A while back Samuel Goodwin left a commit message of "Boyscouting". When I asked him about the commit he reminded me of a rule from the Boy Scouts:
Leave it better than you found it.
Applied to development, this meant eliminating dead code, removing comments, and standardizing format. Samuel did this before he made changes.
Since then, I have tried to follow this practice. It requires discipline. Not only in routine, but in restraint. It's tempting to add other changes to your "Boyscouting" commit.
It is important to understand boyscouting does not change code, only cleans it. Boyscouting is not refactoring. Boyscouting is not fixing bugs.
When in doubt, see if your boyscouting passes this test:
Would reverting the commit result in code loss?
If so, then you've done more than boyscouting. Commits are cheap. As shown in the screenshot, separate changes into their own commit.
Practicing something as simple as boyscouting not only improves the codebase, it improves my development. I no longer waste time on dead code or fixing formatting. Instead I can focus on making changes and use any extra time to improve the code further.
Share the practice of boyscouting with others as Samuel did with me. Boy Scout your code!
Want to learn more of these practices? Check out my other posts on Writing Clean Code or pair program with me to level up your skills.
Top comments (6)
This is one of my favorite software rules of thumbs. But I feel like the software industry needs an girl scout rule too. One that stands out from the official guidelines is
Which might mean that the girl scout rule could apply well to memory-constrained environments and the like.
It's a conundrum for such named rules. On one hand, I want to honor their origins. On the other, I don't like they may not come across as inclusive.
Yeah, it's delicate.
May you please provide samples of what code looks like before and after boyscouting, and what sorts of actions you taking when boyscouting code?
Yes, checkout out my "BaseCode" videos.
thanks!