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?"
Just one rule about coding in c#:
Don't.
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
Learn to use Visual Studio.NET. It will do everything you want it to. Don't worry about tabstops, etc. because it does stuff like that for you. Some helpful shortcuts:
/// = When used a line above functions, events, etc. it will autogenerate the XML based comments
CTRL+[SPACE] = Type ahead
I used to program C# with UltraEdit before my company could afford VS.NET. VS.NET paid for itself the first day that I used it because it saved me so much time.
If you have the time, I'd highly recommend reading the C# language specification.
THERE IS NO DATA. THERE IS O
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]
> and since I'm new to the technology (isn't everyone?)
;-)
Used Java?
Having an IT guy come up with coding standards is like asking the janitor to design an operating system.
(The fact that he's consulting with Slashdot regarding aspects of his job is kind of a hint.)
You might want to look at what Microsoft has published about standards first, use that as a foundation
= /library/en-us/cpgenref/html/cpconnetframeworkdesi gnguidelines.asp
http://msdn.microsoft.com/library/default.asp?url
There are a set of notes towards a set of C# conventions at http://www.xoc.net/standards. RVBA has long been the most widely used set of conventions for Visual Basic. The new conventions take into account the features of C# and .NET.
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
http://www.gotdotnet.com/team/libraries/
.NET assemblies for conformance to the .NET Framework Design Guidelines . It uses reflection, MSIL parsing, and callgraph analysis to inspect your assemblies for more than 200 defects in the following areas: naming conventions, library design, localization, security, and performance (see rule descriptions). The package includes both GUI and command line versions of the tool, as well as the SDK to create your own rules.
This very useful program is a code analysis tool that checks your
I have no idea. I was aiming for funny!
Linux : Mac
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.
It is VERY nice to see people being helpful; and not just making cracks because C# is a Microsoft product.
I think with the interesting people, their lives can't possibly be wrapped up into a nice little package.
I wasn't going to comment on this thread, not being particularly informed on C# itself, but two things have struck me that might be worth mentioning.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I was thinking that functions can only modify their own local variables, and must return a value. Procedures may modify the object's instance variables(or class variables), as well as their ownn local variables, but may not return a value.
Sort of...
class A {
private int foo;
public void setFoo(int foo) {
this.foo = foo;
}
public int getFoo() {
return this.foo;
}
}
Rather than...
public int setFoo(int foo) {
this.foo = foo;
return this.foo;
}
We need a moderation for Sarcastic!
I've thought about this as well. The problem is would it +1 Sarcastic or -1 Sarcastic? I think it should be something along the lines of +1 Sarcastic(Funny) and -1 Sarcastic(Asshole). Or how about a 0 Sarcastic that just adds "Sarcastic(" and ")" to the original modifier name?
Just a thought.
A site that purports to be a language FAQ and yet goes thru the features one at a time eliminating those that can be misused would rule out all good languages -- all useful tools in fact.
.Net is very nice, I don't have much respect for nonsense like this.
There is some value in a list of wise warnings, but that's not how this site presents itself, so I'm forced to conclude that it's just another anti-MS propaganda piece.
Since the REAL story about MS is pretty nasty, yet the technology of C# and
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Be advised (warned ?) that the code written by the webforms designer is very, very buggy.
If you want to wire in custom events for custom controls, or you just like to code your ascx controls in the source view (not the gui designer) then be prepared to have VS.Net intermittently decide to wipe out your event wirings.
Also be prepared to have VS.Net hijack your xml (the aspx or ascx page) formating any time you switch from source editor to gui editor.
I know this is slightly OT but...does anyone else find this "keyword overloading" (IIRR Don Box's essential .NET was where I saw this nice euphemism, or perhaps it was "namespace overloading") annoying? C# is C and C++ derived...why not use Imports (which has not been used for anyting in C#)?
SFAIK you can assign meta-data to all functions etc.. in C#.
Defing some basic meta-data that should be present.
Say Author, Data, Changes / BUGS , Links to design and test documentation etc...
It should be easy to link any good configuration management software into the meta-data.
thank God the internet isn't a human right.
For any Microsoft shop using VB6, COM, or MFC, moving to .Net is a no-brainer.
.NET, and who knows what comes next.
VB6, COM, MFC,
Healthcare article at Kuro5hin