Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Hardcoded values

Question: Does a value fixed in code change between deployments, need a descriptive name, or special-case one identity?

  • Runs: when selected: --rule hardcoded-values, --rule maintainability or --rule all · Fails the check by default: no
  • Right on projects JevGate was never tuned on: reviews 1 of 8, considers 17% (5 of 29) (how it is measured)
  • Right on the projects it was tuned on: reviews 54% (15 of 28), considers 56% (32 of 57)
  • Looks at: application functions and module constants that use literal values other than 0, 1, 2 or one-character strings
  • Evidence unit: one function’s source with its literal values, or a file’s module-level constants
  • Acceptable: Messages, formats, protocol names and values whose meaning the code around them makes clear
  • Names: maintainability/hardcoded-values, hardcoded-values, hardcoded_values · Version: 8

When a finding is right

A finding says a value written in the code changes between deployments, needs a descriptive name, or special-cases one identity. It is right for a production host, a customer id or a price written where configuration belongs, or for a number whose meaning a reader must guess. It is wrong when the code around the value already says what it is: the argument it fills, the function or variable it is assigned to, or a comment beside it. A third of the findings labeled wrong or debatable outside Bend 2 code were values whose meaning was clear from their context.

The rule is opt-in since 0.26: on projects JevGate was never tuned on, 6 of its 37 labeled findings were right. A value that only needs a name is at most a consider, and a note when its file writes it once. A value said to change between deployments is asked where it would differ, and one that is the same wherever the program runs is a note.

Findings it got wrong

Labeled wrong by reading the code, on open-source projects the rules were tuned on.

nanoGPT: 312e12

  • Where: model.py:289 in karpathy/nanoGPT at 3adf61e.
  • Finding (consider): GPT::estimate_mfu likely uses a value whose meaning a reader must guess. The value is 312e12.
  • Why it was wrong: The value is assigned to flops_promised beside the comment “A100 GPU bfloat16 peak flops is 312 TFLOPS”, and the docstring defines the result in those units. Nothing is left to guess.
  • Since: a note since 0.21.0, which made a value that only needs a name a note when its file writes it once (changelog).

create-t3-turbo: the auth CLI configuration

  • Where: packages/auth/script/auth-cli.ts:21 in t3-oss/create-t3-turbo at 8f945b7.
  • Finding (review): One of this file’s constants fixes a value that differs between deployments.
  • Why it was wrong: The file says it is used only by the Better Auth CLI to generate the database schema and is “NOT intended for runtime use”. Its http://localhost:3000, "secret" and "1234567890" are placeholders that never reach a deployment.
  • Since: a note since 0.21.0, which asks such a finding where its value would differ; code no deployment runs makes it a note (changelog).

Damn Vulnerable GraphQL Application: 'DVGAUser'

  • Where: core/views.py:118 in dolevf/Damn-Vulnerable-GraphQL-Application at a961308.
  • Finding (review): CreatePaste::mutate fixes a value that differs between deployments. The value is ‘DVGAUser’.
  • Why it was wrong: 'DVGAUser' is the name of the owner row that setup.py creates on every install, and every paste is attributed to it. It is the same in every deployment; reading it from configuration would change nothing.
  • Since: not addressed; reported the same way from 0.20.0 through 0.25.0.