On Fri, 26 Aug 2011 11:03:21 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
It's a legitimate concern, and there's no right response to it. My point
is that the argument is weak and caving to it would be a mistake. In
essence Nick claims he can't be bothered to change:
if (long_expression_one)
if (long_expression_two)
if (long_expression_three)
statement
with
if ((long_expression_one)
&& (long_expression_two)
&& (long_expression_three))
statement
which adds a grand total of two parens. The claim "blah blah long thing
with the simple unrelated condition requiring ugly line breaks and
screwy formattng/alignment in a big pita to read uber-expression. fuck
this shit. It looks ok in english, but in code the damn thing reads like
a fucking regex" does not stand scrutiny, and mixing in the matter of
indentation is a red herring as indentation is unaffected by the
introduction of the rule.
I'll also note that the argument smacks of the misleading vividness
fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). We
shouldn't shelve an idea because a poor argument against it was
eloquently phrased.
Finally, we've derived significant benefits from ideas in the same
spirit. I don't see signs that we've started overdoing it, or that the
returns are diminishing. To me all signs point to a fertile approach to
explore.
Hm... the only problem I see with simply disallowing if(a) if(b) is this:
if(a)
while(condition)
if(b)
statement;
else // oops! this goes with if(b)
statement;
Or would this be disallowed as well? This could not be combined into a
single if statement obviously, so the only the option to fix this is
adding braces.
I'd hate to see this disallowed, which seems perfectly legitimate:
if(a)
while(condition)
if(b)
statement;
-Steve
