Automotive Deals HPCC Amazon Fashion Learn more nav_sap_plcc_ascpsc Jake Owen Fire TV Stick Handmade school supplies Shop-by-Room Amazon Cash Back Offer angrybirds angrybirds angrybirds  Amazon Echo  Echo Dot  Amazon Tap  Echo Dot  Amazon Tap  Amazon Echo Introducing new colors All-New Kindle Oasis AutoRip in CDs & Vinyl Segway miniPro
Customer Review

163 of 167 people found the following review helpful
5.0 out of 5 stars Applying the Boy Scout Rule..., September 23, 2008
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!
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No

[Add comment]
Post a comment
To insert a product link use the format: [[ASIN:ASIN product-title]] (What's this?)
Amazon will display this name with all your submissions, including reviews and discussion posts. (Learn more)
This badge will be assigned to you and will appear along with your name.
There was an error. Please try again.
Please see the full guidelines here.

Official Comment

As a representative of this product you can post one Official Comment on this review. It will appear immediately below the review wherever it is displayed.   Learn more
The following name and badge will be shown with this comment:
 (edit name)
After clicking the Post button you will be asked to create your public name, which will be shown with all your contributions.

Is this your product?

If you are the author, artist, manufacturer or an official representative of this product, you can post an Official Comment on this review. It will appear immediately below the review wherever it is displayed.  Learn more
Otherwise, you can still post a regular comment on this review.

Is this your product?

If you are the author, artist, manufacturer or an official representative of this product, you can post an Official Comment on this review. It will appear immediately below the review wherever it is displayed.   Learn more
System timed out

We were unable to verify whether you represent the product. Please try again later, or retry now. Otherwise you can post a regular comment.

Since you previously posted an Official Comment, this comment will appear in the comment section below. You also have the option to edit your Official Comment.   Learn more
The maximum number of Official Comments have been posted. This comment will appear in the comment section below.   Learn more
Prompts for sign-in


Track comments by e-mail
Tracked by 3 customers

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
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
Sally says:
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
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
Reppen says:
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
Don says:
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 ›

Review Details