Hacker News Reader

Comment by comex | Hacker News Reader

Somehow over the years learning C on my own, perhaps because it seemed more consistent to me, I got used to writing

    if(foo) {

omitting the space after control statements' names, which is almost never done - except in very early C code. (It's not just this: V7 Unix often omits the space as well.). I should probably settle on a less idiosyncratic personal style, but I can't help but take a little heart from seeing "my" style in such a famous codebase. :)

View on HN

It was also defined in the Plan 9 code style: http://plan9.bell-labs.com/magic/man2html/6/style

"no white space after the keywords if, for, while, etc."

    if(foo)

I avoid doing this because it looks like a function call.

In an appropriately powerful language, it could be a function call.

after

  #define if(X) LET(_it,X) if (_it)

it would be a macro call

I'm fairly certain that shadowing a keyword with a macro is forbidden by the standard (or invokes UB?) but this will still work for most compilers, provided LET is defined reasonably. Hm, something like

     #define LET(name, X) \
       for (int let_once_=1, name=(X); \
            let_once_; \
            let_once_=0)

may be reasonable, though tokenpasting in __LINE__ for good measure might be necessary for nesting.

Shadowing keywords is perfectly valid, although I believe you can't shadow keywords in standard headers so that compiler writers don't need to worry about it. It gives rise to some "useful" C/C++ features that should never be used, like if you want to access private members in foo.cpp, do

     #define private public 
     #include "foo.cpp"
     #undef private

I can imagine some insidious menace adding this to the top of a file:

    #define public protected

I once someone jokingly do (the second only always works in C, not C++)

    #define else
    #define struct union

Evil!

This is all very well if you have a friendly, high level scripting language like Ruby, but I'm definitely glad I don't have to write a C compiler where functions can take arbitrary blocks of code.

Apple took care of it for you:

http://en.wikipedia.org/wiki/Blocks_(C_language_extension)

> In an appropriately powerful language, it could be a function call.

> This is all very well if you have a friendly, high level scripting language like Ruby, but I'm definitely glad I don't have to write a C compiler where functions can take arbitrary blocks of code.

That's a surprisingly good setup because in Smalltalk(one of ruby's main ancestor languages)

if/else is a method which takes a block closure.

    a ifTrue: [ l log: 'a is true'] ifFalse: [ 'a is false']

while

in ruby if else is a syntatic construct

    if a
        l.log ('a is true')
    else
        l.log ('a is false')
    end

probably more for perceived clarity/comfortability then speeds sake.

Which is exactly why you don't do it in a language where it isn't.

Why should a developer have to have headspace for a special class of construct? And what difference does it make in practice whether it is a keyword or a function - why do you think it's so important that they are obviously different in the code - does their being part of a special category have any practical implications?

Never using a space before the paren is more consistent. I don't know why people put a space there...

I don't want my function calls to be consistent with control structures.

I don't recall ever mistaking function calls with control structures.

That's the way you do it in normal text.

Reply on news.ycombinator.com