Minimal
stressed for motivation and achievement2005-11-01
Coding standards
Last week at work, I was passed the company’s coding standard for C# and .NET. It was a Word doc, 28 (twenty-eight) pages long. It was supported by two other documents, one of them 10 pages and the other 18 pages long. Is it just me, or does 56 pages of coding standard / best practice sound a little OTT?
Worse than that, I found it disrespectful. Its excessively prescriptive nature implictly credits the developer with no common sense. How is that meant to build mutual respect, trust and team spirit? A 28 page document’s good for little more than rolling up and using to bash people over the head, IMHO.
Incidentally, I only found out there was a standard after having submitted my own. Mine was 1 page long. It said stuff like “Use FxCop,” “Turn on XML documentation” and “Format things the way Visual Studio does”. I know which standard I’d rather be maintaining, but I guess I wasted my time. :-/
BTW, if the team members use the coding standard all the time then they'll almost forget that it exists. Perhaps that's why no-one mentioned it.
: 9:10 amCoding standards are necessary, but a document that long does seem excessive. Question: Do you have code reviews to ensure the standards are being followed? They must take ages if you have to go through a large document as well as all code.
Surely the fact they are so big lowers their overall usefulness?
: 9:22 amIn my eyes, strict coding standards are ok, but you don't need a 28 page document to be strict and comprehensive and it's good to have a little flexibility for common sense, anyhow. Saying "Use FxCop" does the job nicely. Better than having a large doc, in fact, as FxCop provides automated code reviews rather than the sort of drawn-out situation Andrew describes.
BTW, I had been shown a coding standard on my first day, but it was for C++, not C#. A lot of it just didn't make sense for C# hence me writing a new standard. Sadly, no-one told me that another team already had one that I could use.
One of the main reasons I think this is a good kind of coding standard is that it says nothing at all about how you should name variables or what type of whitespace you could use. I couldn't give a monkey's about those things because I think that anybody using particularly obfuscated naming or formatting is clearly a cretin and won't get near my team anyway.
What it does say is how to design C++ code that is as reusable and as robust as possible.
Quality. :-) I nearly used that argument as a basis for only needing a lightweight standard in my original post. If you really need things spelled out to your developers, you've got problems in your hiring process.
Also, this again makes me wonder what really does belong in a coding standard and what just belongs in a recommended reading list. The standard I knocked together was more a description of a practical approach to writing the code rather than a standard per se.
Use FxCop and write Unit Tests.
<< Home
Archives
April 2002 May 2002 June 2002 July 2002 August 2002 September 2002 October 2002 November 2002 December 2002 January 2003 February 2003 March 2003 April 2003 May 2003 June 2003 July 2003 August 2003 September 2003 October 2003 November 2003 December 2003 January 2004 February 2004 March 2004 May 2004 June 2004 July 2004 August 2004 September 2004 October 2004 November 2004 December 2004 January 2005 February 2005 March 2005 April 2005 May 2005 June 2005 July 2005 August 2005 September 2005 October 2005 November 2005 December 2005 January 2006 February 2006 March 2006 April 2006 May 2006 June 2006 July 2006 August 2006 September 2006 October 2006 November 2006 December 2006 January 2007 February 2007
