DEV Community

Cover image for DEV3L on Five Lines of Code - How and when to refactor
Justin L Beall
Justin L Beall

Posted on

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)


Enter fullscreen mode Exit fullscreen mode

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


Enter fullscreen mode Exit fullscreen mode

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

Image description



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

Enter fullscreen mode Exit fullscreen mode




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

Enter fullscreen mode Exit fullscreen mode




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

Top comments (0)