reversing the comparison
in [Visual Basic]
|
Prev: Displaying property menu at runtime
Next: Delay Methods
From: Paul Clement on 21 Jul 2010 13:03 On Wed, 21 Jul 2010 09:48:04 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: � Paul Clement presented the following explanation : � > On Tue, 20 Jul 2010 12:01:57 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: � > � > � > � > It's still backwards with respect to readability. ;-) � > � > � � > � > � Only if your screen is infinitely wide, or you just call functions with � > � > � very short parameter lists. � > � > � > � > Or you use line continuation characters. ;-) � > � � > � Generally, no. They make E&C a bit more troublesome. HTH! � > � > Works fine for me. :-) � � You're using a different language, so that's totally irrelevant. That's what I was trying to tell you. ;-) Paul ~~~~ Microsoft MVP (Visual Basic)
From: DanS on 21 Jul 2010 17:30 Tom Shelton <tom_shelton(a)comcast.invalid> wrote in news:i24hof$rd4$1(a)news.eternal-september.org: > DanS formulated on Tuesday : >>>> � Why put FALSE == instead of the function first, like >>>> we usually do? >>>> >>>> Looks like the Yoda School of Programming to me. Coded >>>> properly, the comparison to FALSE isn't even necessary. >>>> >>> >>> It's C++ code.... Older C++ didn't define a bool type >>> or have any concept of a boolean value. That mades these >>> types of comparisons necessary, and the reverse test was >>> to prevent the old bug of accidently doing an assignment >>> in the test. >> LoopHere: >> Since when is a programmer's own deficiency a bug ? >> > > A bug is any incorrect behavior in the program - which in > this old case maybe the result of a typo or as you say, > programmer deficiency. What does this actualy have to do > with my response? Why would you ask that ? Your response to the question was...... "Older C++ didn't define a bool type or have any concept of a boolean value. That mades these types of comparisons necessary, and the reverse test was to prevent the old bug of accidently doing an assignment in the test." Goto LoopHere;
From: Karl E. Peterson on 21 Jul 2010 18:17 Paul Clement explained on 7/21/2010 : > On Wed, 21 Jul 2010 09:48:04 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: > > � Paul Clement presented the following explanation : > � > On Tue, 20 Jul 2010 12:01:57 -0700, Karl E. Peterson <karl(a)exmvps.org> > wrote: � > > � > � > � > It's still backwards with respect to readability. ;-) > � > � > � > � > � > � Only if your screen is infinitely wide, or you just call functions > with � > � > � very short parameter lists. > � > � > > � > � > Or you use line continuation characters. ;-) > � > � > � > � Generally, no. They make E&C a bit more troublesome. HTH! > � > > � > Works fine for me. :-) > � > � You're using a different language, so that's totally irrelevant. > > That's what I was trying to tell you. ;-) No need! I've known you're totally irrelevent for years! :-) But thanks for sharing that with the group, I guess. <shrug> -- ..NET: It's About Trust! http://vfred.mvps.org
From: dpb on 21 Jul 2010 18:44 DanS wrote: > Tom Shelton <tom_shelton(a)comcast.invalid> wrote in > news:i24hof$rd4$1(a)news.eternal-september.org: > >> DanS formulated on Tuesday : >>>>> � Why put FALSE == instead of the function first, like >>>>> we usually do? >>>>> >>>>> Looks like the Yoda School of Programming to me. Coded >>>>> properly, the comparison to FALSE isn't even necessary. >>>>> >>>> It's C++ code.... Older C++ didn't define a bool type >>>> or have any concept of a boolean value. That mades these >>>> types of comparisons necessary, and the reverse test was >>>> to prevent the old bug of accidently doing an assignment >>>> in the test. > > LoopHere: > >>> Since when is a programmer's own deficiency a bug ? >>> >> A bug is any incorrect behavior in the program - which in >> this old case maybe the result of a typo or as you say, >> programmer deficiency. What does this actualy have to do >> with my response? > > Why would you ask that ? > > Your response to the question was...... > > "Older C++ didn't define a bool type or have any concept of a > boolean value. That mades these types of comparisons > necessary, and the reverse test was to prevent the old bug of > accidently doing an assignment in the test." > > Goto LoopHere; 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"? --
From: Bob Butler on 21 Jul 2010 20:01
"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. |