> For the complete documentation index, see [llms.txt](https://zokyo-auditing-tutorials.gitbook.io/zokyo-informational-vulnerabilities/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zokyo-auditing-tutorials.gitbook.io/zokyo-informational-vulnerabilities/tutorials/informational-vulnerability-10-naming-convention.md).

# Informational Vulnerability 10: Naming Convention

{% hint style="info" %}
[**Book an audit with Zokyo**](https://www.zokyo.io/)
{% endhint %}

**Introduction:** Naming conventions are a cornerstone of effective software development, fostering readability, consistency, and a unified coding style. Solidity, as a prominent language for writing Ethereum smart contracts, is no exception. Adopting established naming conventions in Solidity is essential for producing clean, maintainable, and standardized codebases. This tutorial aims to guide developers through the prevalent naming conventions in Solidity, promoting best practices for crafting clear and comprehensible smart contracts.

#### **1. Contract and Library Names**

* **PascalCase:** Contract and library names should be written in PascalCase, meaning that each word is capitalized without spaces or punctuation.

  ```solidity
  solidityCopy codecontract AssetManager {...}
  ```

#### **2. Function Names**

* **camelCase:** Function names should adopt the camelCase format, starting with a lowercase letter followed by uppercase initials for subsequent words.

  ```solidity
  solidityCopy codefunction getTotalAssets() public view returns (uint256) {...}
  ```

#### **3. Event Names**

* **PascalCase:** Similar to contracts, event names should also be in PascalCase to ensure they are easily distinguishable and readable.

  ```solidity
  solidityCopy codeevent AssetAdded(address indexed assetOwner, uint256 assetValue);
  ```

#### **4. Modifier Names**

* **camelCase:** Modifiers should follow the same convention as function names, utilizing camelCase for consistency.

  ```solidity
  solidityCopy codemodifier onlyOwner() {...}
  ```

#### **5. Variable Names**

* **camelCase:** Variables, including state variables and local variables, should be named using camelCase to maintain uniformity across the code.

  ```solidity
  solidityCopy codeuint256 totalSupply;
  ```

#### **6. Constants and Enum Types**

* **UPPER\_CASE\_WITH\_UNDERSCORES:** Constants and enum types should be named using uppercase letters, separated by underscores to denote spaces.

  ```solidity
  solidityCopy codeuint256 constant MAX_SUPPLY = 10000;
  enum AssetState { ACTIVE, INACTIVE, PENDING }
  ```

#### **7. Struct Names**

* **PascalCase:** Structs should adopt PascalCase to maintain a clear and distinguished naming style.

  ```solidity
  solidityCopy codestruct AssetInfo {...}
  ```

#### **Conclusion and Best Practices**

Adherence to a coherent naming convention is instrumental in enhancing code readability and maintainability. It fosters a professional coding environment, facilitating collaboration and communication among developers.

* **Consistency:** Ensure that naming conventions are consistently applied throughout the codebase.
* **Clarity:** Choose names that convey the purpose or functionality of the contracts, functions, or variables clearly and concisely.
* **Documentation:** Complement the naming conventions with adequate documentation to further elucidate the code's purpose and functionality.

Embarking on your Solidity development journey with these conventions as your guide will ensure a well-organized, professional, and highly maintainable codebase, setting a solid foundation for successful and secure smart contract deployment and execution.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zokyo-auditing-tutorials.gitbook.io/zokyo-informational-vulnerabilities/tutorials/informational-vulnerability-10-naming-convention.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.