The Boy Scout Rule

Arun Sasidharan on May 06, 2017

Entropy /ˈɛntrÉ™pi/: lack of order or predictability; gradual decline into disorder. Entropy in physics refers to the amount of “d... [Read Full]
markdown guide
 

I completely agree with you, I have been working on code base, which was littered with sql prepared statements with the java code. But if i try to extract the statement and convert it into java callable statement, i have to get the permission of business and they start to worry whether it will break the code. Sometimes the developers get the reply it is already working, business doesn't need the developer to work on it. I can rant so much, but i think the developer need to have some freedom to refactor the code :-)

 

Have the business people got burnt in the past by devs trying to clean the code? Do you have automated tests in place that make sure if you refactor the code that you can show it still functions in the same way?

The best way to handle this is in the course of normal feature work when you have to touch the code, that is when you clean it. So then you can just roll the change in with normal feature work and do not need to ask for the time to clean the code.

 

TDD can give you the freedom to clean the code and put everyone at ease.

 

I'm a bit leary about generalizations like this. The sentiment is in the right place, but often it can be misapplied. The biggest problem is understanding what "cleaner" code actually is. There is a wide range of opinions on this. If a change is trival, why is it made at all. If it is non-trivial, then the worry about a functional change is real.

I think cleaning for the sake of cleaning is wrong. There should be a very clear goal anytime you go to refactor something.

 

I see this "no cleaning for the sake of cleaning" line a lot in contribution guidelines. But what about small changes like improving variable names, improving formatting etc? Should they only be done when you're changing the functionality of that particular piece of code then?

 

Yes, changes are best made when adding functionality or fixing a defect. Preferably prior to the fix/addition. I feel as though there needs to be something motivating the change, otherwise you might spend forever cleaning the code. The reason I'm cleaning the code is because the messiness is getting in the way of a new feature, or is the likely cause of a defect.

It's important to consider the rest of my approach though. I spend a lot of time "cleanign" prior to implementing a new feature. Essentially I try to refactor so that the new feature will be an easy addition, rather than having to hack into the existing code.

With defects, I prefer fixing underlying problems than surface issues. Cleaning code is often just the best approach here.

 

As a beginner, this rings very true. The more code I add, the more errors I encounter. It even renders working code useless when I remove the broken code. This is going to be a very difficult, and rocky learning process. I know that my faults lie in ignorance, and just having very little experience with the code I am working on. I do my best to keep the code as clean as possible for error checking, and to avoid any future issues. Maintaining order is key.

 

Nice article. I posted a similar one a few years ago entitled Are you a Boy Scout?. I think this practice is important for any dev at any level. It shows your passion for code and if you have code reviews, a great way to transfer knowledge - ultimately creating a positive feedback loop. Just be mindful not to Boy Scout everything!

 

Not a bad article/idea…but you know the Broken Windows theory has been disproven and shown to be hella racist, right? Not the best analogy to use here, particularly since you have other analogies to lean on…

code of conduct - report abuse