elements of programming
The Elements of Programming Style (1974) by Brian Kernighan and P.J. Plauger
clarity first
write clearly. not cleverly.
say what you mean. directly.
let the reader see the intent.
use libraries.
reuse what works. copy the good parts. improve them.
good artists copy. great engineers don’t waste time.
avoid unnecessary variables.
prefer simple, immutable data when you can.
benchmark before you trade clarity for performance.
computers are fast.
let them handle what they’re good at.
remove repetition, but only if it helps.
don't abstract what you won't need.
avoid branches when expressions will do.
use the language well.
some features exist for a reason.
others should be avoided.
know the difference.
structure matters
make code read top to bottom.
group related logic.
use real control structures — not clever jumps or flags.
follow decisions with their actions.
use data to remove control flow when you can.
design around the shape of your data — not your code.
don’t settle for your first draft.
rewrite until it’s obvious.
think in modules
break large problems into small ones.
each module should do one thing, well.
make interfaces clear.
structure follows data.
data comes first.
don't patch around bad code — rewrite it.
big programs grow in small pieces.
test those pieces as you build.
handle input like it matters
validate early.
handle edge cases with care.
never trust counts — use markers or boundaries.
make input readable, and output self-explanatory.
echo defaults. label everything.
make the format easy to parse and review.
contain I/O inside small routines.
limit side effects.
don't repeat mistakes
initialize every variable.
expect more than one bug.
invest in good tools.
watch for off-by-one.
watch for equality logic.
watch for loops that exit early or badly.
write code that can "do nothing" gracefully.
test boundaries.
program defensively.
optimize last
get it right before you make it fast.
keep it right while you optimize.
make it clear, always.
don't chase tiny gains.
don't add complexity for imagined performance.
requirements will change anyway.
let the compiler optimize the simple things.
prefer better algorithms to clever tweaks.
instrument before you guess.
special cases are rarely special.
code for the common case.
document less, but better
make code and comments agree.
don't explain bad code — fix it.
name things well.
write comments that add insight, not noise.
format to show structure.
indent to reveal logic.
document your data layouts.
and don't overcomment.
your code should speak for itself.