Is there a way to measure programming style?

This is a discussion on Is there a way to measure programming style? within the C Programming forums, part of the General Programming Boards category; If you were asked to measure different programming styles what would you measure?...

  1. #1
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794

    Is there a way to measure programming style?

    If you were asked to measure different programming styles what would you measure?

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    By "programming style", do you mean "code style", as in "how much you indent each line, where you place braces, and if you put spaces after parenthesis or not", or "the overall approach to the design and implementation of a software project", or perhaps something else?

    The first one is pretty meaningless to measure.

    The second is pretty hard to measure - one metric would be "how many defects per man-month", perhaps with additional difference in weight for different types of defects [for example customer found, found in internal testing, system crash, application crash, cosmetic].

    If you are asking for something else, then please be more precise in what you ask about.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    Quote Originally Posted by esbo View Post
    If you were asked to measure different programming styles what would you measure?
    1) The ability of other programmers, regardless of their experience, to quickly and more correctly, understand the code involved, when compared to other programming styles.

    2) Being able to see a larger number of rows of code, on a page, as well as longer lines of code,
    All this in a font size that is easily readable, not insanely small.

    3) Space saving:
    That's why I dislike the "let's indent each level of code by 10 spaces!" style - wastes horizontal space, and the "student style", where every opening brace has to be on it's own line - that strikes me as both condescending "look, I'm dumb as a brick and can't be trusted to type an opening brace", as well as wasting vertical space on the monitor.

    I like a space before any operator, and after it as well. Just offsets and highlights it, nicely.
    I don't believe a parenthesis needs a space before or after it, unless it is code requiring multiple and complex parenthesis sets, in the same line of code. Then it's helpful.

    4) A certain straight forward elegance. Student style doesn't have it. I like K&R's style, liked it from the first time I saw it, and I like it still all these years later.

  4. #4
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Adak View Post
    That's why I dislike the "let's indent each level of code by 10 spaces!" style - wastes horizontal space, and the "student style", where every opening brace has to be on it's own line - that strikes me as both condescending "look, I'm dumb as a brick and can't be trusted to type an opening brace", as well as wasting vertical space on the monitor.
    I've never seen anyone that indents 10 spaces? I use a tab and set my IDE to make tabs 4 spaces wide (the default on mode IDE's I've seen).
    I absolutely despise code that uses those old 70's style braces that don't line up! It makes it a hell of a lot harder to read. With monitor and font sizes these days, there's no way you can use the excuse of not being able to see enough code on the screen at one time.

    Quote Originally Posted by Adak View Post
    I like a space before any operator, and after it as well. Just offsets and highlights it, nicely.
    Exactly.

    Quote Originally Posted by Adak View Post
    I don't believe a parenthesis needs a space before or after it, unless it is code requiring multiple and complex parenthesis sets, in the same line of code. Then it's helpful.
    I prefer spaces between parenthesis like printf( "Hello world" ); but not having spaces doesn't bug me nearly as much as not lining up braces.

    Quote Originally Posted by Adak View Post
    I like K&R's style, liked it from the first time I saw it, and I like it still all these years later.
    Yuk.

  5. #5
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >I absolutely despise code that uses those old 70's style braces
    >that don't line up! It makes it a hell of a lot harder to read.
    A good programmer should be able to read any style as long as it's consistent. Rather than complain about a style, why not use it for a month or so to get used to it? Then you won't have as much of a problem with readability.

    >1) The ability of other programmers, regardless of their experience, to quickly and more
    >correctly, understand the code involved, when compared to other programming styles.
    That's probably the best measure of style, but it's also the hardest one. You have to get a group of programmers to review the code.

    >2) Being able to see a larger number of rows of code, on a page, as well as longer lines of code
    I disgree. Compact code doesn't equate to good code.

    >3) Space saving:
    There's no point saving space if you don't need to. Likewise there's no point wasting space if you don't need to. You need to back this one up with a good reason.

    >4) A certain straight forward elegance.
    How would you measure elegance?
    My best code is written with the delete key.

  6. #6
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    Quote Originally Posted by Adak View Post
    That's why I dislike the "let's indent each level of code by 10 spaces!" style - wastes horizontal space, and the "student style", where every opening brace has to be on it's own line - that strikes me as both condescending "look, I'm dumb as a brick and can't be trusted to type an opening brace", as well as wasting vertical space on the monitor.
    I disagree with that one.
    There are two coding styles I don't like:
    One is:
    Code:
    void foo() {
    }
    And one is:
    Code:
    void foo()
    { // something;
    // something
    }
    It should be:
    Code:
    void foo()
    {
    	// something
    }
    Readable code gives priority before shorter and more compact code!
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    Quote Originally Posted by Elysia View Post
    There are two coding styles I don't like:
    One is:
    Code:
    void foo() {
    }
    Why don't you like it? Are you just talking about functions or any compound statement?
    Quote Originally Posted by Elysia View Post
    And one is:
    Code:
    void foo()
    { // something;
    // something
    }
    I agree with this one, but not because of readability. Pretty printers and formatters tend to choke on this style and fail to produce the requested format.

    >Readable code gives priority before shorter and more compact code!
    Consider the advice I gave to cpjust. Neither of the styles you gave as bad examples lack readability. The problem is on your end, not being familiar enough with them to brainparse the code just as easily as you do your own style. What do you think of this one?
    Code:
    void foo()
        {
        // code
        }
    My best code is written with the delete key.

  8. #8
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Prelude View Post
    What do you think of this one?
    Code:
    void foo()
        {
        // code
        }
    That one is a little better, but it's still bad.

    The reason I think this one lacks readability:
    Code:
    void func() {
    }
    is because when people write their function braces like that, they also write their if, for, while and all other braces like that and it clutters up the screen too much. If you have other stuff on the same line as a brace and you're scanning through the code quickly to find a specific piece of code or just trying to get a quick summary of the logic, it's easier to miss the brace than if it was on a line by itself. Basically it helps space out the code a bit more so it isn't one solid block of text on your screen.

  9. #9
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >That one is a little better, but it's still bad.
    Why? It has consistent indentation, the blocks are well defined, and the braces are on a line by themselves.

    >it's easier to miss the brace than if it was on a line by itself
    That would be a reasonable argument if the code had no indentation.

    >Basically it helps space out the code a bit more so
    >it isn't one solid block of text on your screen.
    One solid block of text? Are you sure you're not exaggerating just a little bit? If it's really as bad as you suggest, moving the opening braces to a line on their own clearly won't fix the problem.
    My best code is written with the delete key.

  10. #10
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,499
    Code:
    if ( something ) {
        doAbit();
        ofThis();
    } else {
        doSomeMore();
        ofThat();
    }
    I don't pay any attention to the braces when I'm reading the code, it's all about following the indentation. I certainly don't have any kind of mental "count" of the current nesting depth of the code based on the brace count.
    I generally assume that if the programmer cared enough to make the indentation correct, then the braces are going to be in the right place as well (and therefore of little concern).

    For the most part, braces are just syntactic crumbs for the compiler to chew on to make it easier to parse the code. We humans are perfectly able to figure out the flow without braces at all, eg.
    Code:
    if ( something )
        doAbit();
        ofThis();
    else
        doSomeMore();
        ofThat();
    From a human perspective, there's been no loss of information. All the detail needed to still work out what's going on is still there.

    Or put another way, if you can't do this to your code, and have it still make sense to your readers, then it's poorly formatted code IMO. Code which forces me to mentally track the braces is just too much hard work.

    Because braces add little to my understanding of the code, I like to tuck them away so they provide minimal visual intrusion on the actual code which contains what's really going on.



    With a smaller font, I can also use this style
    Code:
    if ( something )
    {
        doAbit();
        ofThis();
    }
    else
    {
        doSomeMore();
        ofThat();
    }
    Even though the braces have undeserved prominence all of a sudden, the extra vertical white-space on a smaller text size can certainly help with program clarity.

    But as ever, it's the indentation which tells me what's going on, not brace counting.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  11. #11
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    I prefer symmetrical braces to K&R because I guess it's easy to let yourself naturally spot the symmetricality in the text, and deduce what is actually relevant.

    But it's not like I'd be upset if I had to work on K&R code.

    Indenting braces with the code, however, makes my brainparser choke.
    Last edited by robwhit; 01-09-2008 at 02:26 PM. Reason: sp

  12. #12
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    Quote Originally Posted by Prelude View Post
    Why don't you like it? Are you just talking about functions or any compound statement?
    It's just my individual opinion and coding style.
    Still, usually when people write with
    Code:
    void foo() {
    }
    Typically the code is messy. Still readable, but messy.
    When people do
    Code:
    void foo()
    {
    }
    It's usually clean. I prefer clean style over everything else, because it makes the code extra readable.

    >Readable code gives priority before shorter and more compact code!
    Consider the advice I gave to cpjust. Neither of the styles you gave as bad examples lack readability. The problem is on your end, not being familiar enough with them to brainparse the code just as easily as you do your own style.
    I know. Maybe it doesn't apply to the above example as much, but it could apply to:
    Code:
    void foo() { something; something; something; something; }
    In which case it's better to write:
    Code:
    void foo()
    {
    	something;
    	something;
    	something;
    	something;
    }
    Yes, it takes more lines, but it's more readable.

    What do you think of this one?
    Code:
    void foo()
        {
        // code
        }
    It's even scarier than
    Code:
    void foo() {
    }
    Because the blocks should be put on the same level as the so called block element.
    As you can see, it really defeats the purpose of the indentation because the code is on the same level as the { and }.
    To me, that's just ugly and messy and less readable.

    It's all about the indentation, though--it's what makes code readable. But the style of where putting the braces can help make the code even more readable, but it's coding style and we are free to choose whichever ones we want.

    And btw, braces can be important to know what code the block belongs to, not just the indentation. In big loops, I find it easier to just search for the { and } to see where it begins and ends. That's also, I'm guessing, why I like the { on a separate line.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    If the only thing that matters is the indentation, then why not save even more space and do this:
    Code:
    int func() {
        if ( something ) {
            call_func(); }
        else {
            call_func2(); }
        return 0; }

  14. #14
    The larch
    Join Date
    May 2006
    Posts
    3,573
    To satisfy everybody, the board software might have code reformaters where you can define your own styles.

    What if I like completely random spacing because that would keep me alert and awake?
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  15. #15
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >then why not save even more space and do this:
    As long as you're consistent, no problem. Though you would be actively pursuing unreadable code by choosing a style that isn't in common use. For C it seems like the majority of programmers have settled on either a K&R variant or Allman.
    My best code is written with the delete key.

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. WM_CAPTION causing CreateWindowEx() to fail.
    By Necrofear in forum Windows Programming
    Replies: 8
    Last Post: 04-06-2007, 08:23 AM
  2. Button handler
    By Nephiroth in forum Windows Programming
    Replies: 8
    Last Post: 03-12-2006, 05:23 AM
  3. Which style of if loops is most common?
    By dwks in forum A Brief History of Cprogramming.com
    Replies: 38
    Last Post: 08-25-2005, 03:18 PM
  4. WS_EX_COMPOSITED style (double buffering) problems
    By JasonD in forum Windows Programming
    Replies: 2
    Last Post: 10-12-2004, 11:21 AM
  5. Tab Controls - API
    By -KEN- in forum Windows Programming
    Replies: 7
    Last Post: 06-02-2002, 09:44 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21