- Robert C. Martin's Clean Code Tip #12: Eliminate Boolean Arguments
- Robert C. Martin's Clean Code Tip of the Week #11: Output Arguments are Counterintuitive
- Robert C. Martin's Clean Code Tip of the Week #10: Avoid Too Many Arguments
- Robert C. Martin's Clean Code Tip of the Week #9: One Step Test
- Robert C. Martin's Clean Code Tip of the Week #8: Your Build Shouldn't Require More Than One Step
- Robert C. Martin's Clean Code Tip of the Week #7: Clean up Old Commented Out Code
- Robert C. Martin's Clean Code Tip of the Week #6: Avoid Poorly Written Comments
- Robert C. Martin's Clean Code Tip of the Week #5: Avoid Redundant Comments
- Robert C. Martin's Clean Code Tip of the Week #4: Avoid Obsolete Comments
- Robert C. Martin's Clean Code Tip of the Week #3: Avoid Inappropriate Information
- Robert C. Martin's Clean Code Tip of the Week #2: The Inverse Scope Law of Function Names
- Robert C. Martin’s Clean Code Tip of the Week #1: An Accidental Doppelgänger in Ruby
- What Is Clean Code?
- Designing a User Interface in C# Using the Model View Presenter Design Pattern
- UML Class Diagrams for Java Programmers
- Keeping the Code Clean
- An Exploration of Extreme Programming in Practice
Clean Code: A Handbook of Agile Software Craftsmanship
Clean Code: A Handbook of Agile Software Craftsmanship, Adobe Reader
Agile Principles, Patterns, and Practices in C#, Adobe Reader
Agile Principles, Patterns, and Practices in C#
UML for Java™ Programmers
Agile Software Development, Principles, Patterns, and Practices
Pattern Languages of Program Design 3
Sorry, this author hasn't posted any blogs.
This chapter is from the book
Clean Code: A Handbook of Agile Software Craftsmanship
The Boy Scout Rule
It's not enough to write the code well. The code has to be kept clean over time. We've all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation.
The Boy Scouts of America have a simple rule that we can apply to our profession.
- Leave the campground cleaner than you found it.5
If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn't have to be something big. Change one variable name for the better, break up one function that's a little too large, eliminate one small bit of duplication, clean up one composite if statement.
Can you imagine working on a project where the code simply got better as time passed? Do you believe that any other option is professional? Indeed, isn't continuous improvement an intrinsic part of professionalism?
Account Sign In
View your cart