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?"
It's 10 PM. Do you know if you're un-American?
Don't attempt to come up with any of your own formatting rules (as much as it's tempting to make your code look like the rest of your code)... having a standard formatting implemented by the IDE results in much cleaner formatting and will ensure that the people you hire will understand the code that much sooner.
To work out some standards use what you know from Java, Python or any other language with a C based syntax.
The guys at ICSharpCode (http://www.icsharpcode.net/TechNotes/) have some nice documents on coding styles/standards for coding for #Develop (you don't have to follow them when coding using #Develop)
Also have a look at something like FX Cop from MS (http://www.gotdotnet.com/team/libraries) to help enforce coding standards.
t
I would also stress: use the inline documentation stuff a log (/// comments). Use NDOC to generate documents from the XML output. Make use of the using() {} statement to encourage early resource disposal.
It doesn't really matter what coding standards you implement, as long as something consistent is used. And that doesn't really matter much either.
Microsoft will probably innovate a new language syntax soon, my guess would be C##. It will undoubtedly be more scalable, secure, robust and less prone to errors. And it'll automatically be included in the latest version of Windows, but not be compatible with previous versions due to architecture limitations.
Personally, I'm holding out for that version. I'm going to push my company to standardize on that version. Because it just makes good business sense.
We need a moderation for Sarcastic!
Maybe you'll find this useful: White paper on resource management in components written for the Common Language Runtime (CLR).
-jk
> and since I'm new to the technology (isn't everyone?)
;-)
Used Java?
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...
Make sure you recommend CVS, or some other type
of versioning system to save hell down the road.
Enforce under penalty of death or termination of
employment that DOCUMENTATION IS PART OF DEVELOPMENT.
I've had many a contract where I've basically just
had to say "screw it" and redo a rats nest of
undocumentated code because of zero documentation.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
....several other readers. Take a look at FxCop.
It will help you check your code for conformance to design guidelines and point out possible usage errors, localization issues, security problems, and possible performance improvements.
A complete coding standard is difficult to come up with in one shot. Also, developers generally have their "de-facto" standards that they like to follow, so getting buy-in can be difficult. Perhaps it's easier to just allow the coding standard to evolve as needed by using a collaboration facility to come up with it.
Take a look at Twiki.
Recently though, my employer has standardized on C# and .NET, and since I'm new to the technology (isn't everyone?)
.NET now is like adopting J2EE when it was at version 1.0 or 1.1. The details of the APIs aren't hammered out, yet, so a lot of code your company creates will be "legacy" very quickly--probably within one year. If you don't believe me, ask anyone who jumped onto the JSP and Java Servlet bandwagon when they first came out (before tag libraries, etc.).
I'm suprised your company would take such a high-risk action. "Standardizing" on something so new and untested is, IMO, irresponsible.
Adopting
Healthcare article at Kuro5hin
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
I was in your shoes when I was using UltraEdit and the free .NET SDK for development. I had all kinds of macros set up to autogenerate a separate xml file where my comments would be extracted from the code and placed into, while placing the rest of the 40 or so cs files into a dll and running it, etc. I thought that the color coding was help enough with programming. I'd just assumed that VS.Net was just bloat-ware like every other MS dev. env. that I've used in the past.
.Net built-in class libraries in your brain and can compile code with warnings in your head on the fly, VS.Net will greatly speed up the development process. (It's much easier to hit ".", "(", or CTRL+SPACE, than to google MSDN for what I'm looking for.) Aside from all the other features already listed, its integration with VSS is pretty seamless.
However, unless you have the entire
You really have to use it for a day to realize it's potential. All the MS marketing fluff sites don't do it any justice. Ours at work was included with individual MSDN Universal subscriptions for all of our developers. We all got to upgrade from NT and whatever development tools we were using before (VS6.0, HomeSite, UltraEdit, notepad, vim).
THERE IS NO DATA. THERE IS O
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.