I'm a recent AI graduate (circa 2 years) working for a modest operation. It has fallen to me (primarily as I'm the first 'adopter' in the department) to create a basic (read useful?) C# coding standards document.
I think I should explain that I'm probably the most junior software engineer going, but I'm looking forward to this task as hopefully I might actually be able to produce something half usable. I've done a pretty extensive search of the Internet and read articles on what a coding standards document should / should not contain. This seems like a good as place as any to ask for some suggestions.
I realise that I am potentially opening a door to a whole world of disagreement about 'the best way to do things'. I both understand and respect the undeniable fact that each programmer has a preferred method of solving each individual task, as a result I'm not looking to write anything so draconianly proscriptive as to stifle personal flair but to try and get a general methodology and agreed standards (e.g. naming conventions) to help make individuals code more readable.
So here goes .... any suggestions? Any at all?
Never write your own coding standards use the MS ones (or the Sun ones or ... as appropriate for your language). The clue is in the word standard, the world would be a much easier place to code in if each organization hadn't decided to write their own. Who really thinks learning a new set of 'standards' each time you change teams/projects/roles is a good use of anyone's time. The most you should ever do is summarize the critical points but I'd advise against doing even that because what is critical varies from person to person. Two other points I'd like to make on coding standards
These two points are the reality to my wish that everybody would write code that looked the same.
I disagree - so long as he creates the document, the worst that can happen is that it gets forgotten by everyone.
If other people have issues with the content, then you can ask them to update it to show what they'd prefer. That way it's off your plate, and the others have the responsibility to justify their changes.
Ironically setting the actual standards are likely to be the easy part.
My first suggestion would be to elicit suggestions from the other engineers about what they feel should be covered, and what guidelines they feel are important. Enforcing any kind of guidelines requires a degree of buy-in from people. If you suddenly drop a document on them that specifies how to write code you'll encounter resistance, whether you're the most junior or senior guy.
After you have a set of proposals then send them out to the team for feedback and review. Again, get people to all buy into them.
There may already be informal coding practices that are adopted (e.g prefixing member variables, camelcase function names). If this exists, and most code conforms to it, then it will pay to formalize its use. Adopting a contrary standard is going to cause more grief than it's worth, even if it's something generally recommended.
It's also worth considering refactoring existing code to meet the new coding-standards. This can seem like a waste of time, but having code that does not meet the standards can be counter-productive as you will have a mish-mash of different styles. It also leaves people in a dilemma whether code in a certain module should conform to the new standard or follow the existing code style.
I also follow Resharper. Also the guide line mentioned on scott guthrie blog http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net.aspx And http://csharpguidelines.codeplex.com/releases/view/46280
IDesign has a C# coding standards document that is commonly used. Also see the Framework Design Guidelines 2nd Ed.
I have recently found Encodo C# Handbook, which includes ideas from many other sources (IDesign, Philips, MSDN).
Another source may be Professional C#/VB .NET Coding Guidelines.