On Inner and Outer Using Directives

Once upon a time, I enforced code quality for a financial system developed by a team of more than forty programmers. My primary concern in this particular role was to ensure the checked in code actually compiled. We had a continuous integration server that alerted the entire team when something went wrong, so it was only a priority when the build went red. This was before gated check-ins became popular, and before I took this role, a breaking build actually set us back an entire day.

Consider how much money was lost due to forty stuck developers. Now consider the impact on other teams such as quality assurance.

I redesigned the build system to prevent this sort of catastrophic failure, and I ended up owning it. I was then able to implement continuous delivery and other mechanisms to grease the software-producing machine.

Surprised

One day, while working on a script, a check-in caught my eye. I was accustomed to the default item templates in Visual Studio, and I never considered the possibility before me.

For reference, this is the result of creating a class with the default template.

Sure, it was a little different back in those days since LINQ was still a sparkle in the eye of Cω. Here’s how the code looked in this particular developers’ check-in, using the above empty class.

There were using directives inside the namespace! I nearly spilled my chai latte.

I noted the responsible developer before journeying through the cubicle maze to his desk.

“Hey, I saw your recent check-in. Why are your using directives inside the namespace?”

He responded, “That’s how Microsoft recommends you do it.”

I then asked him to change it back. Even if it was the recommended style, none of the other files in the entire project used this convention.

Of course, I found his usage and reasoning curious, so I had to look into it.

Guidance Wanted

I uncovered guidance for inner using directives in Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, then in its first edition. I also discovered StyleCop, which is useful for enforcing and reporting violations of the rules contained in the book.

I had already implemented FxCop to analyze the code as part of the build process, and I wanted to see if StyleCop could provide as much value to us as FxCop proved to be.

Note: Microsoft has since removed FxCop as Visual Studio now includes its functionality. To obtain FxCop, download the Windows 7.0 SDK.

It wasn't long before I abandoned the idea as unviable for this particular project. It was hard ensuring even 80% code coverage in the unit tests. It was harder to cut down on the amount of FxCop warnings. It would be impossible to manage the tens of thousands of StyleCop issues.

Guidance Found

I cultivated an appreciation of uniform code in large projects as it facilitates shared ownership. I've been on many Frankenstein projects in the past, and there were always subsystems no one wanted to touch. Perhaps worse, there were often subsystems selfishly held by one developer. Style is important for team projects because consistency is important for team project.

For my own projects, I adopted many of the conventions from Framework Design Guidelines, including placement of using directives within the namespace.

Cutting and pasting using directives to achieve consistency in your source code is annoying. Luckily, another connoisseur of code style, Chad England, felt the same way. He created an extension for JustCode to provide a warning and quick fix for outer using directives.

If you would like to try it out, simply open Extensions and Updates in Visual Studio, click on the Online dropdown, search for JustCodeStyleFormatExtension, and then click Download.

 

You can also download this extension from the Visual Studio Gallery or view the source code on Chad's GitHub.

JustCode, Your Way

Not everyone wants this particular quick fix. After all, the default templates don’t even support the guidelines it is enforcing. Nevertheless, Chad’s quick fix is optional, and it illustrates why we opened up the JustCode API.

We add features to JustCode that appeal to the broader audience. Unfortunately, features for a narrow audience can have a much larger impact for an individual. If you find yourself in need of one these, you can add it to JustCode yourself! Here’s how to get started.