Code Quality & Refactoring

Quality is not beauty. It is how cheaply the next person can change this code without breaking it.

Coupling and cohesion are the two measures that matter most. Cohesion is how related the things inside a module are; coupling is how much modules depend on each other. You want high cohesion and low coupling. Most other guidance is a special case of this.

SOLID, briefly and honestly: Single Responsibility — a class should have one reason to change. Open-Closed — extend behaviour without editing existing code. Liskov Substitution — a subtype must be usable anywhere its parent is, which is why a Square that breaks Rectangle's behaviour is the classic violation. Interface Segregation — many small interfaces beat one fat one. Dependency Inversion — depend on abstractions, not concretions.

Code smells are named symptoms, not rules. God object — one class that knows everything. Primitive obsession — passing strings and ints where a type would carry meaning, so nothing stops you swapping two arguments. Shotgun surgery — one conceptual change requiring edits in twelve files, a coupling problem. Feature envy — a method more interested in another object's data than its own. Magic number — an unexplained literal.

Refactoring moves have names too, and using them signals you are making a known, safe transformation rather than rewriting: Extract Method, Rename, Inline, Introduce Parameter Object, Replace Conditional with Polymorphism. The definition matters: refactoring changes structure without changing behaviour. If behaviour changes, it is not a refactor, and calling it one is how untested rewrites get merged.

Cyclomatic complexity counts independent paths through a function, which is roughly the number of tests needed to cover it. It is a useful smell detector and a terrible target.

DRY has a limit. Two pieces of code that look alike but change for different reasons should stay separate — deduplicating them couples two things that were independent, and the cure is worse than the repetition.