Five Lines of Code: How and when to refactor

by Christian Clausen

Overview

Five Lines of Code teaches refactoring that's focused on concrete rules and getting any method down to five lines or less! There’s no jargon or tricky automated-testing skills required, just easy guidelines and patterns illustrated by detailed code samples.

In Five Lines of Code you will learn:

The signs of bad code
Improving code safely, even when you don’t understand it
Balancing optimization and code generality
Proper compiler practices
The Extract method, Introducing Strategy pattern, and many other refactoring patterns
Writing stable code that enables change-by-addition
Writing code that needs no comments
Real-world practices for great refactoring

Improving existing code—refactoring—is one of the most common tasks you’ll face as a programmer. Five Lines of Code teaches you clear and actionable refactoring rules that you can apply without relying on intuitive judgements such as “code smells.” Following the author’s expert perspective—that refactoring and code smells can be learned by following a concrete set of principles—you’ll learn when to refactor your code, what patterns to apply to what problem, and the code characteristics that indicate it’s time for a rework.

Foreword by Robert C. Martin.

Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.

About the technology
Every codebase includes mistakes and inefficiencies that you need to find and fix. Refactor the right way, and your code becomes elegant, easy to read, and easy to maintain. In this book, you’ll learn a unique approach to refactoring that implements any method in five lines or fewer. You’ll also discover a secret most senior devs know: sometimes it’s quicker to hammer out code and fix it later!

About the book
Five Lines of Code is a fresh look at refactoring for developers of all skill levels. In it, you’ll master author Christian Clausen’s innovative approach, learning concrete rules to get any method down to five lines—or less! You’ll learn when to refactor, specific refactoring patterns that apply to most common problems, and characteristics of code that should be deleted altogether.

What's inside

The signs of bad code
Improving code safely, even when you don’t understand it
Balancing optimization and code generality
Proper compiler practices

About the reader
For developers of all skill levels. Examples use easy-to-read Typescript, in the same style as Java and C#.

About the author
Christian Clausen works as a Technical Agile Coach, teaching teams how to refactor code.

Table of Contents
1 Refactoring refactoring
2 Looking under the hood of refactoring
PART 1 LEARN BY REFACTORING A COMPUTER GAME
3 Shatter long function
4 Make type codes work
5 Fuse similar code together
6 Defend the data
PART 2 TAKING WHAT YOU HAVE LEARNED INTO THE REAL WORLD
7 Collaborate with the compiler
8 Stay away from comments
9 Love deleting code
10 Never be afraid to add code
11 Follow the structure in the code
12 Avoid optimizations and generality
13 Make bad code look bad
14 Wrapping up

Product Details

ISBN-13:	9781617298318
Publisher:	Manning
Publication date:	10/26/2021
Pages:	336
Product dimensions:	7.38(w) x 9.25(h) x 0.90(d)

About the Author

Christian Clausen works as a Technical Agile Coach teaching teams how to properly refactor their code. Previously he worked as a software engineer on the Coccinelle semantic patching project, an automated refactoring tool. He has an MSc in computer science, and five years’ experience teaching software quality at a university level.

Table of Contents

Foreword xvii

Preface xix

Acknowledgments xxiii

About the author xxv

About the cover illustration xxvi

1 Refactoring re factoring 1

1.1 What is refactoring? 2

1.2 Skills: What to refactor? 3

An example code smell 4

An example rule 4

1.3 Culture: When to refactor? 5

Refactoring in a legacy system 6

When should you not refactor? 6

1.4 Tools: How to refactor (safely) 7

1.5 Tools you need to get started 7

Programming language: TypeScript 8

Editor: Visual Studio Code 8

Version control: Git 9

1.6 Overarching example: A 2D puzzle game 9

Practice makes perfect: A second codebase 11

1.7 A note on real-world software 11

2 Looking under the hood of refactoring 13

2.1 Improving readability and maintainability 13

Making code better 14

Maintaining code … without changing what it does 16

2.2 Gaining speed, flexibility, and stability 17

Favoring composition over inheritance 17

Changing code by addition rather than modification 18

2.3 Refactoring and your daily work 19

Refactoring as a method for learning 19

2.4 Defining the "domain" in a software context 20

Part 1 Learn by refactoring a computer game 21

3 Shatter long functions 23

3.1 Establishing our first rule: Why five lines? 24

Rule: Five lines 24

3.2 Introducing a refactoring pattern to break up functions 27

Refactoring pattern: Extract method 31

3.3 Breaking up functions to balancing abstraction 35

Rule: Either call or pass 35

Applying the rule 36

3.4 Properties of a good function name 37

3.5 Breaking up functions that are doing too much 39

Rule: If Only At The Start 40

Applying the ride 41

4 Make type codes work 44

4.1 Refactoring a simple if statement 45

Rule: Never use if with else 45

Applying the rule 47

Refactoring pattern: Replace type code with classes 49

Pushing code into classes 52

Refactoring pattern: Push code into classes 54

Inlining a superfluous method 58

Refactoring pattern: Inline method 59

4.2 Refactoring a large if statement 62

Removing generality 65

Refactoring pattern: Specialize method 67

The only switch allowed 69

Rule: Never use switch 71

Eliminating the if 72

4.3 Addressing code duplication 74

Couldn't we use an abstract class instead of the interface? 76

Rule: Only inherit from interfaces 77

What is Up with all this code duplication? 78

4.4 Refactoring a pair of complex if statements 78

4.5 Removing dead code 81

Refactoring pattern: Try Delete Then Compile 82

5 Fuse similar code together 84

5.1 Unifying similar classes 85

Refactoring pattern: Unify similar classes 93

5.2 Unifying simple conditions 99

Refactoring pattern: Combine IFS 101

5.3 Unifying complex conditions 103

Using arithmetic rules for conditions 104

Rule: Use pure conditions 104

Applying condition arithmetic 107

5.4 Unifying code across classes 108

Introducing UML class diagrams to depict class relations 113

Refactoring pattern: Introduce strategy pattern 115

Rule: No interface with only one implementation 122

Refactoring pattern: Extract interface from Implementation 123

5.5 Unifying similar functions 126

5.6 Unifying similar code 129

6 Defend the data 135

6.1 Encapsulating without getters 136

Rule: Do not use getters or setters 136

Applying the rule 138

Refactoring pattern: Eliminate getter or setter 140

Eliminating the final getter 142

6.2 Encapsulating simple data 146

Rule: Never, have common affixes 146

Applying the rule 147

Refactoring pattern: Encapsulate data 152

6.3 Encapsulating complex data 155

6.4 Eliminating a sequence invariant 162

Refactoring pattern: Enforce sequence 163

6.5 Eliminating enums another way 165

Enumeration through private constructors 166

Remapping numbers to classes 167

Part 2 Taking what you have learned into the real world 171

7 Collaborate with the compiler 173

7.1 Getting to know the compiler 174

Weakness: The halting problem limits compile-time knowledge 174

Strength: Reachability ensures that methods return 175

Strength: Definite assignment prevents accessing uninitialized variables 176

Strength: Access control helps encapsulate data 176

Strength: Type checking proves properties 177

Weakness: Dereferencing null crashes our application 178

Weakness: Arithmetic errors cause overflows or crashes 178

Weakness: Out-of-bounds errors crash our application 179

Weakness: Infinite loops stall our application 179

Weakness: Deadlocks and race conditions cause unintended behavior 180

7.2 Using the compiler 181

Making the compiler-work 182

Don't fight the compiler 184

7.3 Trusting the compiler 189

Teach the compiler invariants 190

Pay attention to warnings 192

7.4 Trusting the compiler exclusively 192

8 Stay away from comments 194

8.1 Deleting outdated comments 196

8.2 Deleting commented-out code 196

8.3 Deleting trivial comments 197

8.4 Transforming comments into method names 197

Using comments for planning 198

8.5 Keeping invariant-documenting comments 198

Invariants in the process 199

9 Love deleting code 200

9.1 Deleting code may be the next frontier 201

9.2 Deleting code to get rid of incidental complexity 202

Technical ignorance from inexperience 202

Technical waste from time pressure 203

Technical debt from circumstances 204

Technical drag from growing 204

9.3 Categorizing code based on intimacy 205

9.4 Deleting code in a legacy system 205

Using the strangler fig pattern to get insight 206

Using the strangler fig pattern to improve the code 208

9.5 Deleting code from a frozen project 209

Making the desired outcome the default 209

Minimizing waste with spike and stabilize 209

9.6 Deleting branches in version control 210

Minimizing waste by enforcing a branch limit 211

9.7 Deleting code documentation 212

Algorithm to determine how to codify knowledge 212

9.8 Deleting testing code 213

Deleting optimistic tests 213

Deleting pessimistic tests 213

Fixing or deleting flaky tests 213

Refactoring the code to get rid of complicated tests 214

Specializing tests to speed them up 214

9.9 Deleting configuration code 215

Scoping configuration in time 215

9.10 Deleting code to get rid of libraries 216

Limiting our reliance on external libraries 218

9.11 Deleting code from working features 219

10 Never be afraid to add code 221

10.1 Accepting uncertainty: Enter the danger 222

10.2 Using spikes to overcome the fear of building the wrong thing 222

10.3 Overcoming the fear of waste or risk with a fixed ratio 223

10.4 Overcoming the fear of imperfection by embracing gradual improvement 225

10.5 How copy and paste effects change velocity 225

10.6 Modification by addition through extensibility 226

10.7 Modification by addition enables backward compatibility 227

10.8 Modification by addition through feature toggles 229

10.9 Modification by addition through branch by abstraction 232

11 Follow the structure in the code 235

11.1 Categorizing structure based on scope and origin 236

11.2 Three ways that code mirrors behavior 237

Expressing behavior in the control flow 237

Expressing behavior in the structure of the data 239

Expressing behavior in the data 242

11.3 Adding code to expose structure 243

11.4 Observing instead of predicting, and using empirical techniques 244

11.5 Gaining safety without understanding the code 245

Gaining safety through testing 245

Gaining safety through mastery 245

Gaining safety through tool assistance 246

Gaining safety through formal verification 246

Gaining safety through fault tolerance 246

11.6 Identifying unexploited structures 246

Exploiting whitespace with extraction and encapsulation 247

Exploiting duplication with unification 248

Exploiting common affixes with encapsulation 251

Exploiting the runtime type with dynamic dispatch 252

12 Avoid optimizations and generality 254

12.1 Striving for simplicity 255

12.2 When and how to generalize 257

Building minimally to avoid generality 257

Unifying things of similar stability 258

Eliminating unnecessary generality 258

12.3 When and how to optimize 258

Refactoring before optimizing 259

Optimizing according to the theory of constraints 261

Guiding optimization with metrics 263

Choosing good algorithms and data structures 264

Using caching 265

Isolating optimized code 267

13 Make bad code look bad 270

13.1 Signaling process issues with bad code 271

13.2 Segregating into pristine and legacy code 272

The broken window theory 272

13.3 Approaches to defining bad code 273

The rules in this book: Simple and concrete 273

Code smells: Complete and abstract 273

Cyclomatic complexity: Algorithmic (objective) 274

Cognitive complexity: Algorithmic (subjective) 275

13.4 Rules for safely vandalizing code 275

13.5 Methods for safely vandalizing code 276

Using enums 276

Using ints and strings as type codes 277

Putting magic numbers in the code 277

Adding comments to the code 278

Putting whitespace in the code 279

Grouping things based on naming 279

Adding context to names 280

Creating long methods 281

Giving methods many parameters 282

Using getters and setters 283

14 Wrapping up 285

14.1 Reflecting on the journey of this book 285

Introduction: Motivation 286

Part 1 Making it concrete 286

Part 2 Widening the horizon 286

14.2 Exploring the underlying philosophy 286

Searching for ever-smaller steps 286

Searching for the underlying structure 287

Using the rules for collaboration 288

Prioritizing the team over individuals 288

Prioritize simplicity over completeness 288

Using objects or higher-order functions 289

14.3 Where to go from here? 290

Micro-architecture route 290

Macro-architecture route 290

Software quality route 291

Appendix Installing the tools for part 1 293

Index 297