L
luser- -droog
Like machine code? Is there no room for notational convenience,
or higher-level systems? Or hybrids?
Like machine code? Is there no room for notational convenience,
or higher-level systems? Or hybrids?
A
Anders Wegge Keller
If you cannot explain *WHY* the cramped style is safer, then you lose
the argument. Repeating the fallacy that fewer characters means fewer
errors is not an explanation.
The original code was "a = b == c;", so I will pretend that you
didn't move the goalpost on purpose.
My experience tells me otherwise. The problem is not usage in a
simple case like this, where it's just a nuisance, when I hav to guess
the intention. But the coding style creeps into more and more complex
structures, where you end up with code that is more clever than the
programmer or the compiler[1].
Whereas I have to guess if "a = b == c" is intended or not, I have no
doubt what was intended with the explicit if. You may have the
privilege of never touching code you haven't written yourself. I
don't, which have made me a bitter and grumpy old man.
You are moving the goalposts again. This time you are inventing a
completely different pattern. I have never stated an opinion about
this, but if you feel you have to argue against a strawman, Ã'll take
that as an apology.
I don't teach C, I just fix the mistakes of a decade worth of
"clever" people who confuse terseness with clarity.
1. SCO OpenServer Development System.
C
Chris H
Richard said:
This is CRAP the studies show otherwise.
But the line was
f=a==b
Now you see the problems we face.
H
Hans Vlems
Hans Vlems said:Read my earlier posts; look for the [snip] entries
Text is possibly the worst way to clarify an issue.
Text is all we've got here. If you're not interested in clarifying
what you wrote before, I guess there's nothing else to say.
I find it frustrating when someone disagrees with something I've
written and doesn't clearly explain why, or respond to questions
about it. I *like* having my ideas challenged. It's always possible
that I'm wrong, and that someone else has a better idea than I do.
But if you aren't willing to enage in discussion, then neither of
us will learn anything.
--
Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"- Tekst uit oorspronkelijk bericht niet weergeven -
- Tekst uit oorspronkelijk bericht weergeven -
Keith, this usenet group is more about language syntax rather than its
perceived semantic beauty ;-)
And I felt that my point was too much of the latter.
My point was that in a language that supports the type boolean, it
usually has two states TRUE or FALSE (whatever way it gets
implemented).
So a construct like b:=<boolean expression> is very much in line with
the sematics of such a language.
In C, any non-zero value translates to TRUE. Convenient, the standard
libraries rely on it.
At the same time it makes e hesitate to write if (b==1) in C because
it is not the same as if (b).
The workaround is if (b!=0) but that is (to me) less pleasing to the
eye and, IMVHO, confuses the issue of a boolean expression.
An expression like:
if (c==684)
b=1;
else
b=0;
which came up in onother track of this post, obviously has its
supporters here.
In Algol or Pascal,
IF (C=684) THEN B:=TRUE ELSE B:=FALSE;
is fairly ugly,
B:=C=684;
is "better".
Perhaps the fact that the choice of assignment operator in Algol and
Pascal makes a difference.
Hans
H
Hans Vlems
I prefer the second form, provided flag is a boolean that is either
true or false.
The way it works in C is that the second form is actuall a test of
"compare this value with zero".
Which is, while a valid boolean expression, not the same as a boolean.
Hans
B
Ben Bacarisse
Anders Wegge Keller said:
I can't say it's beautiful because I don't think it is and I never
claimed it was. The code is safe in as much as it is correct. It is
also unsafe in that all code is prone to errors.
The main point was to bring together into one place the condition that
set at_beginning. In the original code, it was set conditionally in two
places. Simpler logic makes for safer programs.
I don't understand the fear people seem to have about typos. I don't
remember any hard to find bugs that were down to operator confusions or
miss-bracketing of expressions. Unit tests usually pick them up. All
the hard bugs and maintenance problems that have stuck in my mind come
from overly complex code or logical errors[1]. I'll always opt to keep
the logic as clear and simple as possible.
The suggestion I made was not supposed to end up in an argument about
brackets (I would not have commented further if the only remark had been
in favour of bracketing the conditional) but was meant to highlight
keeping the logic simple. Of course, it always looks trivial in a
simple program like this, but when programs get bigger I'd rather read
one with clear logic but which requires me to know C's precedence rules
than one with tortured logic and few more brackets.
[1] There's an even bigger maintenance problem with design or
"architecture" errors but that's another matter altogether.
C
Chris H
Richard said:
I am not sure you would recognise one. You have an ego in the way.
Nuff said.I have had to debug code from people like you.
So you agree with me then
B
Ben Bacarisse
Anders Wegge Keller said:
Ultimately that is all we have. I doubt either of us an sound scientific
evidence for our positions but I have also said more in another post.
I hope that it will explain my view even if it does not convince you.
That was not the alternative I was commenting on. However, I still that
this is overly long winded though it does not complicate the logic much.
I am not happy that anyone thinks I was showing off but there is nothing
that I can do about that. Maybe we should have a thread about overly
clever code constructs so that we can see what is considered tricksy and
what is considered simple code.
Absolutely not. Had the variable been called x, yes, but I also
strongly urged the use of a "biased" name. Once I've seen "at_beginning
= " I expect a conditional and an alarm bell ring if I don't see on. To
me, the above look shockingly different.
B
Ben Bacarisse
Anders Wegge Keller said:
You've moved them! The names of the variables, the constant involved
and the context all matter.
In the original, miss-reading (or typing) = for == would leave the
reader wondering why at_beginning was always being set, unconditionally,
in a loop, to \n'.
To my mind it is clear what is intended. If you clip the context and
change the variables and the constant involved, sure, you can make it
confusing. In
if (b == c) {
a = 1;
} else {
a = 0;
}
I have to guess that 0 and 1 were intended and that the order is
correct. I can't tell from the variable names and condition alone.
<snip>
A
Anders Wegge Keller
If you don't particular like it, why defend it in the first place?
There is no such thing as simple logic in the real world. The pattern
may start out being benign and somewhat readable, but when several
iterations of changed requirements hyave transformed it into a mess of:
some_condition = (input == 0x42 ||
moon_phase = M_WAXING && input == 042) &&
a_hideously_long_name_caused_by_a_fad_in_2003 != flabbergast;
Then you won't spot the typo. Notice how the guy who added the last
clause in 2003 despaired of understanding it, and wrapped the whole
mess in (), in order to feel better about it.
Except for the names, this is actual code created by hybridizing the
patterns "a = b == c" and "Add yet another boundary condition". I have
seen my share of crappy code, as have anyone working os customer
customized projects, and I know where the evil starts.
Did you spot it before I mentioned it?
[snip]
A
Anders Wegge Keller
Actually, Richard started by boiling it down to single letter names.
I'm not particularly interested in this specific situation. I'm
advocating against the pattern itself, as it leads to horrible
code. Even inside brackets, it becomes an eysore in some cases:
if ( ( i = sscanf( &buf[0], Format,
&tmpstr[0][0], &tmpstr[1][0], &tmpstr[2][0]))
== NUM_Fields ) {
If you pick apart the bits, you will find "i = (sscanf() ==
NUM_Fields)" inside it. It even have the set of brackets that some
have deemed adequate for making stuff clear. I seriously hope that you
will agree that this is not an example of a piece of code that is made
clearer and more readable by a = b == c.
Patterns will be used, even where they are not appropriate.
The world hardly ever provides situations as simple as this textbook
example.
B
Ben Bacarisse
Anders Wegge Keller said:
Eh? I prefer it and I said why.
No and I did not say that. I said "simpler" and some logic is simpler
than others. The OP had logic that was, to my mind, more complex than
it need be.
Why not, it seems obvious to me? Why would the tests not pick this up
immediately? Why is the typo "hidden" in that code and not in something
like this?
if ((input == 0x42 ||
moon_phase == M_WAXING && input == 042) &&
a_hideously_long_name_caused_by_a_fad_in_2003 != flabbergast) {
some_condition = 0;
} else {
some_condition = 1;
}
Anyway, this is not the point! I don't mind if you insist on writing a
if to set a logical variable (though I see it as no safer to do so -- it
just introduces more opportunities for errors). The original code set
the variable in two places (conditionally) and it is that trend that I
was warning against. If modifications continue to add further places
where it is set, the logic will deteriorate even further.
If the program's evolution requires that the condition gets more
complex, so be it. There is nothing one can do about that other than,
at some point, moving the condition into a separately documented function.
No, I see that they needed the brackets to get the right meaning or, if
they did it to "feel better about it" rather than needing it they have
introduced a bug. Exactly the same applies to both versions -- the
extra brackets are either needed or they are a bug. Obviously I can't
say which without know the purpose of the code.
Of course I did.
K
Keith Thompson
[snip]Anders Wegge Keller said:
That's *very* different from the original example.
The original example was something like:
at_beginning = ch == '\n';
or, with parentheses (which I agree are helpful):
at_beginning = (ch == '\n');
This expression has *no* side effects other than the top-level
assignment.
You're extrapolating from this to an expression used as an if()
condition with a subexpression that has the side effect of assigning
a value to an object.
Speaking only for myself, I probably wouldn't write your more complex
example; I'd probably write the assignment as a separate statement,
and I'd choose a name other than "i". But I have to be prepared
to read and understand that kind of expression when reading C code
written by others.
But I find
at_beginning = (ch == '\n');
perfectly clear and less error-prone than the if/else alternative.
(On the other hand, it does have a different meaning than
if (ch == '\n') {
at_beginning = 1;
}
which leaves at_beginning alone when ch != '\n'.)
K
Keith Thompson
Hans, you appear to have ignored this advice.
[...]
This particular discussion is mostly about semantic beauty, and there's
nothing wrong with that. It's a big part of good programmng in C.
Of course.
So write "if (b)" -- and give "b" a name that clearly indicates that it
represents a condition.
Yes, and I find the C equivalent better for exacly the same reasons.
My point is that we needn't be entirely limited by the semantics of the
language we're using. C90 doesn't have a boolean type. C99 does, but
the equality and relational operators still yield results of type int,
and conditions are still defined in terms of comparison to zero.
Nevertheless, we can write clear code that treats boolean expressions as
boolean expressions. We don't have to get lost in an analysis of how
each expression is evaluated in whatever context it appears in. With
carefully chosen idioms, we can write code that expresses its intent as
clearly as possible, without adding unnecessary verbosity just because
there's no explicit boolean type, or just because we don't happen to be
using it.
We can write:
at_beginning = (ch == '\n');
...
if (at_beginning) {
...
}
and the code works *exactly* the same way as it would if "=="
yielded a bool result and if() took a bool condition.
The extra verbosity of
if (ch == '\n') {
at_beginning = 1;
}
else {
at_beginning = 0;
}
gains us exactly *nothing*.
[...]
This particular discussion is mostly about semantic beauty, and there's
nothing wrong with that. It's a big part of good programmng in C.
Of course.
So write "if (b)" -- and give "b" a name that clearly indicates that it
represents a condition.
Yes, and I find the C equivalent better for exacly the same reasons.
My point is that we needn't be entirely limited by the semantics of the
language we're using. C90 doesn't have a boolean type. C99 does, but
the equality and relational operators still yield results of type int,
and conditions are still defined in terms of comparison to zero.
Nevertheless, we can write clear code that treats boolean expressions as
boolean expressions. We don't have to get lost in an analysis of how
each expression is evaluated in whatever context it appears in. With
carefully chosen idioms, we can write code that expresses its intent as
clearly as possible, without adding unnecessary verbosity just because
there's no explicit boolean type, or just because we don't happen to be
using it.
We can write:
at_beginning = (ch == '\n');
...
if (at_beginning) {
...
}
and the code works *exactly* the same way as it would if "=="
yielded a bool result and if() took a bool condition.
The extra verbosity of
if (ch == '\n') {
at_beginning = 1;
}
else {
at_beginning = 0;
}
gains us exactly *nothing*.
K
Keith Thompson
Anders Wegge Keller said:
Yes, there is.
Ok, so something that started out as a perfectly reasonable assignment
statement:
some_condition = (foo == bar);
gradually mutated into a confusing mess. That's no reason not to write
the perfectly reasonable assignment in the first place.
Are you suggesting that
if (foo == bar) {
some_condition = 1;
}
else {
some_condition = 0;
}
is immune to such problems? Isn't it more likely that a maintenance
programmer would try to make the same change to both branches of
the if/else, and likely get one of them wrong?
The evil start when you take existing clean code and make it overly
complex. The solution isn't to avoid writing clean code in the first
place. The solution is to be more careful during maintenance.
[...]
Let's suppose that, apart from the typo (042 for 0x42), the above
expression accurately reflects the intended semantics. How would
you write it more clearly? Personally, I'd add at least one set of
parentheses and align the subexpressions to reflect the semantic
grouping. I'd also pick more meaningful names. But I'd probably
keep the pattern of assigning the result condition to a variable
with a meaningful name.
Would you replace all the "&&" and "||" operators with a nest of
if/else statements?
B
Ben Bacarisse
Anders Wegge Keller said:
OK, but you did not need to keep them! They do matter.
Eh? All I can see is what is written and it's not of that form. Its
shape is (i = sscanf(...)) == CONST and the brackets are required
(unless they are a big of course).
Had i = (sscanf() == CONST) been the intended shape (maybe written
without the parentheses) then I'd be very wary of it because 'i' is such
a bad name of a logical variable -- it should have been a "biased" name
like 'parse_ok' or 'all_inputs_seen' or some such.
Surely it would simply be wrong if it were re-written using the a = b ==
c pattern (including a = (b == c))? In this case clarity does not come
into it.
Yes -- I agree that as conditions get more complicated, brackets help
more and more -- but in this specific case it looks correct and
minimally bracketed. I'd prefer a better name than 'i' and I am not a
fan of the &E[0] pattern so I'd probably have written:
if ((n_inputs = scanf(buf, Format,
tmpstr[0], tmpstr[1], tmpstr[2]))
== NUM_Fields) {
but none of that has much to do with what we've been discussing.
<snip>
C
Chris H
Keith Thompson <kst- said:
No it started as
some-condtion= foo==bar;
A
Anders Wegge Keller
If that holds true for you, then you are one lucky guy
With the risk of making this sound like a rant, My world consists of
an event driven control system, distributed over anything from 15 to
45 processes, 3 to 5 interface cards with their own CPU, talking to a
bunch of distributed nodes, with yet another level of code. That mess
controls various sorting machines that generate events by means of
upwards of 50 operators doing stuff in a random order.
In other contexts, this would be called the gateway drug. Putting yet
another conditional on top of the pile works fine in most cases, until
someone suddenly screw up, I get a phonecall at 3 am, and have to
figure out that piece of code with a plant manager screaming on the
phone telling me just how much overtime he have to pay.
If the same code goes into both branches, then someone is doing a
very bad job. I'm talking about the conditions before that.
I know. Yet, I do not have the privilege of working in an
environment, where that is practiced at all times. Normally, the
combination of eager project manager, customers with an urgent need
for some change to the buisness logic, and a nearby deadline combines
to sloppy code. Again, if that is a fact you have not had to live
with, I envy you.
Actually, the typo was here: moon_phase = M_WAXING
I had to change the names to protect the guilty parties. I tried to
convey the general spirit of them, though.
In this case, the whole mess was refactored away because of changes
made outside this bit. If that hadn't been the case, I'd at least have
put the conditionals into an if statement, leading to the
assignment. In my opinion the readability of a multi-line perlish
construction (assignment - condition) is nil. So the least effort
would be to change the order, so the flow looked like (condition -
assignment)
In this case I would, had it been the only change needed.
A
Anders Wegge Keller
Keith Thompson said:
The pattern is the same. Written by someone, who 17 years ago was
fresh out of school, knowing that a = (b == c) would remove the need
for if.
That is still the first step into the shady world.
I've been mentioning all the time that my objection is to the general
*pattern*, not the particular case.
You would have skipped the i entirely (or removed it later on), as it
isn't used for anything beyond this point, in the current version of
the code.
Right up until the point where it isn't safe anymore. In that
respect, it's like being a "little bit" pregnant.
Depending on code flow, the 0 assigment could be placed at another
point. But you may recall that I actually listed an else in my
preferred way.
A
Anders Wegge Keller
Ben Bacarisse said:
In this context I fail to see why this is different from you saing
it's safe and beautifull.
Becuse I do not have the possibility of exhaustive testing. I don't
even have unit tests. What I have is a simulation of the machines our
software controls, and that's it. In this case, input hardly ever was
34, meaning that this lived for a long time.
We are talking about two entirely different things here. I'm dead set
against the pattern of making conditional statements, be it
assignments or other statements, without a clearly visible if () { }
[else { }] construct. If I wanted to write perl, I'd do it in that
language.