Code Review · Python · Maintainability

Python Code Review: Magic Numbers

Review Python code that hides business rules behind unexplained numeric values.

Code Review Exercise

Review the following code. The logic is not obviously broken, but it has a maintainability problem that experienced reviewers often call out.

python
def calculate_shipping(order_total, item_count):
    if order_total > 75:
        return 0

    if item_count > 10:
        return 12.99

    return 7.99

What would you ask the author during code review?

Review Findings

Issue #1: The numbers do not explain themselves

Values like 75, 10, 12.99, and 7.99 may be correct, but the code does not say what they represent. A reader has to guess whether they are business rules, temporary values, test values, or copied constants from somewhere else.

Issue #2: Business rules are hidden in code

The free-shipping threshold and shipping fees are business decisions. If those values change, someone has to search through code instead of updating a clearly named constant or configuration value.

Issue #3: Harder to review and test

A reviewer cannot easily tell whether 75 means dollars, items, weight, or a promotion threshold. Named values make the intended behavior easier to validate and test.

Issue #4: Duplication risk

Magic numbers often get copied into other files. Once the same value appears in multiple places, future changes become risky because one copy may be updated while another is missed.

Improved Version With Named Constants

python
FREE_SHIPPING_THRESHOLD = 75
BULK_ITEM_THRESHOLD = 10
STANDARD_SHIPPING_FEE = 7.99
BULK_SHIPPING_FEE = 12.99


def calculate_shipping(order_total, item_count):
    if order_total > FREE_SHIPPING_THRESHOLD:
        return 0

    if item_count > BULK_ITEM_THRESHOLD:
        return BULK_SHIPPING_FEE

    return STANDARD_SHIPPING_FEE

This version does not change the behavior, but it makes the intent much clearer. A reviewer can now understand the business rules without reverse-engineering the numbers.

When Configuration May Be Better

Constants are a good first improvement, but some values should not be hard-coded at all.

If shipping thresholds or fees change frequently, they may belong in configuration, a database table, a feature flag, or a pricing rules service instead of source code.

python
def calculate_shipping(order_total, item_count, shipping_rules):
    if order_total > shipping_rules.free_shipping_threshold:
        return 0

    if item_count > shipping_rules.bulk_item_threshold:
        return shipping_rules.bulk_shipping_fee

    return shipping_rules.standard_shipping_fee

This Is Not Python-Specific

Deep nesting is a review smell in many languages: Python, Java, JavaScript, C#, Go, and others. The specific syntax changes, but the review comment is the same: make invalid cases explicit, reduce indentation, and keep the main path easy to follow.

What To Say In A Code Review

A good review comment is specific and helpful, not just critical.

Example review comment:

Consider replacing these raw numbers with named constants such as FREE_SHIPPING_THRESHOLD and STANDARD_SHIPPING_FEE. That would make the business rules easier to understand and safer to change later.

Interview Follow-Ups

Are all numbers magic numbers?

No. Common values like 0, 1, or simple loop bounds are often obvious from context. The issue is with unexplained values that carry business meaning.

Should every magic number become a constant?

Not always. If the value changes by environment, customer, pricing plan, or feature flag, configuration may be better than a constant.

Why do reviewers care about this if the code works?

Because code is read and changed many times after it is written. Unexplained numbers make future changes riskier.

Is this problem specific to Python?

No. Magic numbers are a maintainability issue in Java, JavaScript, Python, SQL, configuration files, and almost every production codebase.

What Interviewers Expect

A strong reviewer does not only ask whether the code runs. They also ask whether the code communicates intent clearly.

  • Readability: replace unexplained values with meaningful names.
  • Maintainability: make future business-rule changes safer.
  • Design: consider configuration when values change often.
  • Testing: named rules make test cases easier to understand.