Slashdot Mirror
Coding Standards for C#?
infinite9 asks: "I've been given the task of writing the coding standards for my corporation. I've been in IT for 12 years, so many things are obvious. Recently though, my employer has standardized on C# and .NET, and since I'm new to the technology (isn't everyone?) I'm not sure what to include. I've included a paragraph about signing assemblies with a standard key pair as well as a few other odds and ends. Apart from the obvious statements that apply to any language like good comments, good variable names, and maintainable code, can anyone suggest other C#/.NET related things that I should include?"
use an abstraction layer and your code will be portable (maybe) to gtk#
Before adopting WHATWG, read the moonlight.NET EULA [http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx]
Of course the problems with this approach is that it's way too easy to use the IDE as a crutch - especially Intellisense. One day you'll be in a situation (like a technical quiz for an interview) where you won't have these tools available, so unless you're paying attention you won't know what to do.
Now this is not to say that IDE's are bad - we all use them. But be aware of what you're doing - commit to memory the notion of what event handlers you're really writing code for.
Also, VS.net writes part of your code for you as part of the interface design - this is hidden (collapsed) by VS.net into a region - something like "Forms Designer Generated Code". They're correct in telling you in the comments not to touch it, but do open it up and look at it every once in a while, both because then you'll see the behind the scenes stuff (something VB6 wouldn't let you do) and because that stuff is written with Microsoft Best Coding Practices in mind, so it's clean to look at and study.
Schnapple
It's easy to abbreviate code with lots of Using statements. However, this obfuscates code, since there are several thousand classes scattered across numerous namespaces. Plus there's no different in byte code between explicit naming and abbreviated naming combined with Using statements. In our group, even the folks originally opposed to all that extra typing have now adopted this style, just for readability. One more thing: After using doxygen for the past year, I view Microsoft's xml tags a distant second. The latest doxygen 1.3 candidate does a fairly decent job with C#, and the resulting documentation is much more informative than Microsoft's. Just my two scents...
In looking at MS's design guidelines, I'm struck by how big the learning curve appears to be.
One of the main ideas behind guidelines is supposed to be that consistency will result in more programmer productivity because the programmer will recognize new aspects more quickly.
The question is: Does the time it takes to learn the guidelines so they are second nature exceed the time saved by avoiding a lookup of a function or having to come up with your own name?
Guidelines are an engineering product just as much as code, and as such, they should be subject to the same cost/benefit tradeoff as anything else. I wonder how often in practice this analysis is actually done.
I think it's pretty funny, yet deadly serious... They go through each feature of C# and end up concluding that you should avoid them all.
C# Best Practice: Do not use boxing and unboxing
check it out here:
csharp faq
When developing your coding standards, categorize the "rules" into three categories: recommended, guidelines, and rules.
Recommendations are really just suggestions. For instance, the last coding standards I helped to author we recommended that open brackets (the '{' character) be placed at the end of the expression rather than on a separate line. This recommendation was not followed by some, but it really isn't that critical towards code readability. For the record, I actually like putting open brackets on new lines, so that the open & close brackets line up. I did change my practices, but I occasionally forgot, and didn't get yelled at since it was merely a "recommendation".
Guidelines are "rules" to be followed at all times unless there is a really good reason not to. For instance, we had a guideline that instructions should not be divided between lines, and that only one instruction should appear per line. Well, if you have a really long piece of logic, splitting the instruction across two lines makes sense. Conditional expressions (i.e. something of the form of "(ab)? a : b") counted as a single instruction.
Rules must be followed at all times. For instance, one rule we used was no "goto" statements. Pretty simple and obvious.
We found that by having the rules in this form, people that would categorically reject some of the guidelines under different circumstances were more receptive towards the guidelines when presented in this manner. So long as they weren't forced to adopt these "rules" they somehow seemed less ominous. YMMV.
--Be human.
Well, that is a pretty good point. The person creating the standards should be a Configuration Manager/CM Level III type; or a similar position, whose job no longer includes coding - a strong technical writing background is likely a job requirement here. I once worked for a very senior programmer and my duties consisted only of testing software; putting together installers and distribution media; and documentation - which included coding practices for the junior developers. Nice thing was the senior developer not only gave guidance but followed a lot of my suggestions.
I think with the interesting people, their lives can't possibly be wrapped up into a nice little package.