Three Levels of Code Cleanup

Here are three levels of Cleaning up a codebase, starting at what should be mandatory minimum, up to being a steward of your codebase.

Pitch In:  Don't check in any new garbage code.  Give yourself a code review before check in.

I know you are busy and you don't always have time for cleaning up everyone else's mess.  What I'm saying here is at least clean up your own trash.  You might not have enough time to leave it a better place, but what you can do is make sure your stuff isn't increasing the problem.

Give yourself a code review.  Before you do a check in do a compare to the previous version and see if you can see anything out of place.  Do you have any unused variables, any have excessive spacing, are there huge methods that should be extracted, is it Clean Code, is it following the DRY principle?  Yeah this is the same stuff you'd do in a code review for someone else.  As a bonus, by doing this you're actually getting practice at doing code reviews.


The Boy Scout Rule:  In addition to not adding garbage, you can pick up some litter.

Leave the codebase better than you found it.  If we all do this as much as possible the codebase will get better with time instead of becoming fragile legacy code that nobody wants to touch.

We've all had that time where we were in such a hurry to get something checked in thinking that someday somebody will come back to clean it up.  Well that day is today.  You've opened a file to make a change, before you check it in  it's time to make the file as good as possible.

This can be as simple as making sure that white space and indenting is consistent and removing unused references.  This could also be as complex as doing refactoring if something is really out of whack and you understand it.  Clean it up to make it the code you'd like to read.  Again it's like doing a code review, but on  the entirety of the files you touched.

Code Gardening - Going above and beyond and looking around for problems.

This is taking stewardship of the code.  You actively look for places you can fix problems.  This isn't a rewrite where you do it all from end to end, but it is more than just going where your tasks happen to take you.

Look around a little bit for problems and pluck those weeds.  This can be a major endeavor or just a way to make sure that as you do a go to definition and you see something out of place you fix it, even if it's not related to your current task.  As stewards of the codebase we try to make it better all the time.

Quick pointers for cleanup:

• As much as possible keep your task work and your cleanup work separate.  This makes it easier to get any accidents out of the code base.  Separate commits/check ins for clean up tasks and project tasks when possible.

• Especially if you are going to do a complete reformat of an entire file.  Do the format only and make that a check in with a comment stating that it's just reformatting and no logic changes.  Doing something like CTRL-K, CTRL-D in Visual Studio will make tracking changes next to impossible.  So go ahead and do it as a standalone check in.  Then any subsequent changes with the format in place will then be trackable.

• If there are unit tests on the code you've cleaned up, run them before checking in.  I know you'd NEVER check in without building, but running tests give you an extra layer of safety. Hopefully, you didn't mess anything up, but it never hurts to give it one more check.

• Don't be afraid to fix things.  If it's very complex make sure you get a code review, but we have source control for a reason,  we can get back to where you started in short order (especially if you've kept your cleanup tasks separate).

• Use, but don't abuse tools.  Tools like ReSharper can do a great job of doing cleanup, but you don't want to unleash them without supervision.  If you do the automatic cleanup on a directory, you may make yourself very busy trying to undo all the problems it can cause.