Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add coding style guidelines #3059

Merged
merged 9 commits into from
Oct 7, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
87 changes: 87 additions & 0 deletions CODING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# Juvix coding style guidelines for the standard library and Anoma apps

## General rules

- always use the formatter
- don't use unicode, except perhaps for judoc
- avoid `Pair`
- prefer enumerations with meaningful names over booleans, e.g., instead of using `Bool` define:

```
type Transferability := Transferable | NonTransferable;
```

## Imports

- all imports at the beginning of the file
- explicit names for imported identifiers (`import X open using {iden1; iden2}`)
- exception: `import Stdlib.Prelude open`, `import Anoma open` are allowed

## Names

- types: upper camel case (`Nat`, `PublicKey`)
- functions, constructors, etc: lower camel case (`tokenLogic`, `transferLogic`)
- instances: lower camel case with `I` at the end (`instance eqNatI : Eq Nat := ..`)
- boolean check functions: start with `is` (`isWhatever`)
- record constructors: `mk` + type name (`mkResource`)
- meaningful descriptive long names for arguments of public functions, e.g., `element`, `list`, `initialValue`
- exception: common abbreviations allowed: `fun`, `acc`
- short names like `x` are okay for local definitions

## Function signatures

- put everything to the left of `:` in type signatures, with _full_ meaningful names for arguments
- temporary exception: when needed for termination, argument can be moved to the right of `:`
- even when the argument type is moved to the right, give a descriptive argument name in the type:

```
isMember {A} (testEq : A -> A -> Bool) (element : A) : (list : List A) -> Bool
```

## Type variables

- type variables uppercase (upper camel case, like with types)
- implicit type variables: use short version `{A}` in function signatures on the left
- prefer `{A B}` over `{A} {B}` in function signatures
- meaningful type variable names for more "high-level" functions where this makes sense

Example:

```
split
{ResourceType}
{{Convertable ResourceType}}
{{HasOwner ResourceType}}
{{HasQuantity ResourceType}}
{{HasTransferability ResourceType}}
{{TransactionConvertable ResourceType ResourceType}}
(self : KeyPair)
(toSplit : ResourceType)
(quantitiesAndReceivers : List (Pair Nat PublicKey))
: Result StandardError Transaction :=
...
```

But we can use a short name `A` in:

```
find {A} (predicate : A -> Bool) : (list : List A) -> Maybe A
```

## Pattern matching

- use `case` whenever possible; matching on multiple values handled with pairs
- don't use pattern matching with side conditions when there is an `else` side condition -- convert to an `if` in the body instead
- don't pattern match on `Bool` -- use `if` instead

## Application

- don't use "pipes" (i.e., `|>`, `<|`, `>>`, `<<`, etc.)
- weak exception: there is a "natural" data processing pipeline in several steps
- use iterators `for` , `map`, etc., instead of the function application syntax with `fold`, etc.
- use named application when reasonable

## Documentation

- the documentation string should be an English sentence
- mention the meaningful argument names in the function's judoc
Loading