Re: Collider and Mover code

[David Philippi]

On Friday 17 January 2003 03:24, Gervase Lam wrote:
> I was brought up with the one return only principle in functions.  That's
> why there is only one return in the method.  A break could have been used
> in the loop instead.  But since there is a way to avoid this as well, I
> avoided it!

Ah yes, one of those... I didn't need to take more than a glance at the link 
you provided - it's from a C group but Pingus is C++ which is a whole lot 
more different then most people seem to know.

> One return CAN help if awkward clear up code is required.  For example, if
> the routine has many new statements which IDEALLY should only have one
> delete statement.  One return point can help in this case.

In C++ you'd declare pointers which are to be deleted later in the method as 
auto_ptr<> and don't worry about them anymore. One return point doesn't 
protect you against exceptions anyway. In C++ you can avoid most problems 
with multiple return points by using classes which are responsible for 
cleaning up in their destructor if they aren't told that everything went 
well. This doesn't protect against unclear code from multiple returns but 
unclear code may be achieved by so many ways...
Another often stated argument is that multiple return statements prevent 
optimizations by the compiler - that's an old one. They make things more 
complex but GCC 3.x does optimize them if all return the same variable (and 
in case of bool there isn't much to optimize anyway).

In a method as short as this there's no chance for a second return to cloud 
things up and no way that any additional possible optimization will win 
against the cost of running through the loop multiple times doing needless 
checks.

> Though one return is good, sometimes it can cause unclear code.  For
> example if there is a series of if statements that checks for errors.  On
> an error being found, the routine must not run the rest of the code (i.e.
> return immediately).  Though a flag could be used, it makes things less
> straightforward.

There you see something which leads to "The One Rule of programming to rule 
them all": THERE ARE NO DESIGN RULES! Every time you'll hear someone tell you 
about a design rule - correct him/her aloud or in your mind: it's a design 
GUIDELINE, never a rule. There's no design rule without (most likely 
multiple) exceptions in the world of programming. Always use them as the 
default way to do something but keep your mind alert to prevent beeing a 
slave to rules. It's even worse if you're people talk about OO principles 
those are most often fanatics.
I guess you know that goto is very bad? It's not. I've used it only once in my 
code so far and everyone looking at the code told me that it's bad when they 
saw the goto. Then I asked them to take a look at the whole method and tell 
me how they would solve the problem. Everyone had to admit that there was no 
bettersolution then using goto and that it didn't harm the code at all. It's 
just a command that you shouldn't tell new programmers about since it's very 
easy to misuse it, in the hands of an expert it's a valuable tool.

BTW I tend to get a bit aroused whenever I hear someone speak about design 
"rules" unless the audience are new programmers who don't need to know about 
the alternatives yet. When you wrote that you didn't even use break to cancel 
the loop when it's finished, a battery of red lights in my head went on. ;-)
If you insist on following the one return rule, a break most definitly should 
go in there. This will very likely generate the same output as the variant 
using two returns and no bool after a good optimizer went over the code.

> With regards to the Mover and Collider directory structure.  Keeping to
> the current directory convention, mover.hxx could be put in
> Games/Pingus/src with linear_mover.hxx being put into a new directory
> called Games/Pingus/src/movers.

Yes, that would be a way.  What about putting linear mover in a namespace 
Movers? Reminds me of putting the Particle classes in a namespace...

> In a similar way, upright_pingu_collider.cxx and
> upright_pingu_collider.hxx could be put into Games/Pingus/src/colliders.

Along with a namespace Colliders...

> In any case, I think pingu_collider needs to be changed to just collider.
> This is because the abstract class pingu_collider should apply to any
> object, not just Pingus.

What other objects do you think should collide with each other? Defining the 
scope of the class is required to answer your next questions.

> But does this mean that collider should not have a getpixel() method?
> Does getpixel() apply to all other objects?  Should the class hierarchy be
> collider<-pingu_collider<-upright_pingu_collider or
> collider<-upright_pingu_collider?

Bye David