Mike Raiford <mra### [at] hotmailcom> wrote:
> Where that really comes into play is range statements:

> if(10 < money && money < 100)
> {
>   ...
> }

> which can be read as "if money is between 10 and 100"

> Someone I used to work with insisted that you use the same direction in 
> comparisons if you had more than 1 comparison. It seemed to make sense 
> when he used this example. The equivalent (and probably the way most 
> people are familiar with handling ranges) "money > 10 && money < 100" 
> isn't as quick to parse what you're looking for. Using that sort of 
> statement with a single comparison seems a bit ridiculous to me, though.

  I don't have any problem in quickly understanding "money > 10 && money < 100"
because I use it so much.

  (OTOH, one could argue that understanding "0 < money" becomes easy when
you use it a lot...)

  The form you suggest becomes a bit counter-productive when the expression
is not a pure "between x and y", like for example:

if(10 < money*money && money*12 < 100)

  Now it becomes much harder to understand quickly what's going on.

> I have seen and used the [Constant|Literal] == [Variable] syntax before, 
> it's good for preventing assignment where you meant equality bugs. Of 
> course, the problem becomes obvious when you begin debugging seemingly 
> bizarre behavior. But, the objective is to prevent such behavior in the 
> first place.

  In most cases the compiler will issue a warning anyways if you make
the mistake. Never been a problem to me.

> My favorite syntactical bug was the following:

> for(int i = 0; i < cItems; i++);
> {
>     ... Block of code ...
> }

> It's subtle, and if your for loops are any more complex than the above 
> trivial example, results in headaches. I spent an hour tracking 
> something similar down in my early days.

  If the loop of the body uses 'i' (as is rather usual) you'll get a
compiler error.

-- 
                                                          - Warp

Post a reply to this message