Comment by dspillett | Hacker News Reader

Comment by dspillett | Hacker News Reader

Parent Full thread

A valuable life lesson though. I've followed coding standards that I don't entirely agree with¹²³, but breaking them would cause more discomfort for the larger project than the minor irritation keeping them would cause me. I'm sure the feeling is common in other career areas too, particularly professional writing.

---

[1] Not using extra space to line up similar parts of similar lines when grouped together, for instance, I find it makes things easier to read and alter afterwards

[2] Some codebases absolutely hate one-line if statements, it must be in a block even if only one statement is inside the conditional and the brackets must each be on their own line. I get that for more complex code it breaks things up visually in a way that is helpful, but stretching out 20..30 characters over four lines, artificially lengthening a function significantly if it happens multiple times…

[3] One FOSS project I once submitted a patch for insisted on absolutely no inline comments – all explanation had to be in the comment block at the head of the function declaration. It almost discouraged commenting, and I like to comment liberally.

Point 2 is also for security[1], especially in languages with non-hygienic[2] macro systems such as C. But as another commenter (yissp) already pointed out, even without macros it can quickly go bad. I once liked omitting blocks in if, while, for etc., but stopped doing it altogether and it now jumps out as a wart to me, too. It's just too risky for too little benefit.

What I disagree with sometimes is whether the block needs to start on a new line. For example I would like to do this:

    if (foo = bar) { blah(); }

But my former team was against it, and my current team uses a style enforcement tool (which I do agree with in principle), so I don't.

Point 1 is fine by me and the team: We embrace "tabs for indentation, spaces for alignment", so that fits into the philosophy.

Point 3, i.e. disallowing inline comments, seems ill-conceived and bad to me.

[1] Actually correctness, which often means security.

[2] Or rather a generalization of what "hygienic macro" means.

> if (foo = bar) { blah(); }

I'm happy with that. In fact I usually do that to avoid schoolboy errors when expanding to multiple statements later. It doesn't add much (a few characters, not three lines) and allows for lining up parts (ala my point 1) when there are a couple or more of lines doing very similar (but not so much so they can be usefully reduced to a function/macro).

Ah. Of course I managed to make a mistake in that minuscule amount of code, = should be == of course. At least a modern compiler would have warned without extra parenthesis.

[2] For me it has to do with scanning code. If if-statements are always in a block, then I can easily scan to or past it without having to stop and read what it actually says. But, if it is in a single line I have to stop and read it to understand that it is actually an if statement that was put onto a single line.

I've made the mistake of trying to add an extra statement to a one-line if and forgetting to add a block too many times. Although now GCC has -Wmisleading-indentation which should catch that.

Yes, exactly, it's just not worth the risk. It gets worse with preprocessor macro systems like C has, where something might look correct until you follow the macro definition.

Username checks out

Reply on news.ycombinator.com