Is this C program doing what it is supposed to do ?

[Ian Collins]

That's a specious argument because the parentheses are
redundant in both cases.

Redundant to the compiler, but not to the human reader.

A newline after a ; is redundant to the compiler so do you write your
programmes on one line?

 

[Tim Rentsch]

IMHO it's not *entirely* specious.

Certainly the parentheses are redundant, but (for some reason I'm not
sure I can entirely explain) they seem more appropriate for the "=="
case than for the "=" case.

Chained assignments are usually written without parentheses:

var1 = var2 = some_value;

and if I see one *with* parentheses:

var1 = (var2 = some_value);

I know it means exactly the same thing, but I'm going to wonder why the
parentheses are there (hmm, maybe the second "=" was a typo for "=="?).

On the other hand, if I see:

at_beginning = ch == '\n';

it *might* occur to me that the "==" could be a typo for "=" -- but
in this case the meaningful names argue rather strongly against that.
I do find that superfluous parentheses:

at_beginning = (ch == '\n');

make it a bit easier to read (*for me*). I have a mild preference
for the version with the parentheses, and a strong preference for
either form over the verbose if/else version.

I suppose one could argue that adding the parentheses is catering
to ignorant readers just as much as using the verbose if/else form.
I would disagree with such an argument, but I'm not sure I can
articulate why.

I believe I understand what you're saying; to make sure let me
pose a question. Boiled down, is what you're saying anything
more than "people who share my sense of program style will find
the version with parentheses more clear"? If that's all you're
saying, of course I wouldn't argue with that. If you mean to say
more than that, that didn't come out (at least not to me) in
your message - can you explain further what it is?

More generally, C code has at least two audiences, the compiler and
human readers. I like to cater to the needs of the latter (for example,
by indenting my code, something the compiler couldn't care less about),
but I also like to assume that any human readers know the language
reasonably well. We're unlikely to reach universal agreement on where
to draw that line.

If all you're doing is expressing an opinion, I have no problem
with that. My personal opinion is that putting in redundant
parentheses is a disservice in this case. I share your view that
it's more important to write for the human reader than the
compiler, but here I don't believe the extra parentheses help
with that; in fact just the opposite. But that's not an
argument, it's just an expression of personal opinion. Do you
mean to make an argument (supporting this style choice), or
are you just expressing a personal opinion?

 

[Tim Rentsch]

Tim Rentsch wrote:
)> Well it is compared to
)>
)> at_beginning = (ch == '\n');
)>
)> it takes the reader longer to parse the first, is it an assignment to
)> at_beginning or to at_beginning and ch?
)>
)> at_beginning = ch = '\n';
)
) That's a specious argument because the parentheses are
) redundant in both cases.

The standard idiom when assigning one value to multiple variables is:

a = b = c = 1;

So when a random programmer sees such a statement, the first thing he
will think is: 'that looks like a multiple-assignment statement'.
To differentiate the assignment of the boolean result of a comparison,
it would seem prudent to add the parentheses.

a = (b == c);

This rationale begs the question. Of course if one _assumes_
people are going to be confused by leaving out the parentheses
then it makes sense to put in the parentheses, but that's a
circular argument. (Also a dangerous one, because it encourages
careless reading.) I don't agree with the assumption.

Even if we do assume that 'a = b == c' needs to be pointed out to
some non-careful readers, there are other (and better, IMO) ways
of doing that, as for example:

a = b==c;

a = b == c;

a = b == c; /* Note '==' */

Any of these should be enough to jog the attention of an
inattentive reader, but without the annoyance of a lingering
doubt about whether the author was confused about precedence.

 

[Tim Rentsch]

That's a specious argument because the parentheses are
redundant in both cases.

Depends on your programming style.

I'm more likely to look at [at_beginning = ch = '\n';] as double
assignment, but [at_beginning = (ch = '\n');] as a syntax error since
using parentheses in that assignment doesn't mesh with my personal
style preferences. On that point, I avoid statements that include
multiple assignments altogether as a style issue simply to reduce the
opportunity for encountering statements with semantic ambiguities.
It's also the main reason I don't like '=' in 'if' expressions.

If this was someone else's code, I'd have no style frame of reference
to know what semantics the original author intended (not without
reading other code written by that author), and it's particularly
problematic in code that is maintained by several authors with
different styles. The problem is not with the legality of the
statement itself, the problem is the perception of the semantics of
that statement by different people, especially when you're trying to
track down a bug.

Yes, it's because of this problem with multiple perceptions
that I would advocate something other than adding redundant
parentheses (some examples were given in my response to Willem).

 

[Tim Rentsch]

Redundant to the compiler, but not to the human reader.

A newline after a ; is redundant to the compiler so do you write your
programmes on one line?

The point is that the two cases are equally redundant, so
just adding the parentheses does nothing to differentiate
them.

See also my replies to Keith Thompson and Willem.

 

[ImpalerCore]

I believe I understand what you're saying;  to make sure let me
pose a question.  Boiled down, is what you're saying anything
more than "people who share my sense of program style will find
the version with parentheses more clear"?  If that's all you're
saying, of course I wouldn't argue with that.  If you mean to say
more than that, that didn't come out (at least not to me) in
your message - can you explain further what it is?


If all you're doing is expressing an opinion, I have no problem
with that.  My personal opinion is that putting in redundant
parentheses is a disservice in this case.  I share your view that
it's more important to write for the human reader than the
compiler, but here I don't believe the extra parentheses help
with that;  in fact just the opposite.  But that's not an
argument, it's just an expression of personal opinion.  Do you
mean to make an argument (supporting this style choice), or
are you just expressing a personal opinion?

Put simply, if the expected statement is [a = b == c;] and the two
typo statements are [a = b = c;] or [a = (b = c);], I would detect the
second typo with less effort. The intent of the '()' is not to add
verbosity for verbosity's sake, it's to add semantic meaning (to a
human) that the right-hand side should be a boolean expression, akin
to an error correcting code. This is purely a style issue which is
for the most part irrelevant if you don't have to share work with
anyone else's code, since you have your own style and should be
consistent with it. In the absence of errors, none of these
statements are ambiguous to interpret.

If you wanted empirical evidence, here's an experiment. Design a code
example that contains a typo in the style up above. Give group A the
typo [a = b = c;] and group B the type [a = (b = c);]. See what the
average time both groups of people come up with the correct fix. That
should at least give an inkling on whether the style issue matters to
people. One could use a beginner's computer science class as
unwitting test subjects.

And no I'm not asking you to change your style. But if we had to work
on the same code together, I would definitely feel a compulsion to put
parentheses around your [a = b == c;] statements, but not for
statements like [a = b < c]. Are you one that prefers [a = b == c &&
d == e] over [a = (b == c) && (d == e)]?

Best regards,
John D.

 

[ImpalerCore]

Depends on your programming style.

I'm more likely to look at [at_beginning = ch = '\n';] as double
assignment, but [at_beginning = (ch = '\n');] as a syntax error since
using parentheses in that assignment doesn't mesh with my personal
style preferences.  On that point, I avoid statements that include
multiple assignments altogether as a style issue simply to reduce the
opportunity for encountering statements with semantic ambiguities.
It's also the main reason I don't like '=' in 'if' expressions.

If this was someone else's code, I'd have no style frame of reference
to know what semantics the original author intended (not without
reading other code written by that author), and it's particularly
problematic in code that is maintained by several authors with
different styles.  The problem is not with the legality of the
statement itself, the problem is the perception of the semantics of
that statement by different people, especially when you're trying to
track down a bug.

Yes, it's because of this problem with multiple perceptions
that I would advocate something other than adding redundant
parentheses (some examples were given in my response to Willem).

Normally, I wouldn't care at all because it's a style issue. But you
called my parentheses specious and I don't understand why. Are '()'
really that detrimental to good coding style? I just don't see
exactly what the negative consequences are from [a = (b == c)].

If you think it demonstrates my lack of appreciation or understanding
of precedence rules, then I think we'll just have to agree to disagree
on that point.

Best regards,
John D.

 

[Keith Thompson]

I believe I understand what you're saying; to make sure let me
pose a question. Boiled down, is what you're saying anything
more than "people who share my sense of program style will find
the version with parentheses more clear"? If that's all you're
saying, of course I wouldn't argue with that. If you mean to say
more than that, that didn't come out (at least not to me) in
your message - can you explain further what it is?

Hmm, good question. I suppose ultimately it's really just a matter of
personal preference. Nevertheless, I think I'll try to justify it (I
don't expect this to convince anyone).

Consider these two expression statements:

var1 = var2 = some_value;
var1 = var2 == some_value;

Both have exactly the same precedence hierarchy; if you built a parse
tree from each (I won't take the time to draw it), it would look
identical except for the use of "=" in one and "==" in the other.

But the first is an example of a fairly common pattern, a chained
assignment. Even though it's *really" an assignment to var1,
whose RHS happens to be an assignment expression, it can reasonably
be thought of as something more linear than that. It could be
extended to:

var1 = var2 = var3 = var4 = var5 = some_value;

(though I'd certainly question the need for something like that).

It's similar in that respect to an if/else chain; we write:

if (cond1) {
stmt1;
}
else if (cond2) {
stmt2;
}
else if (cond3) {
stmt3;
}
else {
stmt4;
}

rather than

if (cond1) {
stmt1;
}
else {
if (cond2) {
stmt2;
}
else {
if (cond3) {
stmt3;
}
else {
stmt4;
}
}
}

The latter corresponds more closely to the parse tree; the former
corresponds to the more linear way we think about it. (Of course we
could have arbitrarily complex trees of nested if/else statements,
but the linear form is quite common.)

On the other hand, in the second statement, though it has the same
structure, var1 and var2 play very different roles. var2 is compared
against some_value, and the result is assigned to var1. (Yes, I'm
stating the obvious.) It doesn't have the same linear structure
that a chained assignment has. We *could* write

var1 = var2 == var3 == var4 == var5 == some_value;

but it's hardly likely that it would make sense (and if it did,
I'd definitely want to add some parentheses).

In my personal opinion, adding superfluous parentheses:

var1 = (var2 == some_value);

both emphasizes the structure of the expression and makes it stand out
more clearly versus another common idiom:

var1 = var2 = some_value;

that otherwise looks very similar.

But yes, I'm pretty much saying that "people who share my sense of
program style will find the version with parentheses more clear".
}

 

[Keith Thompson]

If you wanted empirical evidence, here's an experiment. Design a code
example that contains a typo in the style up above. Give group A the
typo [a = b = c;] and group B the type [a = (b = c);]. See what the
average time both groups of people come up with the correct fix. That
should at least give an inkling on whether the style issue matters to
people. One could use a beginner's computer science class as
unwitting test subjects.

[...]

The real problem with both expressions is the use of meaningless names.
Give "a" a name that makes it obvious that it's a condition (like
"at_beginning"), and I'll be you'll get better results.

 

[Keith Thompson]

Even if we do assume that 'a = b == c' needs to be pointed out to
some non-careful readers, there are other (and better, IMO) ways
of doing that, as for example:

a = b==c;

a = b == c;

a = b == c; /* Note '==' */

Any of these should be enough to jog the attention of an
inattentive reader, but without the annoyance of a lingering
doubt about whether the author was confused about precedence.

I'm curious: why is adding whitespace better than adding parentheses?

When I see redundant parentheses, I don't generally assume that the
author mistakenly thought they were necessary; I assume that the
author thought that, even though they're not strictly necessary,
they improve readability.

And doesn't adding or removeing white space as you suggest raise
exactly the same question? "Hmm, the author is using white space
to show that == binds more tightly than =; did he think I didn't
know that? Worse, did he think that the white space actually
affects precedence?"

And white space can disappear when the code is run through a
formatter like "indent".

 

[ImpalerCore]

[...]> If you wanted empirical evidence, here's an experiment.  Design a code

example that contains a typo in the style up above.  Give group A the
typo [a = b = c;] and group B the type [a = (b = c);].  See what the
average time both groups of people come up with the correct fix.  That
should at least give an inkling on whether the style issue matters to
people.  One could use a beginner's computer science class as
unwitting test subjects.

[...]

The real problem with both expressions is the use of meaningless names.
Give "a" a name that makes it obvious that it's a condition (like
"at_beginning"), and I'll be you'll get better results.

I didn't mean an example using the literal code statements [a = b = c]
and [a = (b = c)]. In the experiment, the 'a', 'b', and 'c' would be
placeholders for meaningful names (like Keller's example). I think
most of us here agree that using single letter variables names in most
instances (except for idiomatic things like loop indexes) is poor
style.

I agree that appropriately chosen variable names can help detection of
these mistypes as well.

Best regards,
John D.

 

[Tim Rentsch]

I'm curious: why is adding whitespace better than adding parentheses?

Basically there are two reasons: visual processing, and cognitive
load. I find that my eyes have to work harder when the extra
parentheses are there. I'm not sure how much harder exactly, but
it's enough that I notice the difference, and that costs something
in terms of attentiveness. Extra whitespace doesn't fatigue my
eyes the way extra parentheses do.

About cognitive load - please read on.

When I see redundant parentheses, I don't generally assume that the
author mistakenly thought they were necessary;

I also don't assume that but I do sometimes wonder ....

I assume that the
author thought that, even though they're not strictly necessary,
they improve readability.

I don't assume this one either; I'm basically just left wondering.
The uncertainty adds to my cognitive load.

And doesn't adding or removeing white space as you suggest raise
exactly the same question?

No, certainly not the _same_ question. Some other questions (see
below) but they don't carry the same cognitive load.

"Hmm, the author is using white space
to show that == binds more tightly than =; did he think I didn't
know that?

That question is one I don't care about. Obviously some people
think some (other) people aren't as familiar with precendence
rules as they should be. The extra-whitespace author may have
done so to help those other people out. Or, he may have done so
to provide better visual clustering to help readers "chunkify"
the code more easily. Either way, it's not something I have to
think about, because I don't have to wonder about whether he's
confused.

Worse, did he think that the white space actually
affects precedence?"

First I find it hard to believe any C programmer who has had any
real experience would make that mistake. But even supposing
there are such people, as long as their extra-whitespacing is
done so that it's consistent with actual precedence rules,
there's no need to worry. This aspect is one where whitespace
offers a definite advantage over parentheses. Because whitespace
(unlike parentheses) does _not_ affect how an expression is
parsed, the two can be compared against each other. Using extra
whitespace provides a kind of "precedence error-correcting code",
if you see what I mean. Parentheses can't do that, because the
whole reason they are there (logically speaking) is to change
grouping.

And white space can disappear when the code is run through a
formatter like "indent".

Yes that is certainly true, and that's one reason why formatters
that insist on "homogenizing" whitespace aren't very good tools.
Better formatters should be able (subject of course to parameters
and options settings) to preserve extra whitespace.

 

[Keith Thompson]

First I find it hard to believe any C programmer who has had any
real experience would make that mistake.

Agreed; I was probably overstating the case a bit.

But even supposing
there are such people, as long as their extra-whitespacing is
done so that it's consistent with actual precedence rules,
there's no need to worry. This aspect is one where whitespace
offers a definite advantage over parentheses. Because whitespace
(unlike parentheses) does _not_ affect how an expression is
parsed, the two can be compared against each other. Using extra
whitespace provides a kind of "precedence error-correcting code",
if you see what I mean. Parentheses can't do that, because the
whole reason they are there (logically speaking) is to change
grouping.

That last point, I think, is the core of our disagreement. Changing
grouping is not "the whole reason" for parentheses. They can also be
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

Another example: if I see:

if (foo || bar && baz) ...

it takes me a moment to remember that "&&" binds more tightly than "||".
I know it does, but it is, at least for me, a bit of a cognitive load
(to use your phrase). I personally find:

if (foo || (bar && baz)) ...

to be easier to read, even though I know it means exactly the same
thing. And for me, the parentheses do a better job of clarifying the
code than whitespace would:

if (foo || bar&&baz) ...

Also, I dislike operators without surrounding whitespace, and having to
tell the difference between once space and two spaces also adds to my
cognitive load.

[...]

 

[Tim Rentsch]

I believe I understand what you're saying;  to make sure let me
pose a question.  Boiled down, is what you're saying anything
more than "people who share my sense of program style will find
the version with parentheses more clear"?  If that's all you're
saying, of course I wouldn't argue with that.  If you mean to say
more than that, that didn't come out (at least not to me) in
your message - can you explain further what it is?


If all you're doing is expressing an opinion, I have no problem
with that.  My personal opinion is that putting in redundant
parentheses is a disservice in this case.  I share your view that
it's more important to write for the human reader than the
compiler, but here I don't believe the extra parentheses help
with that;  in fact just the opposite.  But that's not an
argument, it's just an expression of personal opinion.  Do you
mean to make an argument (supporting this style choice), or
are you just expressing a personal opinion?

Put simply, if the expected statement is [a = b == c;] and the two
typo statements are [a = b = c;] or [a = (b = c);], I would detect the
second typo with less effort. [snip elaboration]

So is it fair to say you also are just expressing a personal
opinion?

If you wanted empirical evidence, here's an experiment. Design a code
example that contains a typo in the style up above. Give group A the
typo [a = b = c;] and group B the type [a = (b = c);]. See what the
average time both groups of people come up with the correct fix. That
should at least give an inkling on whether the style issue matters to
people. One could use a beginner's computer science class as
unwitting test subjects.

I think it's good to do experiments something like this. This
particular one, however, has some shortcomings. First it
measures only one dimension of performance and ignores others;
put more simply, it measures a benefit but makes no attempt to
measure cost. Second, it assumes that the weighting factor on
the benefit is high enough to make it worthwhile; if it takes
one group an extra hour (say) to correct the problem, but the
problem only occurs once every million man-hours of development
time, the relative gain is probably not worth the cost. Third,
there's no mention of possible alternatives; another approach
to addressing the supposed problem may very well produce higher
benefit and also lower cost.

And no I'm not asking you to change your style. But if we had to work
on the same code together, I would definitely feel a compulsion to put
parentheses around your [a = b == c;] statements, but not for
statements like [a = b < c]. Are you one that prefers [a = b == c &&
d == e] over [a = (b == c) && (d == e)]?

Personally I find most redundant parentheses incur more cost
than benefit, which is explained in more detail in another
reply (to Keith Thompson) in this thread. For the example
you're asking about, I find it easier to read

a = b==c && d==e;

or

a = b == c && d == e;

depending on the actual names involved, than either of the
aforementioned alternatives.

 

[Tim Rentsch]

On 02/ 7/11 10:56 AM, Ben Bacarisse wrote:
<snip>
The line (justifiably) deemed appalling was:

at_beginning = ch == '\n';

Ah, maybe you'd explain why it's appalling?  Chris H won't say despite
being asked.  Do you also agree with him that it's dangerous?

Well it is compared to

at_beginning = (ch == '\n');

it takes the reader longer to parse the first, is it an assignment to
at_beginning or to at_beginning and ch?

at_beginning = ch = '\n';

That's a specious argument because the parentheses are
redundant in both cases.

Depends on your programming style.

I'm more likely to look at [at_beginning = ch = '\n';] as double
assignment, but [at_beginning = (ch = '\n');] as a syntax error since
using parentheses in that assignment doesn't mesh with my personal
style preferences.  On that point, I avoid statements that include
multiple assignments altogether as a style issue simply to reduce the
opportunity for encountering statements with semantic ambiguities.
It's also the main reason I don't like '=' in 'if' expressions.

If this was someone else's code, I'd have no style frame of reference
to know what semantics the original author intended (not without
reading other code written by that author), and it's particularly
problematic in code that is maintained by several authors with
different styles.  The problem is not with the legality of the
statement itself, the problem is the perception of the semantics of
that statement by different people, especially when you're trying to
track down a bug.

Yes, it's because of this problem with multiple perceptions
that I would advocate something other than adding redundant
parentheses (some examples were given in my response to Willem).

Normally, I wouldn't care at all because it's a style issue. But you
called my parentheses specious and I don't understand why.

Please note, what I said was that the _argument_ is specious,
not that the parentheses are. It's important to understand
the difference in those two statements.

Are '()'
really that detrimental to good coding style? I just don't see
exactly what the negative consequences are from [a = (b == c)].

I explained (some of) my views on what these consequences are (as
seen through my perception filters) in my reply to Keith
Thompson.

If you think it demonstrates my lack of appreciation or understanding
of precedence rules, then I think we'll just have to agree to disagree
on that point.

The problem -- well, one of them at any rate -- is that when I'm
reading code and I run across redundant parentheses like these,
I'm not sure _what_ to think as to what the cause or intended
reasoning is. I don't assume that the author is an idiot; on
the other hand I can't always rule it out either. So to answer
your implied question, no, I don't think it demonstrates a lack
of understanding; but it doesn't necessarily demonstrate an
understanding either, and that uncertainty is a distraction.

 

[Tim Rentsch]

Agreed; I was probably overstating the case a bit.


That last point, I think, is the core of our disagreement. Changing
grouping is not "the whole reason" for parentheses.

I think you misunderstood what I was trying to say (and I take
the blame for that, I didn't say it very clearly). I don't mean
that parentheses can't be used for purposes other than grouping,
obviously they can; I mean that using parentheses in expressions
can't be done _without_ determining the grouping (which might be
the same grouping that would occur without the parentheses, but
parentheses force a grouping whether the grouping is changed or
not).

They can also be
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

Yes, obviously many people do this.

Another example: if I see:

if (foo || bar && baz) ...

it takes me a moment to remember that "&&" binds more tightly than "||".
I know it does, but it is, at least for me, a bit of a cognitive load
(to use your phrase). I personally find:

if (foo || (bar && baz)) ...

to be easier to read, even though I know it means exactly the same
thing. And for me, the parentheses do a better job of clarifying the
code than whitespace would:

if (foo || bar&&baz) ...

For these operators I think more spacing works better than less:

if( foo || bar && baz )

Also, I dislike operators without surrounding whitespace,

I expect you and I are actually pretty close on this one. For
some operators (and some operands) having no surrounding
whitespace works okay, but the operators here aren't in that set.

and having to
tell the difference between once space and two spaces also adds to my
cognitive load.

I would like to suggest that your reaction may be caused simply
by lack of familiarity. If you actually tried using extra
whitespace in place of redundant parentheses for two or three
months you might find your perceptions and reactions are not
what you think they would be. I've done similar trials with
other people, so I'm not just talking through my hat here.

 

[Dr Nick]

If you wanted empirical evidence, here's an experiment. Design a code
example that contains a typo in the style up above. Give group A the
typo [a = b = c;] and group B the type [a = (b = c);]. See what the
average time both groups of people come up with the correct fix. That
should at least give an inkling on whether the style issue matters to
people. One could use a beginner's computer science class as
unwitting test subjects.

[...]

The real problem with both expressions is the use of meaningless names.
Give "a" a name that makes it obvious that it's a condition (like
"at_beginning"), and I'll be you'll get better results.

You can have pretty meaningful names and no clarity.

How about:
at_beginning = have_we_finished == at_start_of_line;

Is that a typo?

For the record I'm for the ()s, but accept it is a style point. I don't
think it's a "how many spaces" or "where do the braces go" style point
which are pure personal preference. It's more akin to putting ()s
around sub expression when mixing logical and binary operators, or
putting white space in: hyp2 = x*x + y*y;

 

[ImpalerCore]

Put simply, if the expected statement is [a = b == c;] and the two
typo statements are [a = b = c;] or [a = (b = c);], I would detect the
second typo with less effort.  [snip elaboration]

So is it fair to say you also are just expressing a personal
opinion?

Sure it's my personal opinion, but the style of using of parentheses
to emphasize grouping is pretty common in the teaching and books used
when I was learning C and C++. Use of spaces, not so much. In fact I
think you're the first person I've met that advocates using space over
parentheses to emphasize precedence in the manner you're describing.

If you wanted empirical evidence, here's an experiment.  Design a code
example that contains a typo in the style up above.  Give group A the
typo [a = b = c;] and group B the type [a = (b = c);].  See what the
average time both groups of people come up with the correct fix.  That
should at least give an inkling on whether the style issue matters to
people.  One could use a beginner's computer science class as
unwitting test subjects.

I think it's good to do experiments something like this.  This
particular one, however, has some shortcomings.  First it
measures only one dimension of performance and ignores others;
put more simply, it measures a benefit but makes no attempt to
measure cost.  Second, it assumes that the weighting factor on
the benefit is high enough to make it worthwhile;  if it takes
one group an extra hour (say) to correct the problem, but the
problem only occurs once every million man-hours of development
time, the relative gain is probably not worth the cost.  Third,
there's no mention of possible alternatives;  another approach
to addressing the supposed problem may very well produce higher
benefit and also lower cost.

A lot of experiments can have shortcomings, especially those with
humans as the test subjects. I would still find it an interesting
tidbit to know if there was cognitive difference for programmers as a
population even for this simple example. The notion of using
whitespace vs parentheses to emphasize semantic meaning in programming
language would be an interesting study. I'm not sure how interested
cognitive psychologists are in studying programmers; we're probably
pretty boring.

[snip]

Best regards,
John D.

 

[ImpalerCore]

On Feb 10, 12:37 am, Tim Rentsch <[email protected]> wrote:

[snip] Should have been.

Sure it's my personal opinion, but the style of using of parentheses
to emphasize *precedence* is pretty common in the teaching and books
used
when I was learning C and C++.

 

[Tim Rentsch]

ImpalerCore <[email protected]> writes:

[... discussing 'a = b == c;' vs 'a = (b == c);' ...]

Put simply, if the expected statement is [a = b == c;] and the two
typo statements are [a = b = c;] or [a = (b = c);], I would detect the
second typo with less effort. [snip elaboration]

So is it fair to say you also are just expressing a personal
opinion?

Sure it's my personal opinion, but the style of using of parentheses
to emphasize precedence is pretty common in the teaching and books used
when I was learning C and C++.

Remember Dijkstra's admonition: don't think something is _convenient_
just because it is _conventional_. Advising students to use extra
parentheses has been around at least since the 1960's when I first
learned how to program. Offered in beginning classes, it's the
programming equivalent of training wheels on a bicycle -- useful to
get people started, but no real help once the necessary skills have
been acquired. I no longer use training wheels on my bicycle, and I
don't think it's important in my everyday riding to cater to beginners
who still need them.

Use of spaces, not so much. In fact I
think you're the first person I've met that advocates using space over
parentheses to emphasize precedence in the manner you're describing.

People used to think the Earth was the center of the universe and
everything else revolved around it. Are you charging me with being
a heretic? Just because you're hearing an idea for the first time
doesn't mean the idea is bad; it's much more convenient to think of
the Earth as going around the Sun than vice versa, as repulsive as
that idea was to people when it was first proposed.

It would be nice if you tried to engage in an actual discussion
of the merits and shortcomings of a proposed alternative, rather
than just making an ad hominem remark and dismissing it.