Hacker News Reader

Comment by natesm | Hacker News Reader

This is obviously personal preference and opinion and all of that, but that's the whole point of discussion, so:

    if (something) {
    	something();
    } else {
    	something_else();
    }

vs.

    if (something)
    {
    	something();
    }
    else
    {
    	something_else();
    }

To me, the first one is chaotic. It's not so bad like that, but throw in a loop (as well as the external function declaration) and it's a complete mess.

The second one is orderly. Block separation is very clear, and each brace is matched by an equal.

IMO, if you need to worry about how many lines of code fit on your screen, it's probably time to refactor (or upgrade from a netbook).

I might be crazy though, because I write

    int* foo

instead of

    int *foo

And no one does that. Pointers are a type!

View on HN

You might have a point, but your arguments are inconsistent with each other; You say

> IMO, if you need to worry about how many lines of code fit on your screen, it's probably time to refactor (or upgrade from a netbook).

But also:

> Block separation is very clear, and each brace is matched by an equal.

Block separation is equally clear in the first example (same column means same block), and if your IDE can't show you matches if you're lost, it's time to upgrade from ed or edlin.

Also,

> I might be crazy though, because I write "int* foo" instead of "int \foo" [edit: \ should be asterisk. can't make it show one, though]

You are indeed crazy, or at least misguided and confusing. because

    int* a, b;

implies a and b or both of type "int* ", but actually, a is of type "int* " and b is of type "int". The second form is visually consistent, because:

    int *a, b;

Says "*a" is of type "int", and also "b" is of type "int".

I feel perhaps you are missing my point -- you are talking about block separation and vertical space, I am talking about grouping of logical units.

I agree with your points for functions, (most)loops, switches, and so in, but for if/else try/catch/finally do/while an other multiblock statements, I think it helps to have some convention to group them, other than indent level. The blocks depend on each other, not just are in proximity.

I would never do:

  for (a;b();a++) {
     stuff();
  } if (test) {
     ...
  }

because the if and the for are not parts of the same logical chunk. Nor would I do:

  ...
  } else {
    catchall();
  } if (new_test()) {
  ...

Again because a new if is new logical chunk.

Basically, it isn't about block delineation or about vertical space, its about grouping logical units that have multiple blocks at the same nesting level.

I use a newline and (sometimes) comments for that, so for example two unrelated if statements will have a blank line and some sort of comment between them.

I think it would be really interesting to see how people's code style preferences translated to how they design things (or prefer designs). I like minimalism and lots of whitespace in designs, and it definitely translates to how I best read code.

I follow Python's example for this.

    if (...) {
      ...
    } else if (...) {
      ...
    }

corresponds to

    if ... :
      ...
    else if ... :
      ...

not

    if ... :
      ...
    
    else if ... :
      ...

But then you write

  int* foo, bar;

and the troubles begin...

Ah, that's exactly the thing I try to avoid. Presumably you're going to use those variables, right? So, unless there's truly an issue (conditional assignment that is too complex for a ternary) why not declare them at the point of use? C99 lets us do that, there's no reason to keep the C89 habits.

Meaning:

   int* foo = whatever;
   // do some stuff with foo, now we need bar
   int* bar = whatever;

Outside of a for loop, I would never do two assignments on the same line, so it isn't an issue.

If it really has to be done like that, I just suck it up in that case. C has its warts.

But it still looks cleaner to put your variables first and your code after. It's like in a play, you mention which characters are going to be in the scene before you get to the dialogue.

Yes, this has bitten me recently and it's almost enough to make me type it the other way. Almost...

Conversely, I find the first example far easier to read. The second one is, to me, too "broken up" which completely interrupts the flow. To each their own. :)

I always write "int* foo", so you're not alone. I also prefer

    {
    else
    }

too.

subjective. control flow complexity is equivalent. stop talking about it.

Heaven forfend people discuss different ways to view a problem.

Yes, but on a page discussing a font ?

I completely get the reason why code blocks were first introduced in these comments, but think the "int" versus "int " discussion is offtopic.

Reply on news.ycombinator.com