New to blockchain software development? Read my beginners guide here

Naming conventions in Solidity (and other style guides)

Created on October 2022 • Tags: guidessolidityethereum

A simple to follow guide to the main naming conventions and other style guides for Solidity language that you should know


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.

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!

See all posts (70+ more)

See all posts (70+ more)

Was this post helpful? 📧

If you liked this content and want to receive emails about future posts like this, enter your email. I'll never spam you.

Or follow me on @CryptoGuide_Dev on twitter

By using this site, you agree that you have read and understand its Privacy Policy and Terms of Use.
Use any information on this site at your own risk, I take no responsibility for the accuracy of safety of the information on this site.