Table of Contents for Naming conventions in Solidity (and other style guides)

How you write your Solidity code is really up to you. But if you follow the common naming conventions and other style guides it will look neater, be easier to read and look more professional.

This is normally quite important… but with solidity smart contracts appearing publicly (if you share the source code & verify them on etherscan) it is even more important.

Contract names naming convention in Solidity

Contract names should be PascalCase (also known as CapsWords)

e.g. MyContract, Contract

Contracts should also match their filename. If a file contains multiple contracts (which itself is not recommended), the filename should match the main/core contract.

Library names naming convention in Solidity

Library names should follow the same convention as contract names - PascalCase.

Libraries should also match their filename.

Struct naming conventions in Solidity

Structs should also be in PascalCase (CapsWords)

e.g. MyStruct, Person

Event names

You might notice a trend here, but event names should be in PascalCase (CapsWords)

e.g. MyEvent, TransferTokens, Withdrawal

Function names naming convention in Solidity

This should be in camelCase (also known as mixedCase)

e.g. increment(), incrementCounter(), addSomethingToMe(), changeOwner()

Function parameters naming convention in Solidity

These should also be in camelCase (also known as mixedCase)

• e.g. whoSaidHi - sayHi(address whoSaidHi)
• senderAddress, owner

Local/state variables

Should be in camelCase (mixedCase)

e.g. totalSupply, counter

Constants

Constants should be in all caps with underscores

e.g. TOKEN_NAME

Modifier names naming conventions in Solidity

These should be in camelCase such as isOwner, owner, myModifier

Enums naming convention in Solidity

Enums should also be in PascalCase

eg. MyEnum, Sizes

Avoiding name collisions (avoiding variable name shadowing) in Solidity

Sometimes you have two variables (often one is a function param, one is state) with the same name. To avoid name collisions it is recommended to append a underscore.

e.g. helloWorldMessage_

Ordering of functions

There is a common ordering of functions that you should follow.

• constructor
• receive function
• fallback function
• external
• public
• internal
• private

Within those groups, view and pure functions should be listed last.

Spotted a typo or have a suggestion to make this crypto dev article better? Please let me know!