What do you think?
Rate this book
Five Lines of Code: How and when to refactor
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
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 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
In Five Lines of Code you will
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 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
336 pages, Paperback
Published October 26, 2021
36 people are currently reading
272 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 15 of 15 reviews
March 10, 2022
A solid guide to approaching refactoring code. There was a lot of repeat advice here, but also some pretty novel ideas that I'd never heard before, such as limiting "if" statements to the top portion of methods.
March 18, 2021
Even as the book is not completed yet, Christian Clausen has managed to make me think differently about software architecture and refactoring. Its intelligent patterns, actionable advice and solid examples demonstrates great teaching skill.
I would recommend this book to anyone working with code. In particular if you are afraid of changing it.
I would recommend this book to anyone working with code. In particular if you are afraid of changing it.
August 8, 2024
I love refactoring books, and I definitely learned a few things from this book.
However, this is one the books I have the most disagreements the most.
For starters, the final code (after the reader applied all the suggested refactorings) is not obviously easier to read then the starting program. The "rules" in general have no justification in real life, and are very dogmatic ("never use else", "never use switch"). The "patterns" are incredibly difficult to apply, and the middle steps result in ridiculously complicated code. The game example is never really explored, and the reader is never expected to play. There are no tests. In general, a really strange book, different from all other books on the subject.
And as with "The Mikado Method", by the same publisher, there is a Part II that has nothing to do with Part I and which seems to be a request from the editor to increase the book length. There is much more that could be explored in Part I, like real-life projects that break or obey the rules.
If you want to consume everything possible on refactoring, then this can be in your reading list. This follows the modern trend of emphasis on compiling and type checking, and some recommended procedures are actually food for thought. But expect a hard time following through and extracting knowledge gems.
However, this is one the books I have the most disagreements the most.
For starters, the final code (after the reader applied all the suggested refactorings) is not obviously easier to read then the starting program. The "rules" in general have no justification in real life, and are very dogmatic ("never use else", "never use switch"). The "patterns" are incredibly difficult to apply, and the middle steps result in ridiculously complicated code. The game example is never really explored, and the reader is never expected to play. There are no tests. In general, a really strange book, different from all other books on the subject.
And as with "The Mikado Method", by the same publisher, there is a Part II that has nothing to do with Part I and which seems to be a request from the editor to increase the book length. There is much more that could be explored in Part I, like real-life projects that break or obey the rules.
If you want to consume everything possible on refactoring, then this can be in your reading list. This follows the modern trend of emphasis on compiling and type checking, and some recommended procedures are actually food for thought. But expect a hard time following through and extracting knowledge gems.
May 10, 2024
From Agile Thoughts: An innovative read!
But I appreciate this author who is willing to make controversial statements and then explain them. Where a lot of other books will shy away from being to extreme and maybe vanillize their principles, this book does not. That said, I agree with maybe 90 some percent of this book and would use it as documented, but there’s a few things I, perhaps haven’t grown enough as a developer or in my experience it isn’t always a good idea. But really, 95% is pretty good so I am really happy and have learned a lot! The author also tackled teaching through a coding kata by using a game that is worked on through most of the book. I and my co-workers really valued that hands on portion even though that made the book much harder to writer for the author.
But I appreciate this author who is willing to make controversial statements and then explain them. Where a lot of other books will shy away from being to extreme and maybe vanillize their principles, this book does not. That said, I agree with maybe 90 some percent of this book and would use it as documented, but there’s a few things I, perhaps haven’t grown enough as a developer or in my experience it isn’t always a good idea. But really, 95% is pretty good so I am really happy and have learned a lot! The author also tackled teaching through a coding kata by using a game that is worked on through most of the book. I and my co-workers really valued that hands on portion even though that made the book much harder to writer for the author.
February 27, 2025
The first part is about some code smells and their refactoring. It is for juniors. The first part is, from mine point of view, confusing, because it is trying to force you to refactor in small steps, but in this many small steps hides the target, I think. Code side by side, is not easy to read and get the motivation and wanted result. Maybe it should be better to show the smell, how to solve it (the target code) and than suggests how to read the goal step by step.
The second part offers more interesting "larger" and more advance topics for seniors. It has more interesting for me but maybe I appreciate to get into more details.
Good introduction and starting point when you are interested in quality of code and refactoring.
The second part offers more interesting "larger" and more advance topics for seniors. It has more interesting for me but maybe I appreciate to get into more details.
Good introduction and starting point when you are interested in quality of code and refactoring.
January 14, 2023
5 lines of code - must read for anyone closer to code, be it a beginer or an expert. Focuses on the benefits of code clean up through refactoring, major call out is on how developing a habit of refactoring as part of daily work help keep the code clean and tech debt free over which translates to better onboarding of new engineers and lower cost of code maintenance in the long run.
Books systematically walks you through refactoring as a method for leaning. Must read for programmers at every level.
Books systematically walks you through refactoring as a method for leaning. Must read for programmers at every level.
January 23, 2023
The principles and advice in the book are insightful and can certainly help with daily programming if followed correctly.
The main problem with the book is that the examples and code snippets are not well-organized, if not misleading. There are quite some times when I say to myself "this doesn't make any sense".
The main problem with the book is that the examples and code snippets are not well-organized, if not misleading. There are quite some times when I say to myself "this doesn't make any sense".
June 13, 2022
Great book. One that I will use as a reference and perhaps refresh on at some point.
December 20, 2023
Worthwhile but very OO-centric.
January 10, 2024
Interesting set of ideas, a book I could argue with.
January 5, 2025
Great read, especially in combination with "Tidy first?"
March 22, 2022
* Refactor mehtods to 5 or less lines of code.
* switch and else are code smells
* Only inherit from interfaces.
* “The content of a function should be on the same level of abstraction” Robert C. Martin (make sure the level of abstraction inside the method always stays the same)
“Every problem in computer science can be solved by introducing another layer of indirection.” This is exactly what interfaces are. We hide details under an abstraction.
John Carmack tweets: “Abstraction trades an increase in real complexity for a decrease in perceived complexity”—implying that we should be careful with our abstractions.
* switch and else are code smells
* Only inherit from interfaces.
* “The content of a function should be on the same level of abstraction” Robert C. Martin (make sure the level of abstraction inside the method always stays the same)
“Every problem in computer science can be solved by introducing another layer of indirection.” This is exactly what interfaces are. We hide details under an abstraction.
John Carmack tweets: “Abstraction trades an increase in real complexity for a decrease in perceived complexity”—implying that we should be careful with our abstractions.
September 1, 2022
I liked the idea of this book, giving some guidance on how to refactor code safely, even without unit tests. The main code example (a simple game written in TypeScript) was useful, and I followed along with it fully, going through all the refactorings and committing it to my own git repo as I went.
Overall, I agree with a lot of advice from this book, but some of it seems wrong to me. I won't get into details on that. I did learn a bit from this book, and it gave me some good practical ideas that I can apply to my own code.
Overall, I agree with a lot of advice from this book, but some of it seems wrong to me. I won't get into details on that. I did learn a bit from this book, and it gave me some good practical ideas that I can apply to my own code.
October 2, 2024
I had to give up half way. The first half had some good advice. However, the code examples were getting harder and harder to follow - both in terms of complexity and in terms of appeal to general audiences. I would be surprised that most engineers have enough context or interest to follow through code samples about games.
I would like to see a more general theme like refactoring an enterprise CRUD applications.
I would like to see a more general theme like refactoring an enterprise CRUD applications.
Displaying 1 - 15 of 15 reviews