Refactor and Improve Code

Code that works is not the same as code that is good. The first time you solve a problem, your code is usually messy — long lines, weird names, copy-pasted blocks. Refactoring is the second pass: you keep the program doing exactly the same thing, but you change the shape of the code so a human can read it. Same behavior, better structure.

What refactoring is — and is not

• Refactoring changes the shape of code, not what it does. The output stays the same; the inside gets cleaner.
• Refactoring is not adding features. New behavior is a separate job.
• Refactoring is not fixing bugs. A bug fix changes behavior on purpose; a refactor must not.
• You refactor in tiny safe steps and run the program after each step to make sure nothing broke.

Code smells — clues that something is off

• Magic number — a raw value like 86400 sitting in the middle of code with no name. Why 86400? Nobody knows.
• Long function — one block that runs for 80 or 100 lines and does five different things at once.
• Duplicated code — the same three lines copied in four places. Fix one, you forget the others.
• Deep nesting — if inside if inside if inside if. Hard to follow, hard to test.
• Unclear name — variables called x, tmp, data, or doStuff. The name does not tell you anything.
• Dead code — lines that never run, or commented-out blocks left over from last week.
• Global variables for everything — state shared everywhere makes it impossible to know who changed what.

Refactors — the moves that fix smells

• Extract constant — give that magic number a name like SECONDS_PER_DAY = 86400.
• Extract function — pull a chunk of a long block out and give it a name like calculateTotal().
• Split into helpers — break one giant function into three or four small ones, each doing one job.
• Early return — instead of nesting deep, return as soon as you know the answer.
• Rename for intent — change x into score, tmp into nextPlayer, data into customers.
• Delete unused code — if a function or variable has no callers, remove it. Source control remembers.
• Pass as parameter — instead of reading a global, accept the value as an argument.

Clean code in three rules

1. Names tell the truth. A function called sendEmail should send an email — nothing more, nothing less.
2. Each function does one job. If you cannot describe it in one short sentence, split it.
3. No surprises. Code should do what its name promises and nothing weird in the background.