01Brief06 / 08

Numbers that do not say what they are

Rewrite can_post so every threshold is a named constant, without changing what the function decides.

What is wrong with itFour bare numbers in four comparisons, each one a policy decision nobody wrote down. 13 is a legal requirement, 20 is an anti-spam limit somebody argued about, 50 is a reputation threshold, and 3 is how many strikes you get. The code says what it does and nothing about why, and the day one of them changes you have to grep for a number.

Function	can_post()
Track	Making it better
Difficulty
Time	~18 min
Concepts	named constants one definition per rule policy is not logic
Cases	9

02The contract

A user under the minimum age cannot post.
A user who has already posted the daily limit cannot post.
A user below the reputation threshold cannot post.
A user with the strike limit or more cannot post.
Anyone else can.
The thresholds are 13, 20, 50 and 3 — and must stay exactly those.
The behaviour must not change in any respect.

—The barchecked, not suggested

Name the age threshold MINIMUM_AGE. 13 is a legal requirement, and the name is what tells the next reader not to tune it.
Name the daily cap DAILY_POST_LIMIT — the one somebody will come and change when the spam rules move.
Name the reputation threshold MINIMUM_REPUTATION.
Name the strike threshold STRIKE_LIMIT.

Every case still has to pass. These are checked by reading your code, so a solution that is merely correct will not clear them.

03Why this one

A magic number is a decision hiding in an expression. The cost is not that the code is unclear in the moment — it is that the number has no name to search for, no single place to change, and no way to tell you whether the 20 over here is the same 20 as the one in the moderation module. Naming them turns policy into something you can read, find and edit, and it takes four lines.

—The concept behind it

Variables on pythonmastery.io →

That is the reading half. Read it there if the idea is new, then come back here — explanation is what makes something make sense, and practice is what makes it stay.

—Worth doing first

The if-chain that should be data

Not a gate — start this one whenever you like. These cover ideas it leans on, and a tick means you have already done them.

your_code.py

05One way to write it

# A legal requirement, not a product setting — do not tune this one.
MINIMUM_AGE = 13

DAILY_POST_LIMIT = 20
MINIMUM_REPUTATION = 50
STRIKE_LIMIT = 3


def can_post(user):
    """Return whether this user is allowed to post."""
    if user["age"] < MINIMUM_AGE:
        return False

    if user["posts_today"] >= DAILY_POST_LIMIT:
        return False

    if user["reputation"] < MINIMUM_REPUTATION:
        return False

    if user["strikes"] >= STRIKE_LIMIT:
        return False

    return True

The comparisons stay exactly as they were

Two are < and two are >=, because two of the numbers are minimums you must reach and two are limits you must not reach. Making them consistent would feel tidier and would change three of the boundary cases. In a refactor, the comparison operators are behaviour and not style.

Constants named for the rule, not for the field

MINIMUM_AGE rather than AGE, DAILY_POST_LIMIT rather than POSTS — the name says which side of the comparison the number sits on, so `age < MINIMUM_AGE` reads as a sentence and `age < AGE` reads as a typo. A well-named constant makes the comparison self-checking.

Python has no real constants, and the convention is enough

Nothing stops anybody assigning to MINIMUM_AGE at runtime; the capitals are a promise between people, and in practice they hold. If you need the promise enforced — a public API, a value other code must not monkey-patch — an Enum or a frozen dataclass will do it, at the cost of a lookup and some ceremony.

06When not to write this at all

Not every literal is magic. 0 and 1 as starting points, 2 in a halving, 100 in a percentage, and the 60s in a time conversion are all clearer as themselves — naming them adds a hop for the reader and explains nothing. The test is whether the number is a decision somebody made: if it could plausibly have been a different number, name it. And once these values need to differ per environment or be changed without a deploy, they stop being constants and become configuration, which is a different mechanism with its own costs.

07Take it further

Move the four values into a settings object passed in, and decide whether the function got better or merely more configurable.
Return the reason for a refusal instead of False, and see how much the named constants help the message.
Look for the same thresholds elsewhere in a codebase you know, and find out whether the two copies still agree.