Hi,
I've read (in "joel on software") that, to avoid confusion between == and =,
when you sometimes use languages that use = as assignments AND comparisons,
you can do some comparisons like this :

  0 == myvalue

instead of

  myvalue == 0

the former causes an error if you put = instead of ==, which avoids potential
headaches later.

While it could seem very ordinary to hardcore programmers here, to me it's
very smart, and I would like to know if there's some place where I could
learn other little tricks like this...

any links ?

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>   0 == myvalue

> instead of

>   myvalue == 0

  I have always disliked that "trick" because it breaks the logical way
to "read" the line. Nobody says "if zero is equal to this value". The
common expression is "if this value is equal to zero".

  I have seen some people go further and extend that "trick" to things
like:

    0 < money

  This always confuses me. Again, nobody says "if zero is smaller than
the amount of money". That sentence would be quite confusing. Naturally
everyone says "if the amount of money is larger than zero".

-- 
                                                          - Warp

Post a reply to this message

"Fa3ien" <fab### [at] yourshoesskynetbe> wrote

> I've read (in "joel on software") that, to avoid confusion between == and
=,
> when you sometimes use languages that use = as assignments AND
comparisons,
> you can do some comparisons like this :
>
>   0 == myvalue

I think the best "trick" is to use a programming language which was designed
with at least some forethought, so that such tricks are unnecessary.

Post a reply to this message

somebody <x### [at] ycom> wrote:
> I think the best "trick" is to use a programming language which was designed
> with at least some forethought, so that such tricks are unnecessary.

  Such languages may lack necessary libraries, support or efficiency.

-- 
                                                          - Warp

Post a reply to this message

>> I think the best "trick" is to use a programming language which was designed
>> with at least some forethought, so that such tricks are unnecessary.
> 
>   Such languages may lack necessary libraries, support or efficiency.

And that's the sad part. C is a horrid, horrid language, but it's where 
all the libraries are. All the "good" languages I've seen have a 
crippling lack of half-decent libraries... [And usually, rather limited 
documentation and unpolished toolchains.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Such languages may lack necessary libraries, support or efficiency.

  Btw, often people wonder why C++ is so popular, given that there are
so many "better" languages out there.

  IMO one very important factor for the popularity of C++ is the staggering
amount of libraries for it. Since almost all C libraries can be used in C++,
the amount of available libraries is simply enormous.

  This is, IMO, often one of the major killers for new languages: Lack of
libraries. The language may be the most perfect language in the world, but
if you don't have libraries to do what you want, it's almost useless.
Nobody wants to reinvent the wheel for every little thing that has been
already implemented to death by other people.

-- 
                                                          - Warp

Post a reply to this message

>   I have always disliked that "trick" because it breaks the logical way
> to "read" the line. Nobody says "if zero is equal to this value". The
> common expression is "if this value is equal to zero".

I mostly agree.  When I seen that trick, I also thought that it was not
very "natural", being the reverse of "this equals that".

However, there are many areas were programming require some kind
of backwards-thinking or even worse, so that's quite benign.

All in all, I don't recommend the trick or even think I'm gonna
use it myself, it was mostly an example of a small trick that
implies a little thinking, and I was wondering if there were any
other small programming tricks of that kind.

Fabien.

Post a reply to this message

somebody wrote:
> I think the best "trick" is to use a programming language which was designed
> with at least some forethought, so that such tricks are unnecessary.

Heh.

To answer the original question, check out the book "programming pearls".

I do the (0 == X) and it seems quite natural after a time. (And I 
occasionally get asked why I do such things in languages where 
assignment and equality don't get mixed up, like Tcl. :-)

I also do the "never use the > sign" in comparisons. It's not a question 
of how you read it out loud, but a question of putting the things in the 
right order. For example:

   0 < A & A < B
If A is between zero and B.

   A < B | C < A
If A is outside the range B to C.

   if (start + 300 < now)
If now is at least 300 seconds past when we started.

Start putting in complicated timestamp calculations, and it becomes very 
helpful. Always use < or <=, always add rather than subtract offsets, 
and I almost never make a mistake and get the wrong things being compared.

It's kind of like drawing a picture, rather than writing a sentence. 
IME, most programmers are more visual than auditory.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Invisible wrote:
> And that's the sad part. C is a horrid, horrid language, but it's where 
> all the libraries are. All the "good" languages I've seen have a 
> crippling lack of half-decent libraries...

That's why I'm looking at Erlang. Decent language, good efficiency, 
industrial-strength libraries.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> And that's the sad part. C is a horrid, horrid language, but it's 
>> where all the libraries are. All the "good" languages I've seen have a 
>> crippling lack of half-decent libraries...
> 
> That's why I'm looking at Erlang. Decent language, good efficiency, 
> industrial-strength libraries.

I did look at Erlang. (Let's face it, other than Lisp, it's the only 
remotely "popular" functional language. And Erikson is behind it, so 
that's a pretty damn big vote of confidence in the soundness of the 
technology.)

But alas, it's not purely functional, and the general style just seemed 
untidy and complicated. It's just not my cup of tea...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message