C# Coding Guidelines

I’ve been in a discussion today with one of our customers on good C# coding guidelines/standards, and I confess to not having any good references to give him.

He was nice enough to send me a link to one that he thought was good, which happens to be by Juval Lowy at iDesign.

If you have other coding guidelines that you think are good, feel free to add the to the comments, and I’ll try to get them up on our C# dev center.

Comments (33)

  1. Anonymous says:

    Just asked this same question in the newsgroups yesterday, here’s an answer I got:


  2. Anonymous says:

    If you install SharpDevelop.

    GO TO Menu

    Help.Coding Style Guide

  3. Anonymous says:

    I’ve heard Lowy’s is good, too, but haven’t checked it out yet. Here’s my favorite so far: http://www.tiobe.com/standards/gemrcsharpcs.pdf

  4. Anonymous says:

    I am surprised you didnt think of FxCop.??? As an employee aren’t you supposed to perfectly cognizant of every single MS application on the planet? 🙂

    Granted FxCop doesnt "give" you the guidlines as much as they enforce them, but it can be really useful tool with formulating your own standards to adopt.

  5. Anonymous says:

    RE: the iDesign doc, I have a few comments and some questions.

    1.4. "Prefix private member variables with m_". I dissagree. I agree with all his other naming conventions. However, in private members, I prefix with _ or they are all lower case. Again, its a standard so if everyone agrees than there is no confusion. I’ve never experienced or witnessed any. But m_ is ugly.

    1.22. "Always place an open curly brack ({) on a new line.". Nope. I personally find code much easier to read when the brace is at the end of the first line rather than a new line. As lost as the code is neatly indented I’ve never experienced trouble determining where it originated nor has anyone who ever read my code. I can’t stand to see too much white space and an open brace really creates white space. Of course, I can’t stand to sufficate, either. I have a very strict standard I adhere to that revolves mostly around balancing the right amount of breathing room and content.

    2.4. "Avoid Files with over 500 lines." While I can see some merit in that, sometimes it is just not feasible to do so. I’ve heard people say that it should then be refactored, but there are some occasions where a file will just get to be large. It should be avoided if possible. And while yes, by breaking everything up to different classes can greatly reduce the number of lines, there are things that can’t be broken up. For example, I create custom WebControls. Some of them can’t be broken up and will inevitably take more than 500 lines (in my case, even 2,000 lines.

    2.5. "Avoid methods with over 25 lines." Again. a good thing to strive to achieve, but it isn’t always feasible. I have a method that needs to do do some prep, make a few database calls, do some more prep and then return. While most of the method is already broken up into other methods for general re-use, this method in particular can be no more reduce and is still well over 25 lines. I always strive for the least amount of code but pleny of times I’ve found, it’s not always possible. Back to custom WebControls. Just to render a custom Calendar, even when I severely break up the functions for internal re-use, is still over 100 lines of which are necessary to be there. Okay, "refactor" you say. Not always possible. Time, budget, etc.

    2.6. "Avoid using methods with over 5 arguments. Use structures for passing multiple arguments." Okay, I see that many API’s do this. Is this standard practice? I’ve always opted for being able to see the argument list in the function defenition so I know what to pass. Would a structure be as easy or easier? Because then I would need to add more lines of code (on top of the 25 lines requirement) just to pass into another function. What do you say about this, I have no real thoughts.

    2.22… I have no thoughts, but I don’t know I agree or not. Perhaps someone can elaborate why. What advantage is there, except that sometimes (but not always) you may need to use that result again somewhere in which case I understand, but is this just a matter of always preparing for that?

    2.27… I learned something new with this one. Never thought of that before but it makes sense. Didn’t know it can be done.

    2.42. "Avoid events as interface members." I have an ADO.NET wrapper class that has the ability to load plugins for debugging purposes (has saved countless hundred of man hours to just plugin get feedback and plugout when done). In order for this to work, I need to have the interface define some events that the plugin will bind to. The DAL does not reference a plugin but the plugin only knows about the interface and not the wrapper object itself. So in this case, this rule has to be broken.

    2.52… not always feasible. I used a structure for a binary datatype I created that encapsulates 8, 16, 32, or 64 bit binary operations and overloaded all the members but I couldn’t find an operator for the ROR/ROL so I had to provide methods. Search planet-source-code in the .NET second for "Shawn Bullock" if you’re interested in seeing it.

    … no more comments in this post. Everying in sections 1 and 2 not mentioned I agree with an practice mostly.



  6. Anonymous says:

    Coding standards like that one should have a disclaimer, as follows: "This is what we do here. Many of these rules were chosen arbitrarily, purely because SOME standard is better than none at all. If our rules disagree with the ones you prefer, it’s nothing personal. While you work with us, use our rules. After you’ve gone, go back to your own standards. The time you spend betraying your own religious beliefs will not, in fact, make your genitals shrivel or your hair fall out."

    Oh, and as for the 25-lines-to-a-function rule: forget it. Just require that before any programmer starts working with you, he or she spend time maintaining code written in Forth, LISP or Perl. If that doesn’t teach them to write short, simple functions, there’s no hope for them.

  7. Anonymous says:

    At some point in breaking down a larger function into smaller functions just to keep it less than n lines of code, you are then just adding function after function to your class and not all of them are reusable functions. I prefer to take the road of as much reusability as possible. I don’t want my objects being poluted with non-reusable methods just for the sake of it. I break it up where it makes sense and not because there is a hard defined rule that says 25-lines-or-less. I may come across as being a sloppy programmer, but I am highly disciplined and have never experienced a person being confused over my code.

    The bottom line is standards are necessary. But putting a standard on certain things are just plain rediculous. Instead of requiring 25-lines-or-less, instead require the developer to "strive" for 25-lines-or-less-or-as-little-as-is-necessary-if-it-exceeds-25-lines.

    Anyway, I’m not being hung up for over it. I’m simploy making an observation, that some standards can get in the way and should be more of a guideline than a concrete rule.

    And what was that comment you made about betraying religious beliefs and so on? Was that necessary? All it did is remove any credibility in your comment that you had until I read that part.



  8. Anonymous says:

    Woo, Shawn, you’ve never gotten into an argument about the One True Brace Style, have you?

  9. Anonymous says:

    Eric, no I haven’t, because that’s just being rediculous at that point. Brace on the same line or below, isn’t something to argue about. It’s subjective, although I find, if I put it on the line below, it takes another lines and counts towards my 25-line limit 😉 But again, the 25 line limit is just rediculous as a concrete rule rather than a guideline.

    I take it you have argued it, or are you just trying to pick a bone with me?



  10. Anonymous says:

    The guidelines are a mixture of obvious, thought provoking and wrong-headed. More explanation would be interesting. (I’ll take a look at his book.) A little humour would leaven the fascistic tone of some of the rules. No line longer than 80 characters? Here’s a rule for you: Stop using that key-punch machine!

  11. Anonymous says:

    Food for thought: http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=336, cited above,

    says use tabs, not spaces but the topic of this comment says use spaces, not tabs. That’s why some more written justification for these "rules" would be helpful.

  12. Anonymous says:

    Shawn, it looks like we’re 100% in agreement. They ARE inane, all those hard-and-fast rules with no escape clause. I think Joel On Software has an article talking about line-per-function limits where he says that people who are forced to stick to the limits end up just breaking their hundred line "int foo(void)" into "int foo1(void)", "int foo2(void)", etc and calling it all with "int foo(void) { return foo1()+foo2()+…; }" Which is NOT what you want.

    My point about the arguments is that they do become stupid. People fight holy wars over the amount of space before and after the "(", and there have been permanent fallings-out over the correct size of a tab indent. Forceful language like I suggested is one way to get these hard-core loonies to pay attention: you have to remind them that IT DOESN’T MATTER, and they can always go back to their own style later.

    If you forget to put in a disclaimer, then as soon as the loonies read, say, that private function names must use CamelCaps, or the Tab key should be avoided, they’ll just say "rubbish" and ignore the whole document.

  13. Anonymous says:

    FYI, there’s a new Version 1.81 dated January 22. As the version number indicates, it’s a small change from 1.8.

    It’s available at http://idesign.net/idesign/download/IDesign%20CSharp%20Coding%20Standard.zip

  14. Anonymous says:

    FYI, there’s a new Version 1.81 dated January 22. As the version number indicates, it’s a small change from 1.8.

    It’s available at http://idesign.net/idesign/download/IDesign%20CSharp%20Coding%20Standard.zip

  15. Anonymous says:

    This is another stupid one without a reason. The limit on a function size is recommended only for the readability since we are in 21st century with bigger better monitors the 25 lines or for that matter 50 lines does not make any sense at all.

    But it is recommended to keep the function size to be "one screenful" whatever it might be in your case. So that the guy who is trying to understand does not have to go up and down and forget everything in the middle.

  16. Anonymous says:

    how to make connection code in c#

  17. Anonymous says:

    Helpful For MBA Fans.

  18. Anonymous says:

    Ping Back来自:blog.csdn.net

  19. Anonymous says:

    Jeg har efterhånden arbejdet på en del projekter med en del mennesker.En ting de alle har

  20. Anonymous says:

    C#编码规范 为了以后软件更加容易维护,还是有必要建立一套编码规范。



  21. Anonymous says:

    C#编码规范 为了以后软件更加容易维护,还是有必要建立一套编码规范。



  22. Anonymous says:

    Seems obvious when you state it out loud, however it is quite amazing how many companies seem to miss

  23. Anonymous says:

    According to the C# coding style guidelines available from IDesign.Net (