This guide is intended to provide coding conventions for writing solidity code.
This guide should be thought of as an evolving document that will change over
time as useful conventions are found and old conventions are rendered obsolete.

Many projects will implement their own style guides. In the event of
conflicts, project specific style guides take precedence.

The structure and many of the recommendations within this style guide were
taken from python’s
pep8 style guide.

The goal of this guide is not to be the right way or the best way to write
solidity code. The goal of this guide is consistency. A quote from python’s
pep8
captures this concept well.

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.
But most importantly: know when to be inconsistent – sometimes the style guide just doesn’t apply. When in doubt, use your best judgement. Look at other examples and decide what looks best. And don’t hesitate to ask!

The braces denoting the body of a contract, library, functions and structs
should:

open on the same line as the declaration

close on their own line at the same indentation level as the beginning of the
declaration.

The opening brace should be proceeded by a single space.

Yes:

contractCoin{structBank{addressowner;uintbalance;}}

No:

contractCoin{structBank{addressowner;uintbalance;}}

The same recommendations apply to the control structures if, else, while,
and for.

Additionally there should be a single space between the control structures
if, while, and for and the parenthetic block representing the
conditional, as well as a single space between the conditional parenthetic
block and the opening brace.

Yes:

if(...){...}for(...){...}

No:

if(...){...}while(...){}for(...){...;}

For control structures whose body contains a single statement, omitting the
braces is ok if the statement is contained on a single line.

Yes:

if(x<10)x+=1;

No:

if(x<10)someArray.push(Coin({name:'spam',value:42}));

For if blocks which have an else or elseif clause, the else should be
placed on the same line as the if’s closing brace. This is an exception compared
to the rules of other block-like structures.

You should explicitly label the visibility of all functions, including constructors.

Yes:

functionexplicitlyPublic(uintval)public{doSomething();}

No:

functionimplicitlyPublic(uintval){doSomething();}

The visibility modifier for a function should come before any custom
modifiers.

Yes:

functionkill()publiconlyowner{selfdestruct(owner);}

No:

functionkill()onlyownerpublic{selfdestruct(owner);}

For long function declarations, it is recommended to drop each argument onto
it’s own line at the same indentation level as the function body. The closing
parenthesis and opening bracket should be placed on their own line as well at
the same indentation level as the function declaration.

For constructor functions on inherited contracts whose bases require arguments,
it is recommended to drop the base constructors onto new lines in the same
manner as modifiers if the function declaration is long or hard to read.

Yes:

contractAisB,C,D{functionA(uintparam1,uintparam2,uintparam3,uintparam4,uintparam5)B(param1)C(param2,param3)D(param4)public{// do something with param5}}

No:

contractAisB,C,D{functionA(uintparam1,uintparam2,uintparam3,uintparam4,uintparam5)B(param1)C(param2,param3)D(param4)public{// do something with param5}}contractAisB,C,D{functionA(uintparam1,uintparam2,uintparam3,uintparam4,uintparam5)B(param1)C(param2,param3)D(param4)public{// do something with param5}}

When declaring short functions with a single statement, it is permissible to do it on a single line.

Permissible:

functionshortFunction()public{doSomething();}

These guidelines for function declarations are intended to improve readability.
Authors should use their best judgement as this guide does not try to cover all
possible permutations for function declarations.

Operators with a higher priority than others can exclude surrounding
whitespace in order to denote precedence. This is meant to allow for
improved readability for complex statement. You should always use the same
amount of whitespace on either side of an operator:

Naming conventions are powerful when adopted and used broadly. The use of
different conventions can convey significant meta information that would
otherwise not be immediately available.

The naming recommendations given here are intended to improve the readability,
and thus they are not rules, but rather guidelines to try and help convey the
most information through the names of things.

Lastly, consistency within a codebase should always supercede any conventions
outlined in this document.

When using initialisms in CapWords, capitalize all the letters of the initialisms. Thus HTTPServerError is better than HttpServerError. When using initialisms is mixedCase, capitalize all the letters of the initialisms, except keep the first one lower case if it is the beginning of the name. Thus xmlHTTPRequest is better than XMLHTTPRequest.