book

Five Lines of Code

Name: Five Lines of Code
Author: Christian Clausen
ISBN: 9781617298318

by Christian Clausen

October 2021

Intermediate to advanced

336 pages

9h 16m

English

Manning Publications

Read now

Unlock full access

inside front cover
Quick overview of refactoring patterns
Five Lines of Code
Copyright
dedication
brief contents
contents
front matter
forewordprefaceGoal: The selected rules and refactoring patternsAudience and roadmapAbout the teachingAbout the codeliveBook discussion forumBonus projectacknowledgmentsabout the authorabout the cover illustration
1 Refactoring refactoring
1.1 What is refactoring?1.2 Skills: What to refactor?1.2.1 An example code smell1.2.2 An example rule1.3 Culture: When to refactor?1.3.1 Refactoring in a legacy system1.3.2 When should you not refactor?1.4 Tools: How to refactor (safely)1.5 Tools you need to get started1.5.1 Programming language: TypeScript1.5.2 Editor: Visual Studio Code1.5.3 Version control: Git1.6 Overarching example: A 2D puzzle game1.6.1 Practice makes perfect: A second codebase1.7 A note on real-world softwareSummary
2 Looking under the hood of refactoring
2.1 Improving readability and maintainability2.1.1 Making code better2.1.2 Maintaining code . . . without changing what it does2.2 Gaining speed, flexibility, and stability2.2.1 Favoring composition over inheritance2.2.2 Changing code by addition rather than modification2.3 Refactoring and your daily work2.3.1 Refactoring as a method for learning2.4 Defining the “domain” in a software contextSummary
Part 1. Learn by refactoring a computer game

3 Shatter long functions
3.1 Establishing our first rule: Why five lines?3.1.1 Rule: Five lines3.2 Introducing a refactoring pattern to break up functions3.2.1 Refactoring pattern: Extract method3.3 Breaking up functions to balancing abstraction3.3.1 Rule: Either call or pass3.3.2 Applying the rule3.4 Properties of a good function name3.5 Breaking up functions that are doing too much3.5.1 Rule: if only at the start3.5.2 Applying the ruleSummary
4 Make type codes work
4.1 Refactoring a simple if statement4.1.1 Rule: Never use if with else4.1.2 Applying the rule4.1.3 Refactoring pattern: Replace type code with classes4.1.4 Pushing code into classes4.1.5 Refactoring pattern: Push code into classes4.1.6 Inlining a superfluous method4.1.7 Refactoring pattern: Inline method4.2 Refactoring a large if statement4.2.1 Removing generality4.2.2 Refactoring pattern: Specialize method4.2.3 The only switch allowed4.2.4 Rule: Never use switch4.2.5 Eliminating the if4.3 Addressing code duplication4.3.1 Couldn’t we use an abstract class instead of the interface?4.3.2 Rule: Only inherit from interfaces4.3.3 What is up with all this code duplication?4.4 Refactoring a pair of complex if statements4.5 Removing dead code4.5.1 Refactoring pattern: Try delete then compileSummary
5 Fuse similar code together
5.1 Unifying similar classes5.1.1 Refactoring pattern: Unify similar classes5.2 Unifying simple conditions5.2.1 Refactoring pattern: Combine ifs5.3 Unifying complex conditions5.3.1 Using arithmetic rules for conditions5.3.2 Rule: Use pure conditions5.3.3 Applying condition arithmetic5.4 Unifying code across classes5.4.1 Introducing UML class diagrams to depict class relations5.4.2 Refactoring pattern: Introduce strategy pattern5.4.3 Rule: No interface with only one implementation5.4.4 Refactoring pattern: Extract interface from implementation5.5 Unifying similar functions5.6 Unifying similar codeSummary
6 Defend the data
6.1 Encapsulating without getters6.1.1 Rule: Do not use getters or setters6.1.2 Applying the rule6.1.3 Refactoring pattern: Eliminate getter or setter6.1.4 Eliminating the final getter6.2 Encapsulating simple data6.2.1 Rule: Never have common affixes6.2.2 Applying the rule6.2.3 Refactoring pattern: Encapsulate data6.3 Encapsulating complex data6.4 Eliminating a sequence invariant6.4.1 Refactoring pattern: Enforce sequence6.5 Eliminating enums another way6.5.1 Enumeration through private constructors6.5.2 Remapping numbers to classesSummary
Part 2. Taking what you have learned into the real world
7 Collaborate with the compiler
7.1 Getting to know the compiler7.1.1 Weakness: The halting problem limits compile-time knowledge7.1.2 Strength: Reachability ensures that methods return7.1.3 Strength: Definite assignment prevents accessing uninitialized variables7.1.4 Strength: Access control helps encapsulate data7.1.5 Strength: Type checking proves properties7.1.6 Weakness: Dereferencing null crashes our application7.1.7 Weakness: Arithmetic errors cause overflows or crashes7.1.8 Weakness: Out-of-bounds errors crash our application7.1.9 Weakness: Infinite loops stall our application7.1.10 Weakness: Deadlocks and race conditions cause unintended behavior7.2 Using the compiler7.2.1 Making the compiler work7.2.2 Don’t fight the compiler7.3 Trusting the compiler7.3.1 Teach the compiler invariants7.3.2 Pay attention to warnings7.4 Trusting the compiler exclusivelySummary
8 Stay away from comments
8.1 Deleting outdated comments8.2 Deleting commented-out code8.3 Deleting trivial comments8.4 Transforming comments into method names8.4.1 Using comments for planning8.5 Keeping invariant-documenting comments8.5.1 Invariants in the processSummary
9 Love deleting code
9.1 Deleting code may be the next frontier9.2 Deleting code to get rid of incidental complexity9.2.1 Technical ignorance from inexperience9.2.2 Technical waste from time pressure9.2.3 Technical debt from circumstances9.2.4 Technical drag from growing9.3 Categorizing code based on intimacy9.4 Deleting code in a legacy system9.4.1 Using the strangler fig pattern to get insight9.4.2 Using the strangler fig pattern to improve the code9.5 Deleting code from a frozen project9.5.1 Making the desired outcome the default9.5.2 Minimizing waste with spike and stabilize9.6 Deleting branches in version control9.6.1 Minimizing waste by enforcing a branch limit9.7 Deleting code documentation9.7.1 Algorithm to determine how to codify knowledge9.8 Deleting testing code9.8.1 Deleting optimistic tests9.8.2 Deleting pessimistic tests9.8.3 Fixing or deleting flaky tests9.8.4 Refactoring the code to get rid of complicated tests9.8.5 Specializing tests to speed them up9.9 Deleting configuration code9.9.1 Scoping configuration in time9.10 Deleting code to get rid of libraries9.10.1 Limiting our reliance on external libraries9.11 Deleting code from working featuresSummary
10 Never be afraid to add code
10.1 Accepting uncertainty: Enter the danger10.2 Using spikes to overcome the fear of building the wrong thing10.3 Overcoming the fear of waste or risk with a fixed ratio10.4 Overcoming the fear of imperfection by embracing gradual improvement10.5 How copy and paste effects change velocity10.6 Modification by addition through extensibility10.7 Modification by addition enables backward compatibility10.8 Modification by addition through feature toggles10.9 Modification by addition through branch by abstractionSummary
11 Follow the structure in the code
11.1 Categorizing structure based on scope and origin11.2 Three ways that code mirrors behavior11.2.1 Expressing behavior in the control flow11.2.2 Expressing behavior in the structure of the data11.2.3 Expressing behavior in the data11.3 Adding code to expose structure11.4 Observing instead of predicting, and using empirical techniques11.5 Gaining safety without understanding the code11.5.1 Gaining safety through testing11.5.2 Gaining safety through mastery11.5.3 Gaining safety through tool assistance11.5.4 Gaining safety through formal verification11.5.5 Gaining safety through fault tolerance11.6 Identifying unexploited structures11.6.1 Exploiting whitespace with extraction and encapsulation11.6.2 Exploiting duplication with unification11.6.3 Exploiting common affixes with encapsulation11.6.4 Exploiting the runtime type with dynamic dispatchSummary
12 Avoid optimizations and generality
12.1 Striving for simplicity12.2 When and how to generalize12.2.1 Building minimally to avoid generality12.2.2 Unifying things of similar stability12.2.3 Eliminating unnecessary generality12.3 When and how to optimize12.3.1 Refactoring before optimizing12.3.2 Optimizing according to the theory of constraints12.3.3 Guiding optimization with metrics12.3.4 Choosing good algorithms and data structures12.3.5 Using caching12.3.6 Isolating optimized codeSummary
13 Make bad code look bad
13.1 Signaling process issues with bad code13.2 Segregating into pristine and legacy code13.2.1 The broken window theory13.3 Approaches to defining bad code13.3.1 The rules in this book: Simple and concrete13.3.2 Code smells: Complete and abstract13.3.3 Cyclomatic complexity: Algorithmic (objective)13.3.4 Cognitive complexity: Algorithmic (subjective)13.4 Rules for safely vandalizing code13.5 Methods for safely vandalizing code13.5.1 Using enums13.5.2 Using ints and strings as type codes13.5.3 Putting magic numbers in the code13.5.4 Adding comments to the code13.5.5 Putting whitespace in the code13.5.6 Grouping things based on naming13.5.7 Adding context to names13.5.8 Creating long methods13.5.9 Giving methods many parameters13.5.10 Using getters and settersSummary
14 Wrapping up
14.1 Reflecting on the journey of this book14.1.1 Introduction: Motivation14.1.2 Part 1: Making it concrete14.1.3 Part 2: Widening the horizon14.2 Exploring the underlying philosophy14.2.1 Searching for ever-smaller steps14.2.2 Searching for the underlying structure14.2.3 Using the rules for collaboration14.2.4 Prioritizing the team over individuals14.2.5 Prioritize simplicity over completeness14.2.6 Using objects or higher-order functions14.3 Where to go from here14.3.1 Micro-architecture route14.3.2 Macro-architecture route14.3.3 Software quality routeSummary
Appendix A. Installing the tools for part 1
Node.jsTypeScriptVisual Studio CodeGitSetting up the TypeScript projectBuilding the TypeScript projectHow to modify the level
index
inside back cover
Quick overview of rules

Content preview from Five Lines of Code

13 Make bad code look bad

This chapter covers

Understanding the reasons to separate good and bad code
Understanding the types of bad code
Understanding the rules to make code worse safely
Applying the rules to make bad code worse

At the end of the last chapter, we discussed the advantage of clarifying the quality expectation for code at a glance. In the context of optimization, we did so by putting the code in an isolated namespace or package. In this chapter, we study how to make the quality level clear by making bad code look bad at a glance, a process we will call anti-refactoring.

We begin by discussing why anti-refactoring is useful, first from a process perspective and then from a maintenance perspective. Having established the motivation, ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781617298318Publisher Support Publisher Website Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Five Lines of Code

by Christian Clausen

13 Make bad code look bad

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.