DEV3L on Five Lines of Code - How and when to refactor

Refactoring zealots will tell you you cannot refactor without proper unit test in place - Five Lines of Code assumes no tests available (although highly encouraged) while providing practical coding patterns (XP / Clean Code / Refactoring) that leverage the IDE and compiler such that they are considered "safe".

Christian Clausen does a fantastic job at weaving together the fundamentals of technical agile (craftsmanship) practices that are accessible to beginners yet thought provoking enough to teach the oldest of us dogs a few tricks.

---

Refactoring - the discipline of transforming bad code to good code without breaking it. It works best - and cost least - if you do it regularly.

Good Code

• Human Readable
• Maintainable
• Performs task as expected

Time is expensive, make easy to read

Make change easy, then make easy change

Readability - code's aptitude for communicating intent

Maintainability - risk inherent to change

Readability over Performance
(except when performance matters)

Rules

Rule - Five Lines

• No more than five lines
• Specific limit less important than having limit
• Extract method

Comments are used like deodorant on bad code

Rule - Either Call or Pass

• Call or pass, not both
• Keep at same level of abstraction

Carefully consider names

Rule - If Only At The Start

• if should be first thing in function

Rule - Never Use If With Else

• Unless, checking against data type not in control
• if-else as hardcoded decision

Push Code Into Classes refactoring pattern as an extension of Replace Type Code With Classes

Rule - Never Use Switch

• Unless, no default and return in every case

Rule - Only Inherit from Interfaces

• Shared code causes coupling

Favor object composition over inheritance

IDEs indicate unused code, delete it!

Rule - Use Pure Conditions

• Command and query separation

Don't have to understand all code to refactor.

Strategy Pattern is a powerful refactoring tool.

Rule - No Interface With Only One Implementation

• Interface signals variation; if none, adds overhead to mental model

Rule - Do Not Use Getters or Setters

• Force Pushed-Based Architecture, class behavior

Law of Demeter - Don't talk to strangers
Getters mask violations

Rule - Never Have Common Affixes

• Code should not have common prefixes or suffixes

The Real World

Enforce Sequence

• Remove sequence invariant / temporal coupling
• Utilize constructors / lifecycle events

Listen to compiler's output, including its warnings

Avoid having multiple threads with shared mutable data

Zero Compiler Warnings - Broken Window Theory

Comments are sus, smell, and are not to be used as deodorant on unclean code

Comment only what code cannot say - why comments, not what comments

Code is a liability

Incidental Complexity - "Tech Debt"

• ignorance
• waste
• debt
• drag

Sharpen the Saw - 80/20

Anything that is unused, no matter it's potential, is only an expense

Generality and Optimization sacrifice Simplicity - take precautions to minimize adverse effects

Only solve problem at hand, not problem can imagine

Maximize amount of work not done

Code is efficient until proven otherwise - avoid premature performance optimizations at the cost of readability - setup performance tests when optimization is necessary

Isolate tuned code #magic

If cannot make it good, make it stand out

Cyclomatic Complexity as lower bound for number of tests - one for each path through the code

Improving through small steps is what refactoring is about

Rules Overview

• Five Lines
• Either Call or Pass
• if Only At The Start
• Never Use if with else
• Never Use switcth
• Only Inherit From Interfaces
• Use Pure Conditions
• No Interface With Only One Implementation
• Do Not Use Getters Or Setters
• Never Have Common Affixes

---

Reference Journal Events: Start, Finish