Looking forward to a better StyleCop

A consistent coding style is one of the most undervalued components of a maintainable code base. Code should always be optimized for readability as developers spend far more time reading code than writing it. Having a consistent style helps here because it establishes conventions and locations for well known programming elements.

When taken individually items like the naming of fields, the position of braces, the casing of names, etc … are all small neglible issues. Any time spent debating which is right or wrong is time that could be better spent doing virtually anything else. Yet when these items are taken as a whole they serve to create a dialect within the language.

Just as it’s hard to understand someone speaking in a dialect that differs from your own, it’s hard to read code that significantly differs from your dialect. Or at the very least, it slows down the reading process. You’re looking in the wrong for the wrong name pattern, searching for where fields are defined, looking for the wrong naming pattern, etc … The structure of the code is constantly distracting from what it is actually doing.

This gets even harder as the number of styles within a code base increases. Juggling two styles is annoying but once you’re juggling five it’s a real hamper to productivity. Code bases with no enforcement end up with as many styles as there are developers. It only takes a few years before that number gets into the teens and the code is as messy as a college dorm room.

Coding styles help prevent this by adding a level of consistency to a project. It makes the transition between files as smooth as possible because it lets deveolpers focus on what the code is saying, not how or where it is saying it.

A coding style though is worthless unless it is ruthlessly enforced. Developer diligence is simply not a good method of enforcement here. Coding styles can be highly contenious issues and having to constantly square off over them on code reviews and with new hires is a mentally draining activity. Over time even the diligant developers wear down and the code once again begins to devolve into individual preferences.

This is why I’m an unabashed lover of StyleCop. It is simply the best tool around for defining and enforcing style guidelines in a code base. It can be run on the command line, in the IDE and as a part of a checkin verification system. This removes the need for developers to constantly square off over the issue. Get the style right or your change simply won’t pass the necessary tests.

As much as I like StyleCop though I’m enormously frustrated by it when I have a build fail because:

• Didn’t add a space between an if and a (.
• Had an extra newline at the end of the file.
• Put a brace on the wrong line.
• Namespaces weren’t sorted correctly.

All I wanted to do was F5 my latest change and see if it fixed the bug I was working on. But before I can test out a functional change to the source tree I need to spend a few precious minutes making style edits to my code. Why is this silly style issue blocking me from testing my change???

I find annoynances like this are often the root of opposition to adding style enforcement to a code base. Developers are fine, even if it’s reluctantly, with having a coding style. What they dread is constantly fighting the tools to get their job done.

And they are right to feel that way. Fixing style issues is a tedious, repetitive task. Changing the code to be in conformance to the style is needed is easily automatable. We should be relying on tooling here, not manually intervention by annoyed developers.

Many of the fixes to style violations don’t require complex solution wide analysis; just a parser and code generation API ¹. These changes amount to little more than code formatting. The IDE is constantly formatting my code as type, it should be fixing my style violations at the same time.

What I don’t want is to see fixes move into smart tips. Initiating that type of fix still requires manual intervention on my part. Just fix the code without even bothering me:

• Save a file: fix the style violations as a part of the save.
• Close a method brace: fix the style violations just like you’d format the method.

Not all style fixes are simple enough to be done implicitly. Those more explicit ones could be done in batch via an explicit IDE command. Or from a command line tool that runs over a solution.

This is where I believe style enforcement tools need to go in the future. They absolutely must keep their checkin enforcement capabilities. But they should also evolve so style conformance is as automated as possible and those checkin tests are rarely, if ever, hit during normal development.