Erlang/OTP Source Style Guide¶
General¶
Source language is C89.
Source uses mix of tabs and spaces. Tab equals 8 spaces, indent is 4 spaces. It seems that spaces are rather accepted way to indent contributions.
Version Control System¶
Erlang/OTP uses Git as its version control system.
Commits should have max 60 characters in the first line. Long commit description follows after one empty line.
The source tree perfectly should be compilable at any time between commits (it does not have to pass all tests between commits though), to simplify git bisect searches.
Headers¶
The #define Guard¶
All headers should have #define guards to prevent multiple inclusion. The format of
the symbol name is __MODULENAME_H__
or __MODULENAME_H
.
Pragma once is not accepted as of Sept 2016.
Naming Macros¶
All macro names are defined using uppercase letters, numbers and underscores.
For new macros a general suggestion for type safety is: if it’s possible to write
it as inline function, one should not create a macro and use inline
(ERTS_INLINE
or ERTS_FORCE_INLINE
) instead.
Prefer to not convert existing macros to inline without a reason (they are well tested as is now and their compiled representation may slightly change with inline, that is not always desirable). Also when going from a macro to a function, its name should be changed accordingly (lowercase + prefix), this may have some undesired consequences for dependent modules and external code using Erlang API.
Naming Types¶
A new type should be named in CamelCase. A publicly visible type must have
longer prefix. For example garbage collection functions have prefix erts_*
,
erts_gc_*
, and types have prefix ErtsGC*
Do not rename existing types without a good reason, especially if it was a part of the public API.
Naming Functions¶
Functions are named using lowercase letters, numbers and underscores.
Function arguments are named using lowercase letters, numbers and underscores.
A globally visible non-inline function should have an erts_
prefix to its
name.
All inline functions should use ERTS_INLINE
or ERTS_FORCE_INLINE
macro.
A local function inside module should be declared static
.
Naming Variables¶
Local variables are named using lowercase letters, numbers and underscores.
It is suggested to have local variables defined as close to their first use as
possible.
A new variable can be declared at the beginning of any scope
(inside an if
, for
, do
etc), not just at the start of the function
body.
Consider using const
if variable is only set once at the moment of its
declaration.
Consider using a strict sized type (Uint64
or Uint32
for example) when
you definitely know limits of your data. Otherwise consider using sizable
(Word
) and similar.
Coding conventions¶
Argument Passing¶
If a function takes a pointer to a memory block, consider using const
pointer type to pass it as read only (const char *
as a mutable pointer
to an immutable array of char
).
If a function should return more than one value, pass pointer to the
container for the result or pass values using their address.
It is suggested to either mark such arguments in comment as in/out
or have a
prefix _out
.
To avoid mistakes, try not having similar types following each other in argument list. This way you’ll get compiler warning if you miss one argument position.