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

Agreed. I spend most of my time writing non-semicolon languages like Ruby, Haskell, Scala, Elixir, Clojure, and Python. As a result, I never developed the semi-colon reflex that a lot of Algol-family language users built up. I constantly forget semi-colons even after all these years, and my own inability to remember annoys me.

I used to skip semicolons in JavaScript because I could never remember to include them. Using a linter with Emacs made it a non-issue; I get a warning in my editor immediately when I miss one.

PS: I'm really enjoying Rust, so maybe this will be the language that finally forces me to pick up the semi-colon habit.

I thought about that regarding semicolons, optional braces, newline placement, consistent placing of whitespace in general; then I decided having the machine tell me where I need to do more work is all very well and good, but what I really want is a program that will do the work for me instead. So I wrote one: https://www.npmjs.com/package/jsclean

Oh, there's plenty of punishment. Avoiding the punishment in the difficult part. And you can do that the easy way or the hard way.

We would all be better off if semi colons had just been required in JavaScript. The problem is that semi colons are not actually optional in JavaScript. Instead JavaScript use ASI, automatic semi colon invasion, where the compiler attempts to determine where semi colons should go. Unfortunately the rules are complex, prone to certain errors, and I can't rely on everyone I ever work with understanding all of those rules. For all of these reasons if you are writing JavaScript you should just use semi colons.

Well, semicolons may be optional in Python but the official python style strongly recommends agains (needing to use them)

It's not about forgetting them once in a while, it's about playing a game of "needs a semicolon or doesn't" which increases the (already high) number of things the developer needs to worry about

In Python you usually don't add semi-colons, and it will bark when your intention is unclear.

In javascript you may omit semicolons, but the interpreter will guess your intention when it is ambiguous and it will probably guess it wrong.

AFAIK the only "benefit" to semicolons is that you can put multiple statements on the same line.

Dereferencing a null pointer is legal in C. It's the conversion of a null pointer from from an r-value to an l-value that's illegal, which does not happen in that snippet of code.

That's why it's perfectly legal in C to do this (&*foo), even if foo is a null pointer.

Why is that better than just getting `sizeof(* foo)`? Even with typedef, I can see this happening in the future:

    typedef int thing_t;
    ...
    thing_t *foo_internal;
    thing_wrapper_t *foo;
    // code
    foo = malloc(sizeof(thing_t));

    foo = malloc(sizeof(*foo));

That just makes it more verbose.

This, on the other hand, always allocates one object of foo's pointed-to-size, whatever its type:

    foo = malloc(sizeof(*foo));

As an aside, I think nearly any time you want a typedef, it's worth wrapping it in a struct.

    typedef struct { int value; } thing_t;

DRY is good, but making the structure of your code reflect the actual semantics you want is better. What you want is to allocate space for foo. So write that.

Well, in this (simple) case you can just do

    int *foo;
    foo = malloc(sizeof(*foo));

That's pretty severe. Written with spacing, its really pretty clear what is meant by

   if (condition)
      Foo(x)

An ideal IDE would make blocking visible (background tone change etc), and braces could be emitted automatically by the IDE without ever cluttering up the code shown to the programmer.

Sneaky. Most syntax highlighting would make it stick out like a sore thumb, but still, sneaky.

I agree, but I don't see that undermined here.

Does it generally do this in expressions, based on operator precedence, or is it limited to the outer parentheses on selected statements?

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.

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.

We don't use auto format for one because as far as I know it's not available for our languages (objective-c and swift)

I've never met an auto-formatter that I haven't hated the output of enough to not use it.

An interesting result of this (I suppose...) is that if a macro expands an argument twice, and one of those times is an operand for sizeof, you don't need to mention the double expansion in the documentation.

If you think everything called a "function", in every context, is the same thing, you are going to have a very bad day.

It's neither:

sizeof belongs in its own category of unary compile-time(-ish) operators, whose only other member is _Alignof.

If you're so inclined, you might add _Generic and _Pragma to that mix as well, but they aren't really a close fit.