re: The Boy Scout Rule VIEW POST

re: 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 unders...

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