From: ralph on
On Wed, 21 Jul 2010 17:44:29 -0500, dpb <none(a)non.net> wrote:


>
>I'm w/ Tom in some surprise of even commenting on the use of "bug" for
>the problem of a typo causing incorrect behavior in code (in this case
>one instead of two "=" signs). Would you not consider a misspelling of
>a variable name or the inadvertent use of the wrong variable or any
>number of other (more or less) mechanical mistakes bugs? How would you
>define a bug vis a vis a "programmer deficiency"?

I'm just surprised that such an innocuous question generated so much
chaff.

You (dps) hit it dead on with the first reply.
It is simply a coding convention that dates back to K&R to help catch
a particular coding error - typing "=" (an assignment), instead of
"==" (equality) - type the constant/literal first and get an compile
error if you attempt to assign rather than compare. Period.

(Certainly doesn't have a d*mn thing to do with boolean returns etc.
In the example give the constant just happens to be "FALSE", but it
could have as easily been "EOL", "SUCCESS", "BIG_BAD_ERROR_FLAG",
"WOOT_WOOT", or anything else. The rule/tip/practice would still
apply.)

Personally, I never worried about following it faithfully (just
habit). I mean it is a decent idea, and there is certainly no harm in
it, but it's not that big of a deal*.

1) If you are writing a conditional and you recognize you are using a
constant/literal then the same mental alarm that says - "Hey, better
type that constant first", pretty much goes on to say - "Hey, better
make sure you are typing the equally operator".
2) It only works with constants or literals. You can still mess up if
comparing variables.
3) I usually use a lint utility, and lint as well as most modern
compiler's static checking will issue a warning if you use an
assignment operator in a conditional statement.
(I'm a firm believer in setting /W4 and compiling with no warnings.
<g>)

[* However you will always find shops that will consider it a cardinal
sin if you don't do it. Also for some reason it always seems to show
up on C/C++ tests and as a potential interview question.]
From: Tom Shelton on
Bob Butler used his keyboard to write :
> "dpb" <none(a)non.net> wrote in message
> news:i27te9$ul$1(a)news.eternal-september.org...
> <cut>
>> I'm w/ Tom in some surprise of even commenting on the use of "bug" for the
>> problem of a typo causing incorrect behavior in code (in this case one
>> instead of two "=" signs). Would you not consider a misspelling of a
>> variable name or the inadvertent use of the wrong variable or any number of
>> other (more or less) mechanical mistakes bugs? How would you define a bug
>> vis a vis a "programmer deficiency"?
>
> It causes a bug in the application; it's not a bug in the language per se.

No one said it was a bug in the language...

--
Tom Shelton


From: Tom Shelton on
ralph wrote on 7/21/2010 :
> On Wed, 21 Jul 2010 17:44:29 -0500, dpb <none(a)non.net> wrote:
>
>
>>
>> I'm w/ Tom in some surprise of even commenting on the use of "bug" for
>> the problem of a typo causing incorrect behavior in code (in this case
>> one instead of two "=" signs). Would you not consider a misspelling of
>> a variable name or the inadvertent use of the wrong variable or any
>> number of other (more or less) mechanical mistakes bugs? How would you
>> define a bug vis a vis a "programmer deficiency"?
>
> I'm just surprised that such an innocuous question generated so much
> chaff.
>
> You (dps) hit it dead on with the first reply.
> It is simply a coding convention that dates back to K&R to help catch
> a particular coding error - typing "=" (an assignment), instead of
> "==" (equality) - type the constant/literal first and get an compile
> error if you attempt to assign rather than compare. Period.
>
> (Certainly doesn't have a d*mn thing to do with boolean returns etc.

The only reason boolean returns came into it is because most modern
languages force conditionals (if, while, etc) to only accept a
statement that evaluates to a boolean - so the old constant == varialbe
convention isn't a requirement.... You get a compiler error in either
direction.

In other words, they treat boolean as more then just 0 or non-zero...

> In the example give the constant just happens to be "FALSE", but it
> could have as easily been "EOL", "SUCCESS", "BIG_BAD_ERROR_FLAG",
> "WOOT_WOOT", or anything else. The rule/tip/practice would still
> apply.)
>
> Personally, I never worried about following it faithfully (just
> habit).
> I mean it is a decent idea, and there is certainly no harm in
> it, but it's not that big of a deal*.
>
> 1) If you are writing a conditional and you recognize you are using a
> constant/literal then the same mental alarm that says - "Hey, better
> type that constant first", pretty much goes on to say - "Hey, better
> make sure you are typing the equally operator".
> 2) It only works with constants or literals. You can still mess up if
> comparing variables.
> 3) I usually use a lint utility, and lint as well as most modern
> compiler's static checking will issue a warning if you use an
> assignment operator in a conditional statement.
> (I'm a firm believer in setting /W4 and compiling with no warnings.
> <g>)
>
> [* However you will always find shops that will consider it a cardinal
> sin if you don't do it. Also for some reason it always seems to show
> up on C/C++ tests and as a potential interview question.]

Coding standards are a good thing... I didn't really believe in tight
standards, until recently we farmed out some of our stuff to an india
team.... Our standards are getting much tighter now.

--
Tom Shelton


From: ralph on
On Wed, 21 Jul 2010 19:07:31 -0600, Tom Shelton
<tom_shelton(a)comcast.invalid> wrote:


>
>The only reason boolean returns came into it is because most modern
>languages force conditionals (if, while, etc) to only accept a
>statement that evaluates to a boolean - so the old constant == varialbe
>convention isn't a requirement.... You get a compiler error in either
>direction.
>

But the question had nothing to do with *other languages* it was a
C/C++ example, and placing a Constant first has always been a nice
habit to get into when doing comparisons, period.

In the example the other operand was a function, so an error was
likely in either case, but likely had nothing to do with the
programmer employing the convention.

And where did you get the idea you CAN NOT do an assignment in a
conditional statement????

-ralph


From: Tom Shelton on
on 7/21/2010, ralph supposed :
> On Wed, 21 Jul 2010 19:07:31 -0600, Tom Shelton
> <tom_shelton(a)comcast.invalid> wrote:
>
>
>>
>> The only reason boolean returns came into it is because most modern
>> languages force conditionals (if, while, etc) to only accept a
>> statement that evaluates to a boolean - so the old constant == varialbe
>> convention isn't a requirement.... You get a compiler error in either
>> direction.
>>
>
> But the question had nothing to do with *other languages* it was a
> C/C++ example, and placing a Constant first has always been a nice
> habit to get into when doing comparisons, period.
>

To prevent an ACCIDENTAL assignment. I understand that. And that is
the basic answer...

> In the example the other operand was a function, so an error was
> likely in either case, but likely had nothing to do with the
> programmer employing the convention.
>
> And where did you get the idea you CAN NOT do an assignment in a
> conditional statement????
>

I didn't say you can't... I didn't even say you would want to. It is
just a common old C/C++ bug to ACCIDENTLY do an assignment. The
convention of constant first was simply to avoid that mistake.

You can even do an assignent in C# and Java - it's jsut the result of
your expresion must be a boolean.

string line;
while ((line = reader.ReadLine()) != null)
{
}



--
Tom Shelton


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Prev: Displaying property menu at runtime
Next: Delay Methods