reversing the comparison
in [Visual Basic]
|
Prev: Displaying property menu at runtime
Next: Delay Methods
From: ralph on 21 Jul 2010 20:15 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 21 Jul 2010 20:57 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 21 Jul 2010 21:07 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 21 Jul 2010 21:58 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 21 Jul 2010 23:29
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 |