Five Lines of Code
Christian Clausen
  • MEAP began May 2020
  • Publication in Spring 2021 (estimated)
  • ISBN 9781617298318
  • 275 pages (estimated)
  • printed in black & white

Delivers concise refactoring patterns and corresponding rules that will prove immediately valuable for any developer who struggles to quickly, safely and consistently refactor code.

Jeff Neumann
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.” It’s written for working developers, guiding you step by step through applying refactoring patterns to the codebase of a 2D puzzle game. 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. Thanks to this hands-on guide, you’ll find yourself programming faster while still delivering high-quality code that your teammates will love to work with.

About the Technology

Refactoring is a fact of life. All code is imperfect, and refactoring is a systematic process you can use to improve the quality of your codebase. Whatever your architecture, choice of OO language, or skill as a programmer, the continuous design improvements of refactoring make your code simpler, more readable, and less prone to bugs. You’ll be amazed at the productivity boost of adding refactoring to your code hygiene routine—it’s quicker to hammer out bad code and then improve it than spending hours writing good code in the first place!

About the book

Five Lines of Code teaches working developers the shortcuts to quality code. You’ll follow author Christian Clausen’s unique approach to teaching refactoring that’s focused on concrete rules, and getting any method down to five lines or less to implement! There’s no jargon or tricky automated-testing skills required, just easy guidelines and patterns illustrated by detailed code samples. Chapter by chapter you’ll put techniques into action by refactoring a complete 2D puzzle game. Before you know it, you’ll be making serious and tangible improvements to your codebase.
Table of Contents detailed table of contents

1 Introduction

1.1 What is refactoring?

1.2 Skills: What to refactor?

1.2.1 An Example Code Smell

1.2.2 An Example Rule

1.3 Culture: When to refactor?

1.3.1 Introducing refactoring in a legacy system

1.3.2 When should you not refactor?

1.4 Tools: How to refactor (Safely)?

1.5 Tools you need to get started

1.5.1 Programming language: TypeScript

1.5.2 Editor: Visual Studio Code

1.5.3 Version control: Git

1.6 Overarching example: a 2D puzzle game

1.7 A note on real-world software

1.8 Summary

2 Getting to Know Refactoring: the What, Why, and Why Now?

2.1 Improving readability and maintainability

2.1.1 Making code better

2.1.2 Maintaining code …​ Without changing what it does

2.2 Gaining speed, flexibility, and stability

2.2.1 Composition over inheritance

2.2.2 Change by addition

2.3 Refactoring and your daily work

2.3.1 Refactoring as a method for learning

2.4 Summary

Part 1: Learn by Refactoring a Computer Game

3 Using functions to break up long functions

3.1 Our first rule: Why five lines?

3.1.1 Rule: Five lines

3.2 Our first refactoring pattern

3.2.1 Refactoring: Extract method

3.3 A second rule

3.3.1 Rule: Either call or pass

3.3.2 Applying the rule

3.4 Naming

3.5 Refining further

3.5.1 Rule: if only at the start

3.5.2 Applying the rule

3.6 Summary

4 Using objects to eliminate complex if statements

4.1 A simple if statement

4.1.1 Rule: Never use if with else

4.1.2 Applying the rule

4.1.3 Refactoring: Replace type code with classes

4.1.4 Pushing code into classes

4.1.5 Refactoring: Push code into classes

4.1.6 Inlining a superfluous method

4.1.7 Refactoring: Inline method

4.2 A large if statement

4.2.1 Removing generality

4.2.2 Refactoring: Specialize method

4.2.3 The only switch allowed

4.2.4 Rule: Never use switch

4.2.5 Eliminating the if

4.3 Code duplication

4.3.1 Couldn’t we use an abstract class instead of the interface?

4.3.2 Rule: Only inherit from interfaces

4.3.3 What is up with all this code duplication?

4.4 A pair of complex if statements

4.5 Cleaning up

4.5.1 Refactoring: Try delete then compile

4.6 Summary

5 Unifying code to simplify and enable reuse

5.1 Unifying similar classes

5.1.1 Refactoring: Unify similar classes

5.2 Unifying simple conditions

5.2.1 Refactoring: Combine ifs

5.3 Unifying complex conditions

5.3.1 Arithmetic of conditions

5.3.2 Rule: Use pure conditions

5.3.3 Using condition arithmetic

5.4 Unifying code across classes

5.4.1 UML Class Diagrams 101

5.4.2 Refactoring: Introduce strategy-pattern

5.4.3 Rule: No interface with only one implementation

5.4.4 Refactoring: Extract interface from implementation

5.5 Unifying similar functions

5.6 Unifying similar code

5.7 Summary

6 Encapsulate, to localize invariants

6.1 Encapsulating without getters

6.1.1 Rule: Do not use getters and setters

6.1.2 Applying it

6.1.3 Refactoring: Eliminate getter or setter

6.1.4 The final getter

6.2 Encapsulating simple data

6.2.1 Rule: Never have common affixes

6.2.2 Applying it

6.2.3 Refactoring: Encapsulate data

6.3 Encapsulating complex data

6.4 Eliminating a sequence invariant

6.4.1 Refactoring: Enforce sequence

6.5 Dealing with enums

6.5.1 Enumeration through private constructors

6.5.2 Remapping numbers to classes

6.6 Summary

Part 2: Taking What You Have Learned Into the Real World

7 Work With the Compiler

7.1 Know the compiler

7.1.1 Weakness: Halting problem

7.1.2 Strength: Reachability

7.1.3 Weakness: Null checks

7.1.4 Strength: Definite assignment

7.1.5 Weakness: Arithmetic errors

7.1.6 Weakness: Out of bounds errors

7.1.7 Strength: Access control

7.1.8 Weakness: Termination checking

7.1.9 Strength: Type checking

7.1.10 Weakness: Deadlocks and race conditions

7.2 Use the compiler

7.2.1 Gain safety

7.2.2 Do not fight it

7.3 Trust the compiler

7.3.1 Teach it invariants

7.3.2 Pay attention to warnings

7.4 Trust the compiler exclusively

7.5 Summary

8 Avoid Comments

8.1 Out-dated comments should be deleted

8.2 Out-commented code should be deleted

8.3 Trivial comments should be deleted

8.4 Comments that could be a method name

8.4.1 Planning comments

8.5 Comments that document a non-local invariant

8.5.1 Invariants in the process

8.6 Summary

9 Love deleting code

9.1 Deleting code may be the next frontier

9.2 Delete code to get rid of technical-ignorance, -waste, -debt and -drag

9.2.1 Technical ignorance from inexperience

9.2.2 Technical waste from time pressure

9.2.3 Technical debt from circumstances

9.2.4 Technical drag from growing

9.3 Categories for code based on intimacy

9.4 Deleting code in a legacy system

9.4.1 Using strangler fig pattern to get insight

9.4.2 Using strangler fig pattern to improve the code

9.5 Deleting code from a frozen project

9.5.1 Make the desired outcome the default

9.5.2 Minimize waste with spike and stabilize

9.6 Deleting branches in version control

9.6.1 Minimize waste by enforcing a branch limit

9.7 Deleting code documentation

9.7.1 Algorithm to determine how to codify knowledge

9.8 Deleting testing code

9.8.1 Delete optimistic tests

9.8.2 Delete pessimistic tests

9.8.3 Fix or delete flaky tests

9.8.4 Refactor the code to get rid of complicated tests

9.8.5 Specialize tests to speed them up

9.9 Deleting configuration code

9.9.1 Scoping configuration in time

9.10 Deleting code to get rid of libraries

9.10.1 Limiting our reliance on external libraries

9.11 Deleting code from working features

9.12 Summary

10 Never be Afraid to Add Code

11 Avoid Optimizations and Generality

12 Follow the Structure in the Code

13 Bad Code Should Look Bad

14 Wrapping Up

What's inside

  • The symptoms of bad code
  • The extracting method, introducing strategy pattern, and many other refactoring patterns
  • Modifying code safely, even when you don’t understand it
  • Writing stable code that enables change-by-addition
  • Proper compiler practices
  • Writing code that needs no comments
  • Real-world practices for great refactoring

About the reader

For developers who know an object-oriented programming language.

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.

placing your order...

Don't refresh or navigate away from the page.
Manning Early Access Program (MEAP) Read chapters as they are written, get the finished eBook as soon as it’s ready, and receive the pBook long before it's in bookstores.
print book $29.99 $49.99 pBook + eBook + liveBook
Additional shipping charges may apply
Five Lines of Code (print book) added to cart
continue shopping
go to cart

eBook $31.99 $39.99 3 formats + liveBook
Five Lines of Code (eBook) added to cart
continue shopping
go to cart

Prices displayed in rupees will be charged in USD when you check out.
customers also reading

This book 1-hop 2-hops 3-hops

FREE domestic shipping on three or more pBooks