If someone might want it different, it should not be a literal

During the period from August 2, 2026, to August 6, 2026, a project established a rule for determining whether a value should be a setting or a literal in the code. The question guiding this decision is whether a reasonable person could want the value to be different without modifying the code. This principle applies to various aspects such as drop chances, cooldowns, discount rates, caps, page sizes, thresholds, feature switches, and numerous text elements.

One significant challenge identified was settings that were not being utilized. A tax on a transaction was once a properly configured setting yet remained unused, uncharged, and undetected in the code. The issue stems from the fact that the setting was present in the operator's list of changes but had no reader to enforce its application.

To address this, a test was implemented to traverse all registered settings and flag those without a reader. This test proved effective in uncovering both real gaps and deliberate placeholders, which then required documentation.

Another common issue was the presence of duplicated constants. Developers would register a setting with its previous value as the default and then forget to remove the old constant. Consequently, the system would suffer from two sources of the same number. When the operator changed the setting, no changes occurred, leading to confusion and the erroneous conclusion that the system was broken.

An example was a setting named after a discount, where the code applied its own value instead of the registered setting. Deleting the literal constant was essential to make the feature functional.

A subtler issue involved settings that stored data differently. For instance, the purchasability of an item was stored as a flag on the item when the catalog was first created. The shop's stock list, however, was maintained separately. This discrepancy led to an item remaining purchasable even after it was removed from the shop, as the flag remained unchanged. Deriving the flag from the stock list rather than copying it at creation time resolved this issue by ensuring a single source of truth.

The project also addressed the challenge of offline defaults. Some settings needed to be accessible on the player's device, with the client requiring a floor for when no connection was available. Each of these values existed in two forms: one set by the operator and another compiled into the game as a minimum value. The two values had to be identical to prevent inconsistent behavior depending on whether a connection was present or not.

A test was employed to ensure that the compiled floor matched the registered default, catching a subtler regression where the game would continue using the floor even if the value was no longer marked as client-accessible.

Certain values, such as structural values, version markers on saved data, and formula shapes, were explicitly excluded from this rule. Structural values are not mere settings but represent different designs. Version markers and formula shapes are integral parts of the code and should not be treated as settings. The remaining values were identified as settings that developers should anticipate needing to adjust in the future, particularly during late-night debugging sessions.

This approach has proven beneficial for the Idle Cultivation Game, ensuring clarity and maintainability in the codebase.