Conditionals Assertion: Citation Needed about objective-c-style-guide HOT 11 CLOSED

It can also be a problem if you use multi-statement macros that are written poorly. For example:

#define foo(x, y) x; y

if (bar) foo(quux(), quux());

This is, of course, a better argument for writing multi-statement macros correctly:

#define foo(x, y) do { x; y; } while(0)

(Lots of folks don’t understand why they see do/while in macro expansions, or more recently, GNU C statement expressions or blocks. This is why.)

from objective-c-style-guide.

I would also suggest that it’s entirely possible that you’re savvier than the average bear, Josh. I can’t recall instances where I’ve witnessed this burn a novice, or in fact any instances where I’ve seen it burn someone without the macro thing above being involved, but I could see it occurring.

Personally, I feel like thoughtful style guides are most helpful to the least experienced, but that does not necessarily equate to them being unhelpful to the masters of the craft.

from objective-c-style-guide.

Great point, Rob. Regarding "most helpful to the least experienced" I'd argue "only if the style guide adequately explains why this is the better way." In its present state this assertion reads more like dogma. Particularly the "just too many ways" sentiment.

from objective-c-style-guide.

Yes, thorough justification for style choices (or at least explanation, for those choices which are just “we like looking at it better when it looks like this”) is an important tool to educate about the language. Not merely rote memorization of a pattern, cargo culting the way to prosperity as it were, but rather informing. One ought to respect one’s peers enough to explain one’s reasoning, after all.

from objective-c-style-guide.

I would argue that using conditionals without braces introduces risk when refactoring.

I also feel that it is always more clear to use braces than to not use braces. It's for the same reason that I favor using parentheses even when the order of operations would do the same thing anyway.

For example,

x = (7 * 7) - 4;

is functionally equivalent to

x = 7 * 7 - 4;

but a novice programmer, or even an experienced one, might have to think a moment before realizing the latter would produce 45, not 21. We make a hard and fast rule for braces for the simple reason that it leaves little doubt which code should be executed. In addition, it sidesteps issues with moving code around during refactoring.

from objective-c-style-guide.

@bcapps , look at us overlapping like that! Excellent addition.

from objective-c-style-guide.

@chrisladd 👍

from objective-c-style-guide.

All very reasonable explanations. However, is this a style guide or an Objective-C programming book? :-) What I mean is why pick on this and not nearly everything else you could do wrong due to a fundamental misunderstanding of your stated profession?

It's easy enough to comment your way out of logic anywhere and sure, use of a poorly-worded macro would confuse even the pros for at least a moment, but I'm under the opinion that a style guide is just a style guide and not a golden rulebook of language-specific right and wrong. Sure the two relate but any document that combines subjective opinion so closely to deterministic procedure is asking for criticism.

I'm enjoying the perspective, though - I honestly don't think of a style guide as being responsible for teaching a programmer flow control. :-)

from objective-c-style-guide.

The macro justification here is wrong. Multi-statement macros that are written like that are unequivocally incorrect, and can cause problems in other use-cases too. It is not an appropriate justification for requiring braces, it is merely a justification for requiring that macros be written correctly.

Requiring braces when a new line is involved is eminently reasonable, e.g.

if (foo)
    bar;

There are a number of possible justifications for requiring the braces. But they don't apply to the single-line variant

if (foo) bar;

There's no risk of introducing errors during refactoring or moving code, or incorrect indentation causing issues, and no risk of "goto fail".

That said, single-line if conditions should be used sparingly. They can increase code legibility, but they can also decrease it. But the only good reason to ban it is "because we don't want to make subjective code legibility calls", although the style guide already contains other rules that require code legibility calls (such as the one on the ternary operator).

from objective-c-style-guide.

I disagree that there's no risk of introducing errors. I would say it's quite high relatively speaking. A single line if() often becomes a multiline one and I don't want anyone to have to remember to retroactively add braces.

from objective-c-style-guide.

I disagree that there's no risk of introducing errors. I would say it's quite high relatively speaking

I agree with @paulbruneau here. I think the small benefit of concision is not worth the larger cost of having more than one way to do things and introducing subjective judgements into this part of the guide.

from objective-c-style-guide.