DEV3L on Five Lines of Code - How and when to refactor
Tags: agile, refactoring, cleancode, craftsmanship
Published: 2021-12-03 19:32:43

---
title: DEV3L on Five Lines of Code - How and when to refactor
published: true
description: 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".
tags: agile, refactoring, cleancode, craftsmanship
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/brj20g345cv55d47yqg0.png
---

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.

---

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vai3k5tp24os9s3esc0y.png)

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

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5m4d45s2dsyebozbsedk.png)
 
## 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)
```

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vyf1k9v28neyfx48ajvn.png)
 
# 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

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n95gfrvra133vzzgv4e3.png)
 
## Rule - If Only At The Start

- `if` should be first thing in function

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0k1jfvcm5hiws8reezux.png)
 
## 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.

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m2q4sygwtcphgac0aa6s.png)
 
**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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7p8t14m4cgtj2enx69wh.png)
 
```
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](https://dev.to/dev3l/we-call-it-saw-time) - 80/20

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

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z6nxtg9j36wh37ls6vo1.png)
 
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

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/72smssrmbw4eseonufp6.png)
 
---

Reference Journal Events: [Start](https://twitter.com/dev3l_/status/1457399150031552515), [Finish](https://twitter.com/dev3l_/status/1466640119067201538)