ค่าคงที่และค่าที่เปลี่ยนแปลงไม่ได้

Some values never change after a contract is deployed. For these, Solidity offers constant and immutable keywords that store the value in the contract bytecode instead of expensive storage slots.

Using them reduces gas and signals intent to readers.

A constant must be assigned at the point of declaration and known at compile time. Its value can never change.

By convention constants use UPPER_CASE names.

A constant does not occupy a storage slot. The compiler inlines its value everywhere it is used, so reading it costs almost nothing.

This makes constants ideal for configuration like decimals, caps, and fixed fees.

An immutable variable is set once, either at declaration or in the constructor, and then can never change.

Unlike constants, its value can depend on runtime data such as deployment arguments.

The key difference is when the value is fixed:

• constant - fixed at compile time, must be a literal expression
• immutable - fixed at deploy time, can use constructor inputs

Both are stored in bytecode, not in storage slots.

Immutables shine when each deployment needs different fixed parameters, like a token's total supply or an associated contract address.

Reading a regular state variable requires an SLOAD (storage read), which is costly. Constants and immutables are read directly from bytecode, which is far cheaper.

Converting frequently-read fixed config to constant/immutable is an easy optimization.

A constant cannot depend on anything computed at runtime. Values like block.timestamp, msg.sender, or storage reads are forbidden for constants.

For those, use immutable instead.

After the constructor finishes, an immutable can never be reassigned. Any attempt to write to it outside the constructor is a compile error.

Typical patterns:

• constant for token decimals, max supply caps, and fixed fee rates
• immutable for the owner, deployment timestamp, and linked contract addresses

Both improve clarity and reduce gas compared to mutable state.

By widespread convention, constant names are written in UPPER_SNAKE_CASE, while immutable names often use normal camelCase or a leading underscore for constructor params.

Consistent naming makes audits faster.

You learned about gas-efficient fixed values:

• constant - compile-time literal, inlined into bytecode, UPPER_CASE
• immutable - set once at deploy time (often in the constructor), then read-only
• Both avoid expensive storage reads (SLOAD)

Use constants for known literals and immutables for per-deployment configuration.