I have a mild compulsion to clean up code. When i see mixed indentation (usually tabs vs spaces), I start getting twitchy. When I see star imports, places where old loops can be replace with the “new” foreach loops (thereby reducing line noise in many cases), or any of a number of different “improvements” to the code I start itching to start cleaning up. But there’s (at least) one problem: not everyone wants their code cleaned up.
For many, such janitorial efforts hide any actual functionality changes and they would prefer such changes be made in a separate commit/task. While there’s some merit to that complaint, it’s also often true that time for mere janitorial work will rarely/never get allocated. So without taking advantage of opportunities, it will never get done. Unless you work on a project that values such changes, these changes will either be made alongside functional fixes or not at all.
To resolve this tension, there are things both camps can do. If your project is open source, you could implement something like The Linux Kernel Janitor Project. This project is used as one possible entry point for beginners to begin to learn the system and make some changes without necessarily having to know enough to effect major changes. This kind of project can work in a corporate setting as well, though most companies would prefer to get some “value” from their employees as quickly as possible.
If a janitorial project is not an option, then try to grant some leeway for intermittent clean up. If code isn’t maintained, it can become so crufty over time that making actual bug fixes or functional enhancements can be difficult. On the flip side, those like me that like to get code into shape need to show some restraint and courtesy.
Sometimes its just pride that rebels against having someone else muck with “my” code that leads people to object to such changes. But in many cases, drastic and pervasive reformats or “tweaks” to code can lead to impossible to decipher merge conflicts for people doing significant changes in those files. It can be tempting (and gratifying) to do a deep clean on a file or whole sets of files but you have to consider the impact of those changes. You might have to settle for one or two things to clean up this time and catch the rest later. At the end of the day, it’s about making a working product and if your cleanups cause delays for others as they sort out what exactly you did, then you’re not exactly helping out.
Of course, prevention is the best medicine so each project should choose a set of standards and conventions. These could include a set of libraries that everyone agrees to use. This can lead to a set of standard/best practices in the project rather than everyone choosing their own favorite XML libary for their subsystem, e.g. It should certainly include code style conventions. For me, I choose the Sun conventions. There’s nothing magical about them. I like them and encourage their use. But whatever works for your team, just pick something and stick to it. This will help reduce the need in the future for large scale janitorial work.
The criteria for what is the “right” way to do things can change over time. e.g., the foreach loop is newer than most java code, I’d wager. On older code you’re still likely to see many while loops or old style for loops that could be migrated to the new style. Your team’s style/practice guidelines should be periodically reviewed and update to account for the change landscape in both language features and third party libraries. Once any changes are agreed upon, you need to prepare yourself for those changes to start trickling in. These can be done in an organized sweep and clean up of the code or piecemeal by individuals as they find them.
Either way, you’re going to want people like me in there to help.
