Coding Tools Conflict With Old Coding Standards

WARNING:  This is not a jab at Lowy‘s Standards, I’m just picking on his stuff.    So don’t take it to heart, it’s just code. 

So I’ve been creating tips o’ the day recently and I started reading through some of Juval Lowy’s C# Coding Standards.  I’m a follower of Microsoft’s & the Code Analysis/FxCop school of code creators.  I also tend to follow the idea that if it is generated, it should generate to specification with no bad code in there.  Sometimes I let things slide if the code base is really trustworthy, such as the Enterprise Application Blocks.  The reasons are long that I go by current code standards, the main reasons boil down to plain, cold, hard cash.

The simple fact is, if you don’t follow current standards it exponentially makes it more difficult to use all of the code generators, shortcuts (like ReSharper), and the legion of tools that are available for enhancing one’s ability to create good code.  While I was digging through Lowy‘s Coding Standards from IDesign I noticed a few standards that I have issue with.  If for any other reason than it costs more money, because it takes time to make changes to the tools, and thus, time is money.  Every machine one has to touch using standards that deviate from tool usage is lost time.

I know, I know, you’re probably thinking, “Adron!  How insanely obsessive compulsive!”  Yeah, well, I am.  It makes me good at what I do, it also makes me entertaining when I speak, drink, or randomly start conversations.  Let’s take a few examples just to prove my point.

In Lowy‘s Standards Document #4 is “Prefix private member variable with m_.  Use Pascal casing for the rest of the member variable name following the m_.“

public class SomeClass { private int m_Number }

The sample above is all fine and dandy, but seriously, why go old school C++ and use the m_ when one can just use the current Microsoft P&P Code Analysis/FxCop standard of just “number” or “someNumber”?  Because if you use m_, you have to alter your ReSharper template and when generating documentation it confuses some tools and in general, and when generating document it appears busy as if to add complexity where none is needed.

#20 is another item that just doesn’t really work.  It states “All member variables should be declared at the top, with one line seperating them from the properties or methods.”  This one I don’t have “that” much of a problem with, but there is a serious issue.  If you have a bunch of private members, do you know if you’ve created the appropriate respective public properly getter and setter?  Can you easily use the “prop” macro function that will allow you to generate the private and public property and all that is left is merely filling in the member name, type, and public property name?  Does it simplify what ReSharper does?  My simple rule of thumb is that you do what makes since for the file.  If you do heavy ReSharper and gen the properties then do split them as Lowy says.  But if you don’t have ReSharper than be sure to keep the private member with the public property it is for.  It is easier then to find your member and its associative property.

The last one I’m going to harp on is #10.  When doing Agile and TDD there is major emphasis that the tests are documentation.  “Use extensive external documentation for API documentation.” is somewhat counter to a live, actively changing, and readily maintained system.  I tend toward the TDD and tests are documentation approach because of the larger return on the investment developers get from this.  If the product is a software tool for other software purchasers, then yeah, create API documentation.  Otherwise keep a minimal amount of API documentation and test, test, test.

But I must say, in the end, the Lowy Standards document is some great stuff.  If you aren’t following extensive standards as he has laid out, his or Microsoft’s or whoever’s, it doesn’t matter.  To create great software one has to have good standards in place.  To have good change management and good process (Agile or otherwise) one needs good standards.

So hats off to Mr. Lowy, great job.  I just don’t agree 100%, but we wouldn’t be very good developers if we didn’t disagree on things sometimes.