Coding conventions


<rant>

Most of the coding convention I’ve seen being used by SW houses seems to promote wastage of lines. I suspect that since in many cases code size is measured in LOC it actually helps quoting a larger number. E.g. I start getting a tad irritated when I have to write code as follows

// Why do I have to put in the enclosing curly braces :(
if(flag)
{
   Func();
}
// Can't I just use get { return foo; } and set {foo = value; }
public CFoo Foo { get { return foo; } set { foo = value; } }

</rant>


Comments (13)

  1. Kevin Daly says:

    While I wouldn’t require it as a convention (and I am responsible for that where I work) I often tend to use braces for conditions where there is only one statement, simply because of the likelihood that there will be *more* than one statement in the not too distant future.

    If I’m honest it’s also because my experiences with other languages made me twitchy about conditions without explicit scope delimiters.

  2. Kam says:

    Hi, I would like to know why this is such an issue.  I actually prefer the "more lines" for readability and standards.  Am I missing something here?  Are the extra lines or curly braces detrimental in any way?

    The curly braces to me denote a "sphere of influence".  Even if it is only one line now, it may become more in the future.  And it standardises things.  An "if" clause will contain the processing logic for a true within curly braces ALWAYS.  See?  One less thing to remember.

    I’m not ranting.  Just not understanding why this is a problem.  I understand this is your blog – therefore your rants.  And this may just be an "Adrian Mole" type entry.

    Discuss 😉

  3. Marc says:

    I prefer the style you refer to as a waste of lines. And I am not measured by LOC. What I don’t like is your CFoo (waste of letters?).

  4. It’s all about what works for you, but to me the MOST important thing when writing code is to adopt a coding standard that promotes easy reading.

    if (1==)

    {

      some condition;

    }

    if (2==2)

    {

      some other condition;

    }

    is easier to read (for me) than

    if (1==1)

     some condition;

    if (2==2)

     some other condition;

    The number of lines doesn’t matter to the compiler…

  5. This drives me nuts the carriage return costs nothing but adds so much to read ability.

    if(some condition){

    some action

    }

    The is always better for me. Its offers a separation of ideas.  One line for the condition the next the reaction to said condition being true.

    if( some condition )

    {

    action

    }

  6. This should really be a matter for the display from an IDE.  It’s more personal taste and preference then "Coding Standard"  If the IDE just displayed code blocks in a user defined manner, almost every one would be happy.

  7. Peter Ritchie says:

    I agree with the other commenters.  "Waste of lines", when I bought my computer I opted for the unlimited # of lines…

  8. SirMike says:

    For me it’s not "waste of lines", it’s readability.

    But in contrast, what do you think about writing space after "if", "for" statements. What about casting? To space or not to space? 🙂

  9. Vyacheslav Lanovets says:

    Try to compile and debug in VS2005 this native C++ program:

    #include <string>

    struct TData

    {

    std::string data_;

    void set_data(){ data_ = "1"; } // try to break here and add watch for *this

    };

    struct TDataO1

    {

    TData x_;

    void set_data(){ x_.set_data(); } // try to break here and add watch for *this

    };

    struct TDataO2

    {

    TDataO1 x_;

    void set_data(){ x_.set_data(); } // try to break here and add watch for *this

    };

    int _tmain(int argc, _TCHAR* argv[])

    {

    TDataO2 y;

    y.set_data();

    return 0;

    }

    In typical software there are much more "levels of inidirections" and it’s annoying that watch in debugger does not work for one-line functions. Sometimes, you don’t have access to root object (it’s called y in the program above) from where you could watch all its members, because it was returned from some function and so you have to restart program, but if bug is not 100% reproducable, and the code is used from many places, you better rewrite this place placing { and } on separate lines. After that you wait 1 hour while it compiles and you can debug it.

    After we had replaced several hundreds of 1-line inline functions with normal 3 line bodies, we were able to debug much more efficiently.

    Also I do like braces on separate lines.

  10. Lucius says:

    Readability improves for me when more lines of code fit on my screen as I can see better the code flow. I use to make my function never longer than what fits on screen so I can see code flow better.  I usually do use curly brackets but also do

    public CFoo Foo

    {

       get { return foo; }

       set { foo = value; }

    }

    primarily for readability.

  11. Randolpho says:

    I doubt there will ever be consensus here. Opinions will always vary on the subject.

    My own I personal preference is what you call "wasted space". It’s not becuase I’m judged by LOC or anything like that, but because I believe the "wasted space" makes for a more readable and maintainable document.

  12. Just the other day I ranted about all the explicit get; set; implementation and I found this out today

  13. isagani says:

    For maintenance sake, make it easy on the poor guy who will need to read and update the code.  Can anyone imagine if the code follows no convention, looking like K & K, ATT C, C++, Java, C#, and others all in one?