Re: Paying developers to get features faster
From: james (fishbowl_at_conservatory.com)
Date: 01/26/04
- Next message: james: "Re: Paying developers to get features faster"
- Previous message: Christopher Browne: "Re: Tax Software (US) for Linux ?"
- In reply to: P.T. Breuer: "Re: Paying developers to get features faster"
- Next in thread: P.T. Breuer: "Re: Paying developers to get features faster"
- Reply: P.T. Breuer: "Re: Paying developers to get features faster"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 26 Jan 2004 04:36:29 GMT
In article <js91vb.3u5.ln@news.it.uc3m.es>,
P.T. Breuer <ptb@oboe.it.uc3m.es> wrote:
>And mine with yours. When you mean to use a boolean, use it like a
>boolean:
>
> if (has_escaped_from_zoo)
>
>not
>
> if (has_escaped_from_zoo != 0)
But I do totally agree with that. Even if your language doesn't
explicitly support a bool type, if you have a value that's going to be
treated as a bool, you should stick to it. It shouldn't be an int
in one line, and then magically become a bool when it happens to be
convenient to compare it to zero.
>> I find if(NULL == var) to not only be easier to read, but I also regard
>
>You should probably never read it. It means that you are using a
>pointer instead of a boolean.
That's a very good point, but I do know the difference between the
pointer comparison and the boolean result of the pointer comparison.
>However, if you really meant to test the condition that the pointer is
>null, which is an error condition, then you would indeed write
>
> if (var == NULL)
The origin of this argument is based on the fact that it is possible to
write ( var = NULL ) and spend too long tracking it down. Writing it
as (NULL = var) should cause a compile-time error, and should certainly
be easier to find. The words "proper tools" came up. I started
learning this trade in the 1970s so these habits are pretty deep-seated.
>(though I'd probably always write !var since I would always use a
>pointer also in the sense of the predicate
Well, if the language is guaranteed to evaluate the NULL pointer as 0,
that's fine. Certain very popular languages do not allow you dto do
that.
>> it as a sign of experience and professionalism when I see it in code.
>> My peers agree.
>
>But they are wrong. Probably because they are poor logicians.
It's a matter of opinion. There is no "right" and "wrong", and while I
may not be a mental giant myself, I resent that you have just called my
peers "poor logicians." You don't even know who you are insulting!
- Next message: james: "Re: Paying developers to get features faster"
- Previous message: Christopher Browne: "Re: Tax Software (US) for Linux ?"
- In reply to: P.T. Breuer: "Re: Paying developers to get features faster"
- Next in thread: P.T. Breuer: "Re: Paying developers to get features faster"
- Reply: P.T. Breuer: "Re: Paying developers to get features faster"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
