pingus-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Collider and Mover code


From: Gervase Lam
Subject: Re: Collider and Mover code
Date: Fri, 17 Jan 2003 02:24:49 +0000

> Date: Mon, 13 Jan 2003 22:07:27 +0100
> From: David Philippi <address@hidden>
> Subject: Re: Collider and Mover code

> The code looks very well to me from the C++ view. I've not yet tried
> to=20 understand what it really does and how it interacts with the rest
> of the=20 Pingus code. I'm too tired right now to do this. A few things
> I noticed w= hile=20
> taking a first look:
> - The implementation of upright_pingu_collider::operator() could return
> t= rue=20
> in the for loop if the condition is met and false otherwise at the end
> of= the=20
> method.

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!

I eventually found a clear explanation of why one return is good.

<http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=2f5hq8%24bp%40bb29c.mdd.comm.mot.com&rnum=1&prev=/groups%3Fq%3D%2B%2522can%2Bbe%2Bjust%2Bas%2Bclearly%2Bwritten%2Bwith%2Bone%2Breturn%2522%2Bgroup:comp.lang.c*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D2f5hq8%2524bp%2540bb29c.mdd.comm.mot.com%26rnum%3D1>

I thought I noticed an error in the code fragment.  Indeed, the code 
fragment was corrected later in the newsgroup thread!

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.

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.

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.

In a similar way, upright_pingu_collider.cxx and 
upright_pingu_collider.hxx could be put into Games/Pingus/src/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.

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?

Thanks,
Gervase.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]