> 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-2-magic-numbers.md).

# Informational Vulnerability 2: "Magic" Numbers

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

**Introduction:** "Magic" numbers – raw numerical values without clear meaning – can pose a challenge in code readability and future maintenance. Even though they might not directly affect functionality, using constants in place of these values can vastly improve code clarity. In this tutorial, we'll explore the importance of avoiding magic numbers and the benefits of using named constants in Solidity.

**Concept:** A magic number is a direct numerical value used in the code without an accompanying explanation or name. These numbers can be confusing to other developers (or even the original developer after some time has passed) as their purpose or derivation is not immediately clear.

For example, consider coming across the value `1e36` in the code. Without context, it's not clear why this particular value is used, making the code harder to maintain or audit.

**Benefits of Using Constants:**

1. **Readability:** Naming constants provides context, making the code more self-explanatory.
2. **Maintainability:** If the value needs to change in the future, you only have to update it in one place.
3. **No Gas Overheads:** In Solidity, using constant values doesn't introduce any gas costs.

**Example:**

Given the code snippet:

```solidity
solidityCopy codefunction calculateReward(uint256 baseReward) external view returns (uint256) {
    return baseReward * 1e36; // Why 1e36? It's not immediately clear.
}
```

Using a named constant would look like:

```solidity
solidityCopy code// At the top of the contract or library:
uint256 private constant REWARD_MULTIPLIER = 1e36; // Provides a clear name and can be documented with its purpose.

function calculateReward(uint256 baseReward) external view returns (uint256) {
    return baseReward * REWARD_MULTIPLIER; // More readable and self-explanatory.
}
```

**Recommendation:**

1. Scan your contracts for magic numbers.
2. Replace these numbers with appropriately named constants.
3. Add comments to these constants if further explanation is needed.
4. Test to ensure that the logic remains consistent.

**Conclusion:**

While magic numbers might not introduce vulnerabilities, they can make your codebase harder to understand and maintain. Using named constants enhances clarity and ensures that your contracts remain accessible and easy to update in the future. Prioritizing readability will always pay dividends in the long run, especially in collaborative projects or when seeking external audits.


---

# 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:

```
GET https://zokyo-auditing-tutorials.gitbook.io/zokyo-informational-vulnerabilities/tutorials/informational-vulnerability-2-magic-numbers.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.