re: The Boy Scout Rule VIEW POST

FULL DISCUSSION
 

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.

code of conduct - report abuse