Live data from Hacker News

Humans should think of sizeof() as a function, says Linus Torvalds

lkml.org

71–80 of 140 posts

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#71
post #44
post #31

Earlier quoted context omitted.

Another oddity of C that amuses me is the do/while loop without braces: int i = 4; do printf("hey\n"); while (--i > 0); Even though do/while is a keyword bracketing pair in C, it still only lets you use a single statement (because nested whiles). So everybody uses braces, and thus it looks quite disturbing without them.

it looks quite disturbing without them Remove the newline and it looks ok to me: int i = 42; do printf("hey\n"); while (--i > 0); Another possibility would be: int i = 42; do printf("hey\n"); while (--i > 0);

Just looking ok is not the point. I would prefer a match between how it looks and what it does...

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#72
post #31
post #6

IIRC, if the argument to sizeof is a type, the parentheses are mandatory, anyway, so using it like it was a function is more consistent. I think the reason it is not a function from the standard's point of view is that C does not have any builtin functions (unless my memory totally fails me in this case), all functions have to be either defined locally or #included.

Another oddity of C that amuses me is the do/while loop without braces: int i = 4; do printf("hey\n"); while (--i > 0); Even though do/while is a keyword bracketing pair in C, it still only lets you use a single statement (because nested whiles). So everybody uses braces, and thus it looks quite disturbing without them.

Its not so disturbing when you consider that braces aren't special cased in the C grammar. They group statements so they can be used together where a statement is needed. From the grammar's perspective the "normal" way is without braces. It's just that all the C-alikes have gone a different direction with the way braces are parsed leading everyone to regard the original behavior in C as ugly warts.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#73
I used to write

    return (0);
I.e., with a space. I'm not sure if someone ever told or recommended me to do this, but the reason I did this was consistency with other C statements, because all C statements that take some kind of expression as a parameter (if, for, while) require it to be surrounded by parentheses. So it seemed logical to me to do the same with return. I've stopped doing it now, although some of the old code still lives.

I've seen code by others where there was always a space between the function name and its arguments. That was ugly, and really confused a function call with a statement.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#74
post #69

Earlier quoted context omitted.

Ah, to join the bikeshedding: { on newlines make imho more sense, the block of code is visually balanced that way. We have high-res screens now, no reason to pretend we're still on 80 char terminals. But work long enough in either one of those styles, and the other one will start to look strange.

What advantage does 'visually balanced' give? That's like saying the letter A is better than B because it's 'stands up better.' Indentation is how you should identify blocks.

Indentation to identify blocks can break down in things like switch statements:

switch( c ) {

   case 'A':
     simple_stuff();
     break;

   case 'B': {
     int temporary_variable = 0;
     complex_stuff( temporary_variable );
 }
To me, the advantage of braces on newlines is it makes it extremely easy to tell where blocks start and end---whether you're using your favorite IDE, or reading the code on a blog, or reading the code with "cat". I actually think it's a case where Python has the design advantage on C (since if you do braces-on-newline consistently enough, you end up duplicating python but with superfluous braces added in).

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#75

I respect Linus greatly but the way he to talks to his fellow 'humans' is insanely confrontational, rude and disrespectful. It overshadows his arguments (which are usually very good) and throws people on the defensive. I'm grateful for all he has accomplished and shared with us but I imagine working with him is 'hell'.

I would imagine once you get used to him and thicken your skin up a bit, it's no big deal.

Hell, a little salty language and telling people they're being idiots when they are being idiots is not a bad thing. The best machinists and millwrights I've worked with were like that, and it was a good thing - you don't have time to ask politely when there are steal beams or a two-ton electric motor swinging towards you.

C can be almost as dangerous :-)

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#76

Earlier quoted context omitted.

Exactly. I heard people arguing on the Internet that you should not add parentheses when sizeof is applied to an expression, only a type. I just cannot understand why they bother. Just add a parenthesis and it is always right. Much less cognitive burden.

This is the same people that find it "better" to write JS without the semicolons.

The problem is that without a linter there's no punishment for missing semicolons.

So really the argument should be that everyone should use a linter.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#78
post #74
post #69

Earlier quoted context omitted.

What advantage does 'visually balanced' give? That's like saying the letter A is better than B because it's 'stands up better.' Indentation is how you should identify blocks.

Indentation to identify blocks can break down in things like switch statements: switch( c ) { case 'A': simple_stuff(); break; case 'B': { int temporary_variable = 0; complex_stuff( temporary_variable ); } To me, the advantage of braces on newlines is it makes it extremely easy to tell where blocks start and end---whether you're using your favorite IDE, or reading the code on a blog, or reading the code with "cat". I…

Fundamentally, the problem is that braces are needed at all. Humans are bad at matching them up, so they don't match the humans' intention when indenting. Confusion.

It's all backward. The IDE should SHOW you the blocks somehow (background tone changes etc), and let you edit the blocking explicitely. If they look wrong, you select and hit a key. Now you're in agreement with the compiler.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#79
post #74
post #69

Earlier quoted context omitted.

What advantage does 'visually balanced' give? That's like saying the letter A is better than B because it's 'stands up better.' Indentation is how you should identify blocks.

Indentation to identify blocks can break down in things like switch statements: switch( c ) { case 'A': simple_stuff(); break; case 'B': { int temporary_variable = 0; complex_stuff( temporary_variable ); } To me, the advantage of braces on newlines is it makes it extremely easy to tell where blocks start and end---whether you're using your favorite IDE, or reading the code on a blog, or reading the code with "cat". I…

I'm not seeing what the issue here is, besides that this won't compile because of mismatched braces. There is no need to put braces around the contents of a case block. Unless I'm switching on an enum, I rarely find a compelling reason to use switch/case, and there's usually a cleaner way to do it.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#80
post #73

I used to write return (0); I.e., with a space. I'm not sure if someone ever told or recommended me to do this, but the reason I did this was consistency with other C statements, because all C statements that take some kind of expression as a parameter (if, for, while) require it to be surrounded by parentheses. So it seemed logical to me to do the same with return. I've stopped doing it now, although some of the old…

I find parens around a return value/expression slightly annoying, but not annoying enough to have a debate over it. It doesn't make the code harder to read, IMHO.

Whitespace between a function name and the arguments is significant, however, because with a function-like macro, there must be no whitespace between the name and the opening parenthesis. I've seen the following code in production code, for example:

  #include 
  #define free(x) free(x), x = NULL

  free(ptr1); // Macro
  free (ptr2); // Call free(3) directly
(Whether or not such a macro is good idea is a different question entirely, the point is that you can prevent such macro-expansion by using whitespace. Aesthetically, I find it very disturbing, though.)
Post reply on HN