7.17 Best Practices

Readable Expressions

Favor clarity over compactness — an expression that takes an extra half-second to parse mentally, multiplied across every future reader, costs far more than the few characters saved.

Avoid Complex Conditions

Break a long chain of and/or into named intermediate booleans — it documents intent and makes each piece independently testable.

# Harder to read at a glance
if cpu > 80 and mem > 90 and not maintenance_mode and disk < 95:
    alert()

# Clearer
resource_critical = cpu > 80 and mem > 90
disk_ok = disk < 95
if resource_critical and disk_ok and not maintenance_mode:
    alert()

Use Parentheses

Even where precedence rules technically make them unnecessary, parentheses make grouping explicit for anyone reading the code without the precedence table memorized (see 7.9 Operator Precedence and Expression Evaluation).

Quick Interview Answer

“The core habits are: favor readable expressions over compact ones, break long and/or chains into named intermediate booleans so intent is documented and each piece is independently testable, and add parentheses even where precedence rules make them technically optional — nobody should have to hold the full precedence table in their head to understand a conditional.”

Common Mistakes

• Treating a single named boolean as unnecessary overhead for “just one extra condition” — it pays off the moment the condition changes or needs debugging.
• Adding parentheses inconsistently, making some expressions look ambiguous by contrast with others nearby that have them.