163 of 167 people found the following review helpful
Applying the Boy Scout Rule...,
Verified Purchase(What's this?)
This review is from: Clean Code: A Handbook of Agile Software Craftsmanship (Paperback)
When you do code maintenance, you can really "love" or "hate" a person that you do not even know just by the code he or she has written. Messy code almost always goes hand in hand with lower productivity, lower motivation, and a higher number of bugs. In the first chapter, Robert C. Martin presents in a very instructive way, the opinion from very well-known personalities about what "clean code" is, and also suggests we apply the Boy Scout Rule (Leave the campground cleaner that you found it) to our code. The following chapters present practical advice about how to do this cleaning (or even better, how to avoid the mess in the first place).
The suggestions presented in the book (meaningful names, pertinence of comments, code formatting, etc) may sound very familiar to any experienced programmer but they are presented with such a level of detail and with very illustrative examples that it is almost impossible not to learn valuable things chapter by chapter. All the examples are in Java, but the guidelines they illustrate can be applied, in most of the cases, to other languages.
The most challenging chapter to read (but also a very valuable one) was the Refactoring of the class SerialDate (from the JCommon library). It is a real-life example and the author shows step-by-step what it takes to do refactoring. The last chapter, "Smells and Heuristics" makes a very good closure presenting in categories and in a condensed way, potential problems and suggested ways to solve/mitigate them.
I enjoyed reading this book and after finishing it, I decided to apply the Boy Scout Rule. I took a module written in a procedural language and not only managed to improve the clarity of the code, but also reduced the number of lines from more than 1,100 to 650. The next person to touch this code will certainly be happy to deal with cleaner code!
Sort: Oldest first | Newest first
Showing 1-10 of 10 posts in this discussion
Initial post: Sep 5, 2010 2:38:41 PM PDT
Last edited by the author on Sep 5, 2010 2:39:28 PM PDT
While it is good "for the code" to be "cleaner than you found it", your boss or manager may not think so. There probably is a balance some where there... for example, if every one in the team is 80% clean or 75% clean, and you are the 95% or 100% clean guy, you will be the person who always take 30% more time to finish things -- or remember the 80/20 rule: the last 20% of the work may take 80% of the time, but cleaning up probably take less time than that, but if you are consistently 30% slower than other people in the team, oh well, it won't work. I once want to "make a world a better place" too, but realize it is not everybody's thinking to do so, and other people won't hesitate to stomp on you to "make his life a better one."
In reply to an earlier post on Dec 23, 2010 7:33:29 PM PST
Daniel Solovay says:
The "Boy Scout" rule works well when applied judiciously. If you've spent an hour figuring out how something works, making changes that will speed the process for the next developer is helpful to the team. But these should be small changes--renaming a variable or method so that is self-descriptive, splitting a class in to a super and sub class to allow for code reuse, etc. Rewriting code for pure creative satisfaction is not agile--it has to help the team.
In reply to an earlier post on Dec 25, 2010 2:41:12 PM PST
Any boss who comes down on a developer who produces the best code in the team, but is 30% slower than others is, to be frank, incompetent. In any case, there's a huge variation in developer productivity, so a very able developer who takes 30% longer because their fixing bad code is probably still faster than half the team.
In most projects, most of the team isn't '80% clean'. Most of the team is 30% clean. The quality of software these days is largely awful, and it isn't improving.
I personally believe that the attitude displayed demonstrates a primary problem with the software industry these days; everyone is obsessed with short-term schedule, and few people care about long term maintainability or even suitability for purpose.
In reply to an earlier post on Dec 26, 2010 12:21:33 AM PST
Last edited by the author on Dec 26, 2010 12:28:22 AM PST
I think if you say 30% slower = incompetent, that may be generalizing too much. If it is bank or mission critical software, and / or if 30% slower means 50% less time to hunt down and fix bug, and do software maintenance or upgrade, then how can it be termed "incompetent". But, like the sugar in soft drinks, many people care about instant satisfaction. He won't care about what happens 2 or 3 years down the road. If he can report everything going fast and smooth consistently, he gets promoted, and later on, he leaves the company for a better position or let the managers under him to deal with the mess. He is still a director or VP, enjoying the high salary and power, which is the most important to him, vs quality of code.
In reply to an earlier post on Apr 18, 2011 3:44:04 PM PDT
Charles M. Nobles says:
There's another factor to be considered: many managers (still) measure productivity by the number of lines of code produced. If you cut the line count from 1100 to 650, why you must be not just 30% slower, but negatively productive. Better luck at your next job. This, along with ridiculous schedule pressure, is probably why the code is dirty to begin with.
In reply to an earlier post on Apr 19, 2011 1:27:05 AM PDT
I am seeing it again: when you are responsible and create clean and beautiful code, the boss just "give you more items to do, in a tighter schedule" and CLA-CHINK... the company earns more money, he has better performance review (from driving you harder). At the same time, the incapable guys, chit-chat with the boss, saying foul language together with the boss, and looking at expensive car's webpage together during working hours, become friends of the boss and they can step on you and not care. Software world is not so much about craftsmanship. It is about pure power.
In reply to an earlier post on Aug 24, 2011 7:05:20 PM PDT
Last edited by the author on Aug 24, 2011 7:10:15 PM PDT
Replace all your for loops with:
as many times as you need iterations. Original idea courtesy of an employee of a MAJOR international sweatsh... I mean outsourcing operation. Yes, I saw that in the wild. I'm dead serious.
@OP's original post: Well, obviously the logic is broken. If a clean coder is taking 30% longer the first thing a decent developer/manager should ask is: "Is s/he the reason it's not taking everybody else 30% longer?"
Programming is complicated. So is management. Sadly, managing programmers as a career has become a kind of fly paper for morons.
In reply to an earlier post on Sep 23, 2012 4:24:35 PM PDT
To paraphrase Thomas Keller,
"the great challenge [of excellence] is... to derive deep satisfaction from the mundane."
I'm not ready to give up on excellence yet, and so the only way must be to do it with pride and artistry. I cant go another way. Day Job notwithstanding.
In reply to an earlier post on Sep 23, 2012 6:46:13 PM PDT
@Erik you said "a decent developer/manager". Yes, that's the keyword. Nowadays, how many percentage of "decent" managers do you see? I think it varies by country, and vary by location. In the Silicon Valley, I am estimating out of 10, there are less than 3.
In reply to an earlier post on Jan 5, 2015 10:02:22 PM PST
If you find yourself with such a manager (a misnomer) and you have data that you fulfilled requirements with less code and they get upset with fewer lines of code, there are many better places with saner managers: what matters at the end of the day are not merely results, but correct results, on-schedule. Fewer lines of code, where there's otherwise no less error checking done, is easier to fix and maintain most times, than is overly large code that tends to be less clear. Granted, it's entirely possible to provide shorter, less-clear code that's harder to read/modify: it's always a balance.
‹ Previous 1 Next ›