Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
Noted software expert Robert C. Martin, presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin, who has helped bring agile principles from a practitioner’s point of view to tens of thousands of programmers, has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of software craftsman, and make you a better programmer―but only if you work at it.
What kind of work will you be doing? You’ll be reading code―lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly you will be challenged to reassess your professional values and your commitment to your craft.
Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code―of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.
Readers will come away from this book understanding
- How to tell the difference between good and bad code
- How to write good code and how to transform bad code into good code
- How to create good names, good functions, good objects, and good classes
- How to format code for maximum readability
- How to implement complete error handling without obscuring code logic
- How to unit test and practice test-driven development
- What “smells” and heuristics can help you identify bad code
This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
I’ve heard a lot of people dunk in this book for being “outdated” why examples in an older Java style, but I think the premise is just as valuable today as ever.
I don’t know what part of the book could possibly be described as outdated, specially as it’s not even focused on Java at all.
Also, the book covers guidelines such as how to name variables and how to write functions/methods to be readable.
The only advice I frown upon is the recommendation to use exceptions for basic error-handling, and it’s fundamentalist approach to the don’t-repeat-yourself (DRY) principle when it’s premature enforcement causes far more problems than the ones it solves, particularly in inadvertently tightly coupling code that is only bears a surface resemblance.
A lot of people die on the hill of hating strongly typed languages as well.
People who write hard to understand and thus difficult to maintain code without possessing some self reflection skills will say anything negative they can about this book.
When having to declare something is a string or int or bool or whatever triggers people, then certainly having to stick to best practices (as deemed by the author), such as the single responsibility principle, is going to be nightmare for their habits.
Clean code is ultimately a treatise on how to not be a dick while working as part of a team.
It also reinforces this notion that software engineer has a craft component which really seems to rub some people the wrong way.
I’m one of those who think this book is outdated (or at least needs an update remain a “must read” for people working on software). The blog post linked as a top level comments does a good job of pointing out some of the problems. That’ not to say it’s worthless, but if we are going to recommend books to newcomers, they should reflect the state of the art understanding of the field.
When it comes to craftsmanship, I also oppose Uncle Bob. Again, it’s not because what we do doesn’t have an element of craft in it, it’s because the concept of craftsmanship is not enough to explain what we do. Dave Farley does a great job of explaining the reasons in his conference talk: Taking Back “Software Engineering” – Craftsmanship is Insufficient • Dave Farley • GOTO 2022. We are not in the middle ages any longer, we need operate like an engineering discipline.
I’m not sure you realize how “engineering disciplines” operate as crafts.
Some engineering fields might be bounded by tons of regulations and standards and specifications, but that does not remove the craftsmanship from the problem domain. At most, those surface design requirements and convert them into hard design constraints, but that does not get rid of the need to go beyond those and leave our mark in terms of subjective definitions and measures of quality.
Also, these comments on “operate like an engineering discipline” are mostly sourced from a cargo cult mentality, where mindlessly mimicking the surface-level aspects of the things they try to emulate is perceived as being key to achieve their perceived qualities. However, software is not bound by most, if any, of the requirements that other engineering fields must adhere to. It makes no sense to presume that a solution that rose from a very specific set of constraints applied to a very specific set of problems will also be adequate for an entirely different problem subjected to entirely different constraints.
From the comment you are replying to:
I have nothing to say to this. Have a nice day.
Having elements that arguably don’t fall within someone’s personal definition of craftsmanship does not mean it’s a craft where craftsmanship is critical.
Lack of merit in one’s personal beliefs does that.