Lance's Whiteboard

Random scribbling about C#, Javascript, Web Development, Architecture, and anything else that pops into my mind.

News


Creative Commons License
Lance's Whiteboard Blog by Lance Hunt is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at weblogs.asp.net



Sponsored Ad
Sponsored Ad

Blogs I Read

Update: C# Coding Standards v1.13

You can now download version 1.13 of my C# Coding Standards for .NET.

I havent posted on this topic for a while, so here is the change log since v1.09:

 

1.10

05/25/2004

Modified naming conventions for Internal and Protected identifiers.  Added, modified, & removed misc rules.  Corrected grammar, code, and some verbiage.

1.11

06/08/2004

Modified formatting.  Restructured “Language Usage” section.  Corrected language, and added code examples.  Consolidated conflicting rules.

1.12

06/30/2004

Modified code commenting and formatting rules.  Modified various code examples.  Modified Exception Handling and Flow Control sections.

1.13

08/17/2004

Modified layout & added License Agreement.  Misc. grammar adjustments.  Removed rules on foreach vs for pending additional research.  Added rules on switch/case statements.

After my previous update, Anon and I had a lively discussion on K&R Style, for/foreach, and switch/case statements which have been felt in the latest series of changes.   So keep your questions and comments coming!  They are being seriously considered and do impact my thought process.

 

 

 

Comments

AndrewSeven said:

No direct comments this time.
The stuff from Anon was interesting.
I had to look up K&R : Just say NO. Don't make it fit in the window by removing all whitespace, do it by refactoring.

The clone trick is quite nice.

if(condition)ThisIsOK();
if(condition)
ThisIsnt();
SomeoneAlwaysTriesToAddThisCall();

This is bad, blow this thing up with a whole bunch of braces and save yourself (whoever you are) 5 paragraphs of comments.
if(condition)W();
else if(a&&b||c)T();
else if(c&&d&&f)F();
else if(o&&(f&&a))IsGoiongOn();

If code, by looking clean and clear, also looks like it needs refactoring, that is a Good Thing. Refactor it.
# August 17, 2004 10:24 PM

Lance said:

Thanks for catching the mistake to derive from ApplicationException instead of Exception. I'll correct that at once!

I wrote some of this stuff over a year ago, so there are still remnants of old thinking in there.
# August 18, 2004 10:49 AM

Lance said:

Understanding the philosophy behind K & R has always been an elusive thing for me.

My coding style generally is a very defensive one. I try to write code that is maintainable by less-disciplined developers without them getting themselves into trouble by making hard-to-find mistakes.

If you keep the mental-picture in mind of a new developer or intern trying to read, comprehend, and modify your code, then your likely to end up with things like whitespace, liberal commenting, good variable name selection, and simplified conditionals & expressions.

To me, this is a reasonable approach, to others it is sacrilege - to each his own.

I hope this provides some insight into some of my thought processes behind selecting rules, standards, and guidelines.
# August 18, 2004 11:06 AM

Lance said:

I just posted a slight revision(1.13a) that changes the comment about deriving from ApplicationException.

Thanks!
# August 18, 2004 12:21 PM

Travis said:

This is all good and all. But is there anywhere that is explained "Why" some of these standards are standards? Example: "Avoid invoking methods within a conditional expression." Ok, but why should I avoid that?
# August 18, 2004 3:59 PM

Lance said:

The rule you mention is something I discovered through years of experience. After performing hundreds of code-reviews on code from contractors, interns, and new programmers, I saw a trend where bugs were frequently introduced by such statements.

This has been especially true with C# Code written by old VB6(or earlier) programmers due to the different compiler behavior around AND and OR operators in conditional expressions. In VB6, both tests of a statement like "If..X..AND..Y..Then..." are evaluated prior to determining true/false. Yet in most other languages (like C#), the statement is evaluated from left-to-right and short-circuits the remaining expression if the boolean result is already determined by the 1st test. When VB.NET was created, this scenario lead to their creation of the notorious keywords "AndAlso" and "OrElse" which differentiate the choices in conditional operator behavior.

Why should this be a C# standard instead of a VB-to-C# migration tip?

Because it is a good defensive-coding technique that ensures that exceptions, unexpected results, and misunderstandings like the one above do not crop-up during maintenance cycles (often by other developers) when that inline method changes and adds more complex logic. To Avoid the issue, simply invoke the offending method prior to the condition and store-off the result in a local variable, then use that variable in the conditional expression instead of the inline method call.

I hope that all makes sense....
# August 18, 2004 6:08 PM

Andy B said:

Nice document - very helpful for all .net devs.
# August 19, 2004 5:18 AM

Jason Priestas said:

Good stuff! I personally perfer the 1TBS to conserve vertical space, but that's a matter of preference per developer.
# August 26, 2004 3:55 PM

Nick Govind said:

I am currently involved in a project at uni that involves the development of software in the C#. Am I able to apply the coding standard to our project, of course, without any legal issues arising from it?
# August 28, 2004 5:09 AM

Lance said:

Travis -

I definitely took your question as constructive and helpful. I hope that my verbose reply didnt come-off as too defensive.

I admittedly am not a formal author, trainer, or conference-presenter. I'm just a fellow developer who has strong opinions on best practices after years of seeing the good, the bad, and the ugly in development.

Most of these rules come from performing code-reviews and are just automatic to me these days. I'm definitely looking at better communicating the reasons, assumptions, and potential solutions to each rule. Also, I have played a bit with turning the doc into a set of FxCop rules, but havent made much progress.

Keep your feedback coming, its all good!
# August 30, 2004 11:03 AM

Travis said:

The FXCop rules would be a GREAT addition!
# August 30, 2004 12:31 PM

Avoid using foreach with string arrays ??? said:

I don't know of any reason why we wouldn't want to use foreach on string arrays specifically.

Can you give some explanation on this topic?
# August 31, 2004 9:54 AM