Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

What does style look like, part 2

What does style look like, part 2

  • Comments 13

In my previous style post, I took a piece of code from  Robert Sedgewicks algorithms book, and "Hungarian-ized" it.  The routine currently looks like:

#include "list.h"
main(C cArg, SZ rgszArg[])
  {
    I iNode, cNodes = atoi(rgszArg[1]), cNodesToSkip = atoi(rgszArg[2]);
    PNODE pnodeT, pnodeCur; InitNodes(cNodes);
    for (iNode = 2, pnodeCur = PnodeNew(1); iNode <= cNodes ; iNode++)
      { pnodeT = PnodeNew(i); InsertNext(pnodeCur, pnodeT); pnodeCur = pnodeT; }
    while (pnodeCur != PnodeNext(x))
      {
        for (iNode = 1; iNode < cNodesToSkip ; iNode++) pnodeCur = PnodeNext(pnodeCur);
        FreeNode(PnodeDeleteNext(pnodeCur));
      }
    printf("%d\n", Item(nodeCur));
  }

Btw, I'll show what this code looks like without hungarian during this series, don't worry :).

Now that it's hungarianized, lets look at the structure.  The first thing that stands out is that it's not completely consistent.  Every indentation is 2 spaces, but sometimes lines are compressed, sometimes not.  This is undoubtedly a concession to the space requirements in the book, it's not likely something you'll find in production code.

Lets re-format the code and see what happens.  First, I'll use the "braces appear on the same line as the conditional, indented 4 characters (K&R)" style:

#include "list.h"
main(C cArg, SZ rgszArg[]) {
    I iNode, cNodes = atoi(rgszArg[1]), cNodesToSkip = atoi(rgszArg[2]);
    PNODE pnodeT, pnodeCur; InitNodes(cNodes);
    for (iNode = 2, pnodeCur = PnodeNew(1); iNode <= cNodes ; iNode++) {
        pnodeT = PnodeNew(i); InsertNext(pnodeCur, pnodeT); pnodeCur = pnodeT;
    }
    while (pnodeCur != PnodeNext(x)) {
        for (iNode = 1; iNode < cNodesToSkip ; iNode++) pnodeCur = PnodeNext(pnodeCur);
        FreeNode(PnodeDeleteNext(pnodeCur));
    }
    printf("%d\n", Item(nodeCur));
}

To me, the code hasn't changed that much.  Lets make another change: Moving each statement to its own line:

#include "list.h"
main(C cArg, SZ rgszArg[]) {
    I iNode, cNodes = atoi(rgszArg[1]), cNodesToSkip = atoi(rgszArg[2]);
    PNODE pnodeT, pnodeCur;
    InitNodes(cNodes);
    for (iNode = 2, pnodeCur = PnodeNew(1); iNode <= cNodes ; iNode++) {
        pnodeT = PnodeNew(i);
        InsertNext(pnodeCur, pnodeT);
        pnodeCur = pnodeT;
    }
    while (pnodeCur != PnodeNext(x)) {
        for (iNode = 1; iNode < cNodesToSkip ; iNode++)
            pnodeCur = PnodeNext(pnodeCur);
        FreeNode(PnodeDeleteNext(pnodeCur));
    }
    printf("%d\n", Item(nodeCur));
}

That's somewhat better, the routine takes some more vertical space, but it's a bit clearer what's going on.

Tomorrow, BSD style, and a bunch of other indentation varients.

 

  • Why does everybody like to put the block opening brace on the same line as the parent statement?
  • Because K&R did it that way.

    Personally I don't prefer that style, but it IS a valid coding style.

    And this series isn't about what's good or bad (or at least I'm trying not to let my personal feelings leak into the debate).
  • Whoops! That's a really good point James.

    K&R is "The C Programming Language" by Kernighan and Ritchie (thus K&R). This is the original reference manual for C programming, many (most?) of the first several generations of programmers learned C from that book.
  • At the risk of exposing my total and utter newbness to coding, who/what is K&R?
  • Another thing to throw into the mix - add braces to all single line blocks which are not already braced (such as the for loop inside the while loop).

    Okay, maybe that's just me. :P
  • Steven, that variant comes in tomorrow :)
  • Another thing to throw into the mix: along with putting each executable statement on its own line, also put each declarator into its own declaration (thereby resembling a statement) and put it on its own line.

    If K&R indented 4 columns at a time, was that just because of book typography or did they do it in their real code? I'd have thought they were using DEC terminals[*] along with their DEC CPUs even though they didn't like DEC's operating systems, and I'm pretty sure those terminals already had built-in tabbing to multiples of 8 columns.

    [* at least when they weren't using ASR/33 Teletypes]
  • I don't know why K&R used their style, it's an interesting question.
  • Usual answer is that the OTBS (One True Brace Style a/k/a K&R) is to preserve vertical whitespace. This matters when you're on a 24x80 video terminal, and in email for that matter.

    I'm an aligned bracer myself. Against my better judgement, people have convinced me that the braces should not be indented, but code snippets in manuals or email are longer when you use this format (indented or not).
  • Larry, where did you get your K&R style from? I'm looking at my copy of K&R (1978 edition) and they used a 5 character indent and put the braces for function definitions on a line by themselves. The example for file copying on page 14 looks like

    main()
    {
    .....int c;

    .....c = getchar();
    .....while (c != EOF) {
    ..........putchar(c);
    ..........c = getchar();
    .....}
    }
  • Nicholas, my bad - I miscounted (I'm so used to 4 space tabs).

    And you're right about the function brace, my bad too.
  • I actually worked around "K&R" for a while. Everyone around there put their braces on the same line...
Page 1 of 1 (13 items)