Boy\Girl Scout Coding

When I was a young lad in the Boy Scouts, earning a total of 3 badges I believe, we had a motto when going camping. “Leave the campsite cleaner then you found it.” We always did, and I still do to this day. I always thought that was a great little motto, for way more then just camping.

Everyday in our jobs we get to go into other peoples code, whether to fix a bug (my code), or add a feature (everyone else’s). When we’re in there we really have two options. Option 1, just doing what we need to do and Option 2, leaving the file a little cleaner then we found it.

Option 2 is what I like to call “Boy/Girl Scout Coding”. It’s not a full blown refactor of the file, or making massive changes that need to be regression tested but small improvements to the file that make it cleaner for others. The changes might not even be functional changes to the file, just cleaning up the area around the campsite.

I have an internal list of operations that I like to do, with the assist of ReSharper and my other extensions that make most of the changes very easy.

1. Ctrl+K,D the file.
2. Remove unused using declarations.
3. Remove commented out code.
4. Fix spelling in string literals and comments (I always have spelling errors)
5. Read comments and ensure they are still valid.
6. Add/Remove/Fix/Regorg Regions.

Using Ctrl+K,D is a great start, it is a Visual Studio keyboard shortcut for Format Document. We should all have our settings the same, or using EditorConfig to keep our settings the same. But as we know anything can happen. It’s a quick way to keep everything looking nice. I am very guiltily of leaving in commented out code, especially when I’m working from a template or another page. But once it’s checked in we can always look at the history of the file and get it back, so keeping it around it redundant.

Using the SpellChecker extension it’s really easy to fix spelling mistakes (that I make all the time) in our string literals and comments. I usually leave spelling issues in code (like variable names) the way they are as that requires more testing. I’m a firm believer in self documenting code but there are always very complex blocks of code, or hacks, that require comments, give them a once over to ensure they make sense. Finally #6, I like regions, but others may not. If they are used in a file make sure they match the coding standards and the grouping makes sense.

All the above 6 things I do for Boy/Girl Scout Coding make no, or very little, impact on the underlying IL that gets emitted and no impact on the functionality of the file. It’s just making the human readable code a little cleaner for the next developer that needs to go into the file. The time investment is very minimal (especially with extensions) and in the long run will pay dividends to the company and other developers.

This is one of the articles that I posted internally at Paylocity, but I felt is useful to my readership here as well. If you’re a developer and looking for work check out the remote (and Chicago local) Careers at Paylocity, tell them Shawn sent you!