Shulou(Shulou.com)06/02 Report--

Today, I would like to talk to you about what Solidity coding specifications are, many people may not know much about it. In order to make you understand better, the editor summarizes the following content for you. I hope you can get something according to this article.

Naming conventions avoid using

Lowercase l, uppercase I, and uppercase O should avoid appearing separately in naming, because it is easy to cause confusion.

Contract, library, event, enumeration and structure naming

Contracts, libraries, events, and structures should be named in uppercase letters, also known as Pascal naming or big hump naming, such as SimpleToken, SmartBank, CertificateHashRepository,Player.

Functions, parameters, variables and modifiers

Functions, parameters, variables, and modifiers should be capitalized after the first word in lowercase, also known as hump naming, which is a mixed case, such as:

The function name should be like: getBalance,transfer,verifyOwner,addMember.

Parameters and variables should be like: initialSupply,senderAddress,account,isPreSale.

Modifiers should be like: onlyAfter,onlyOwner.

Code format dependent indentation

Use spaces instead of Tab, indentation should be 4 spaces

Blank line

There should be blank lines between contracts, such as:

Contract A {...} contract B {...} contract C {...}

Instead of using:

Contract A {...} contract B {...} contract C {...}

There should be blank lines between functions, for example:

Contract A {function spam () public {...} function ham () public {...}}

If it is not implemented, blank lines can be omitted, such as:

Contract A {function spam () public; function ham () public;}

Instead of:

Contract A {function spam () public {...} function ham () public {...} left parenthesis should be defined on one line

Definitions include contract definition, function definition, library definition, structure definition, etc., for example, it is recommended to use:

Contract Coin {struct Bank {address owner; uint balance;}}

Instead of:

Contract Coin {struct Bank {address owner; uint balance;}} left parenthesis should be controlled on one line with the condition

When using if, else, while, for, the recommended way to write is:

If (...) {...} for (...) {...}

Instead of:

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

If there is only one line in the control statement, parentheses can be omitted, such as:

If (x < 10) x + = 1

But a statement like the following cannot be omitted if there are multiple parties, such as:

If (x < 10) someArray.push (Coin ({name: 'spam', value: 42})); spaces within the expression

In a single-line expression, unnecessary spaces should be avoided in parentheses, square braces, and curly braces, such as recommended:

Spam (ham [1], Coin ({name: "ham"}))

Instead of:

Spam (ham [1], Coin ({name: "ham"}))

One exception is that the closing parenthesis follows the closing semicolon and a space should be added, as is recommended in the following way:

Function singleLine () public {spam ();}

A semicolon should not be preceded by a space, for example, it is recommended:

Function spam (uint I, Coin coin) public

Instead of:

Function spam (uint I, Coin coin) public

Do not add unnecessary spaces to the alignment, such as recommended:

X = 1x y = 2x longevity variable = 3

Instead of:

X = 1x y = 2x longevity variable = 3

Fallback functions should not have spaces, such as recommended:

Function () public {...}

Instead of:

Function () public {...}

Control the length of each line

Each line should not be too long, preferably within 79 (or 99) characters, and the argument to the function should be a separate line with only one indent. For example, the recommended way is:

ThisFunctionCallIsReallyLong (longArgument1, longArgument2, longArgument3)

Instead of:

ThisFunctionCallIsReallyLong (longArgument1,longArgument2,longArgument3); thisFunctionCallIsReallyLong (longArgument1,longArgument2,longArgument3); thisFunctionCallIsReallyLong (longArgument1,longArgument2,longArgument3); thisFunctionCallIsReallyLong (longArgument1,longArgument2,longArgument3); thisFunctionCallIsReallyLong (longArgument1,longArgument2,longArgument3)

The corresponding assignment statement should be written as follows:

ThisIsALongNestedMapping [being] [set] [to_some_value] = someFunction (argument1, argument2, argument3, argument4)

Instead of:

ThisIsALongNestedMapping [being] [set] [to_some_value] = someFunction (argument1, argument2, argument3, argument4)

Event definitions should follow the same principles, such as using:

Event LongAndLotsOfArgs (adress sender, adress recipient, uint256 publicKey, uint256 amount, bytes32 [] options); LongAndLotsOfArgs (sender, recipient, publicKey, amount, options)

Instead of:

Event LongAndLotsOfArgs (adress sender, adress recipient, uint256 publicKey, uint256 amount, bytes32 [] options); LongAndLotsOfArgs (sender, recipient, publicKey, amount, options); file encoding format

Utf-8 and ASCII coding are recommended

The incoming file should be at the top

Recommended:

Import "owned"; contract A {...} contract B is owned {...}

Instead of:

Contract A {...} import "owned"; contract B is owned {...} the order in which canonical functions are written

When writing functions, you should make it easy to find constructors and fallback functions. The officially recommended order of functions is:

Constructor function

Fallback function (if any)

External function (external)

Public function (public)

Internal function (internal)

Private function (private)

For the same type of function, the constant function is placed at the end, for example, the recommended method is:

Contract A {/ / Constructor function A () public {...} / / fallback function function () public {.} / / external function / /. / / with constant external function / /... / / Public function /. / / Internal function / /. / / Private function / /.}

Instead of the following function order:

Contract A {/ / external function /. / / Public function / /. / / Internal function / /. Function A () public {.} function () public {.} / / Private function / /.} explicit visibility of the function

All functions (including constructors) should specify the visibility of the function when they are defined, for example, they should use:

Function explicitlyPublic (uint val) public {doSomething ();}

Instead of

Function implicitlyPublic (uint val) {doSomething ();} visibility should precede the modifier

The visibility of the function should be written before the custom function modifier, for example:

Function kill () public onlyowner {selfdestruct (owner);}

Instead of

Function kill () onlyowner public {selfdestruct (owner);} distinguishes functions from events

To prevent confusion between functions and events (Event), declare an event in uppercase and prefix it (you can use LOG). For functions, always start with a lowercase letter, except for the constructor.

/ / event Transfer () {} function transfer () {} / / event LogTransfer () {} function transfer () external {} constant is not recommended

Constants should use all capitals and underscores to separate big words, such as MAX_BLOCKS,TOKEN_NAME, CONTRACT_VERSION.

After reading the above, do you have any further understanding of the Solidity coding specification? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.