Packages
surgex
0.5.0
6.0.1
6.0.0
5.1.1
5.1.0
5.0.0
5.0.0-git-015aa39a
4.15.2
4.15.1
4.15.1-git-98b3
4.15.0
4.15.0-git-943e
4.15.0-git-5806
4.14.1
4.14.0
4.13.1
4.13.0
4.12.0
4.11.0
4.11.0-git-97d4
4.11.0-git-14c8
4.10.0
4.10.0-git-37f2
4.9.0
4.9.0-git-9d5f
4.8.1-git-80a7
4.8.0
4.8.0-git-fbda
4.8.0-git-e058
4.7.0
4.7.0-git-5414
4.6.1
4.6.0
4.5.0
4.4.0
4.3.0
4.2.1
4.2.0
4.1.1
4.1.1-git-9f6b
4.1.1-git-6f0cd
4.1.0
4.1.0-git-e934
4.1.0-git-8c28
4.1.0-git-56a9
4.1.0-git-55fd
4.0.0
3.2.8
3.2.7
3.2.6
3.2.5
3.2.4
3.2.3
3.2.2
3.2.1
3.2.0
retired
3.1.0
3.0.0
2.24.1
2.24.0
retired
2.23.0
2.22.0
2.21.0
2.20.1
2.20.0
2.19.0
2.18.1
2.18.0
2.17.0
2.16.0
2.15.0
2.14.0
2.13.0
2.12.1
2.12.0
2.11.0
2.10.0
2.9.0
2.8.0
2.7.0
2.6.0
2.5.1
2.5.0
2.4.0
retired
2.3.0
2.2.1
2.2.0
2.1.1
2.1.0
2.0.0
1.6.0
1.5.2
1.5.1
1.5.0
1.4.0
1.3.1
retired
1.3.0
retired
1.2.1
1.2.0
1.1.0
1.0.0
0.5.2
0.5.1
0.5.0
0.4.3
0.4.2
0.4.1
0.4.0
0.3.3
0.3.2
0.3.1
0.3.0
0.2.0
0.1.0
All Things Elixir @ Surge Ventures Inc, the creators of Fresha
Current section
Files
Jump to
Current section
Files
GUIDE.md
# Programming Guide
## Software Design
Exception names must have the `Error` suffix. Reversely, modules that don't call `defexception`
must not have the `Error` suffix.
Pattern matching should be preferred over `.` or `[]` operators for destructuring.
Deep nest digging macros should be preferred over manual deep structure re-assembly.
Keyword lists should be preferred over maps for internal passing of options.
Tuples should be preferred over lists for internal passing of short, predefined lists.
Functions that may result in success or failure and that must pass additional data upon success or
failure should return `{:ok, ...}` and `{:error, ...}` tuples.
Functions that don't fail with `{:error, ...}` should not return `{:ok, ...}` as well.
Raising an exception should be preferred over returning error tuple for cases which don't have to be
handled.
Modules that express single action should be named with a verb prefix and have a `def call` entry.
Modules that don't express single action, should be named with nouns instead of verbs.
Repeating module name in its function names should be avoided. For example, `User.valid?` should be
preferred over `User.user_valid?`.
Operators `and` and `or` should be preferred over `&&` and `||` when arguments are known for sure
to be booleans.
Guard-enabled functions and operators should be preferred over different means to achieve the same.
Nested controllers should be preferred over custom controller actions.
Named functions should be preferred over anonymous functions.
Function pointers should be preferred over redundant anonymous functions. For example, `&func/1`
is preferred over `fn arg -> func(arg) end`.
Function pointers in `&func/arity` format should be preferred over `&func(&1)` format when there's
no need for argument modification.
When a function in a module has many functions that are private to it, then it should be extracted
into separate submodule along with its private functions.
Repeated or reusable calls to `Ecto.Query.fragment` should be extracted to custom macros.
Functions that return `nil` when fetched item is missing should be named with `get` prefix.
Functions that need to return the reason for fetch failure should be named with `fetch` prefix.
Functions that raise when item is missing should be named with `!` suffix.
Sigils `~w{a b c}` and `~w{a b c}a` should be preferred over `[]` for defining string and atom
lists (code style).
When using `_` for unused variables, it should still be named for description purposes.
For example, `_user` is preferred over just `_`.
## Project Structure
Nested module files must be placed accordingly to nesting in their name. For example,
`MyProject.Web.UserController` module must be placed in `my_project/web`.
Within a module, submodule files may be segregated into subdirectories one level deep without
changing the module name. This is handy for keeping large modules organized. For example,
`MyProject.Web.UserController` module may be placed, together with other controllers, in
`my_project/web/controllers`. Inside each subdirectory, all files may share a common suffix in
order to guarantee unique module names.
Entry points for modules with submodules should be placed inside module directory with a file name
same as module name. Modules without submodules should not be placed in separate directory. For
example, `MyProject.Accounts` module should be defined in `my_project/accounts/accounts.ex` if
there are other submodules like `MyProject.Accounts.User` and in `my_project/accounts.ex` otherwise.
Module entry points should be kept as lightweight as possible and proxy heavier business logic to
submodules.
Module entry points should be used as a place to document the module and all its public functions.