Engineers and bloody fools
Quibbles with Standards
Yes - that's my Red Indian name. But seriously, folks:
I just downloaded Juval Lowy's C# Coding standards from IDesign. It's very good, but you wouldn't want to adopt it wholesale. Firstly, if you read his preface, you'll find that he consciously avoids giving reasons for the standards.
"the C# coding standard presented here is very thin on the “why” and very detailed on the “what” and the “how.” I believe that while fully understanding every insight that goes into a particular programming decision may require reading books and even years of experience, applying the standard should not."
If you don't keep the reasons, you can never change the standards. There'll always be sufficient nay-sayers who will resist change by saying that in the absence of the original thinking, overturning an outdated decision is too high a risk. (I guess it's OK for an Alpha-geek like Juval, who can probably both recall the reasoning, and expect to be involved in the process.)
I'm also a little curious about his claim that the 2003 edition of the same document is now the de-facto industry standard. How could we know? For starters, large parts of it are very similar indeed to the advice given in Microsoft's own guidelines. Still - Juval is genuinely one of the giants of the industry. Maybe there's a part of the story that we don't know.
Anyway - on to some detailed points:
2.4 Avoid methods with more than 200 lines
In my development environment I get about 30 lines in view at once. So if you write a 200 line method on any project I work on, expect an argument. An entire method should be viewable with one or perhaps two invocations of the page-down key.
2.6. Lines should not exceed 120 characters.
OK - as an outer limit. Most of my code is less than 80 characters wide.
4.3.14. Never call Thread.Join() without checking that you are not joining your own
thread.
void WaitForThreadToDie(Thread thread)
{
Debug.Assert(Thread.CurrentThread.ManagedThreadId != thread.ManagedThreadId);
thread.Join();
}
To be honest, I don't do enough multi-threaded programming to even know what the problem is here. I suppose if you try to join yourself, you'll block forever. If that's what the problem is, then indeed, you want to take it seriously. In that case, a Debug.Assert isn't good enough. Unless you know in advance which thread you're going to pass in that is. Erm?...
This document is definitely required reading for any C# developer. (Listing some quibbles helped me to stay awake.) Like myself - you may not agree with all of it, but any standard writer has to reserve the right to be arbitrary sometimes. It's better to have an arbitrary standard than no standard, and there's definitely some stuff in there where there's been a choice - go this way or that way: OK - we'll go this way.
Other parts are obviously the result of serious time in the trenches, and I'll be having another read through before long to see if I can pick up the reasoning behind some things. For example,
1.14 Avoid putting a using statement inside a namespace.
Now I don't know why that is, so a little investigation is in order. Brad Abrams says you should put your usings in your namespaces. No reasoning given there, so not much help.Another prominent Microserf Eric Lippert explains his thinking and says:
- have only one top-level namespace per file
- if you choose to put using directives inside your namespaces then fully qualify them with the global alias qualifier
So to round up. Thanks for publishing your standard Juval. It's very thought-provoking, which I suppose is what you would hope. (By the way - it was very irritating to have to round-trip your pdf through ghostwriter before I could copy and paste from it. Don't do that!)
