Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Another example of programming style

Another example of programming style

  • Comments 16

Brad Abrams over on the CLR team just published an article containing the CLR team's internal coding conventions.  It makes an interesting counterpoint to my "what is programming style" series from back in November.

I can't say I agree with everything they're doing (as I mentioned, personally I find it extremely useful to be able to visually discriminate between local variables, member variables and parameters, and their style doesn't allow for that) but it's a good example of a coding style document.

 

  • I don't understand how to reconcile the following two statements:

    1. Braces should never be considered optional. Even for single statement blocks, you should always use braces. This increases code readability and maintainability.

    2. It is suggested that all control structures (if, while, for, etc.) use braces, but it is not required.

  • But not a perfect example. The advice on braces is inconsistent from one section to the next, and some of the examples given violate it.
  • I didn't say it was perfect, I thought it was interesting :)
  • I also like the "m_" prefix for members. It looks like their solution is to never have an implicit this, so instead of "m_id = 42;" they write "this->id = 42;". I'm not sure I've seen this guideline suggested before, but it definitely disambiguates.
  • I'm still waiting for a response on my question about how to solve the colossal blunder called "Control.Dispose(bool disposing)" and how this grievous gaffe ever got into the BCL in the first place?
  • The "use this. instead of m_" guideline is silly. All that does is replace a two-character prefix with a five-character prefix.
    But "this." isn't Hungarian and HUNGARIAN IS EVIL so I guess that makes it justified. ;)
  • How amazing it is!

    Except I use TAB instead of 4 SPACES for indent, that's exactly the style I used all the time. :)
  • It is notable that this isn't the CLR team's coding convention as a whole. In fact while we're moving in the direction of a universal coding standard, so far each of the sub-teams of the CLR have more or less had free rein to oll their own. Brad's post is generally most applicable to the BCL (Base Class Library, which is written in C#). I know that the BST (debugger, EH, GC, threading, etc...) team makes a point that braces are not optionional even for single line control flow statements, and those of us working on 64-bit tend to follow those rules. Generally however, the first rule is *consistency*, if you're working in a file that already has a well defined style go with it.
  • "as I mentioned, personally I find it extremely useful to be able to visually discriminate between local variables, member variables and parameters, and their style doesn't allow for that"

    Funny you mention it, that was exactly my first thought when I read Brad's article too... Coming from a Delphi background, I prefix all my nonstatic fields with a capital F and all static ('global') fields with a G. So I know that anything not starting with a capital is local...
  • I spent eight years working on a large project (C/C++ with 1.4 million lines of code, some dating back 15 years) with few style guidelines and almost virtual disrespect for the guidelines that were there.

    As far at the purely cosmetic stuff (spacing, braces, naming, comment style), it was surprisingly a non-issue. In fact, after a while working on the project, you could usually figure out who wrote what sections by the style and sometimes even the age of the code as people's personal styles evolved over time. I wouldn't recommend a mishmash of personal styles, but having one wasn't as bad as I would have expected.

    As for more substantial guidelines, like declaring the proper types for your variables rather than casting later, those could have saved a lot of grief and pain had they been obeyed. But once again, it was usually easy to guess the author from the types of screwiness.

    Trying to get anything more than a very small team to stick with a style is like herding cats, especially if there is any growth or turnover. Programmers have big egos. Their way is right (mine is anyway). I'd love to see a consistent style, but it's nearly an impossible goal.

    Rather than waste energy on style police, crank up your compiler warning level to the max and block check-ins that aren't 100% warning- and #pragma-free. More bang for buck that way.
  • Adrian,
    That process (seeing who wrote old code) is what I call Software Archaeology, and it can be quite unpleasant.

    That's actually why I wrote up the whole "coding with style" series.
  • Adrian makes the same point as Sutter & Alexandrescu in C++ Coding Standards" (http://www.gotw.ca/publications/c++cs.htm): 0. Don’t sweat the small stuff. (Or: Know what not to standardize.)
  • Brad Abrams over on the CLR team just published an article containing the CLR team's internal coding conventions . It makes an interesting counterpoint to my " what is programming style " series from back in November. I can't say I agree with

  • PingBack from http://workfromhomecareer.info/story.php?id=27317

Page 1 of 2 (16 items) 12