I agree style matters but I also think that your style is no more
right or wrong than someone else's style.
That is a moderately testable claim.
The key thing is that code is intended to communicate. You have to think
about what the code communicates.
There is a reason that, when we have indentation wars, you will
rarely see someone advocate for:
if (x)
{ if (y) {
z;}}
In this case it seems to me that your
argument makes sense but it also seems to me that someone who says I
don't care that the value is 0 I care that the meaning is false and
(x==y) conveys false to them in a more clear manner than 0 does is
also a reasonable view.
Not in C.
And that's the thing -- we're not working in a pure void, we're working
in an existing language with established conventions and patterns. And
in that language, since everyone knows what the boolean operators yield,
anyone who writes something like this is indirectly communicating that
they don't understand the boolean operators.
Furthermore if they know that it results in
the same thing it is simply stylistic and in my opinion anything that
is stylistic only is not right or wrong only different.
Then your opinion is wrong. See the indentation example above.
There are certainly cases where there's room to assert that a matter of
style is purely a matter of taste, but there are plenty of ways you can
make something which is purely stylistic (as in, the same code will
be generated), where one is clearly superior to another in terms of
long-term maintenance and use of code.
Where we part
ways is in the thinking that if someone does not agree with your
stylistic view then everything else they do warrants no more
consideration, seems like an awfully small minded way of thinking to
me.
Not "no more consideration". Merely that, if a particular choice is
sufficiently unreasonable, that warns me that either they don't understand
the language (in which case I need to exercise additional caution in
dealing with their code), or they are prone to making poor decisions
(in which case I need to exercise additional caution in dealing with their
code).
Some kinds of errors or style choices make me more concerned than others.
If I read a block of sixty or so variable declarations which are in no
particular order, of various types for no obvious reason, and with a bunch
of names which are nonsensical or suggest contradictory nomenclatures, I
know *already* that I'm about to read some bad code. Knowing that is useful.
There's a similar pattern; if you see a car with a bashed-in fender, you
can often predict that it will move erratically in ways which, if you are
not taking care on that driver's behalf, would cause you to bash in that
fender. If you have evidence of poor style, being cautious is generally
rewarding.
I would agree with you that you could get carried away with this
as you mentioned with TRUE = (((1!=0)!=(1!=1))!=0) but that is not
really what we are talking about.
How is it different?
-s
