[Opengl3dwm-devel] Re: GL 3D FM

[<bul...@gm...>]

On Friday 31 March 2006 00:19, you wrote:
> Okay whatever you  guys decide.
>
> On 3/30/06, bul...@gm... <bul...@gm...> wrote:
> > On Thursday 30 March 2006 07:39, Alon Dakik wrote:
> > > hey guys,
> > >
> > > are we going to have a DEBUG switch in our code if we want to turn on
> > > debugging?
> > >
> > > we also have to talk about TRUE/FALSE. For me true is something greater
> > > than 0
> > > cuz 0 == NULL,  but in your code zarnick you have SUCCESS ==  0  and
> > > FAILURE == 1
> > > which are both wrong to me just TOO WRONG!
> > >
> > > I think hehe but maybe you can prove me your way is better.
> > >
> > > Everything in computer science uses  true >= 1 and false <= 0
> > >
> > > Machines, compilers, automata, logic, hardware, electricity  all have 1
> >
> > ==
> >
> > > TRUE and 0 == FALSE. So we need to talk and decide how we should use
> >
> > return
> >
> > > values in our code.
> >
> > Zarnick is sort of right on this issue, a successfull return code is
> > custom to
> > be marked as 0. That's why I don't use/like TRUE-FALSE. And as you
> > stated, Alon, the errors are <0 and the different types of success
> > results are >= 0.
> >
> > So I suggest we use this scheme.
> >
> > As far as DEBUG switch that's a sane solution. And I'm all for it.
> >
> > Another issue we should discuss is coding practice. I suggest the
> > following
> > rules:
> >
> > 1) At least on every 10 lines of code one comment must be found. This
> > will make for new devels and people how look at our code for bugs a much
> > easier job.
> >
> > 2) We all use the same indention, code alingement, naming scheme etc.
> > This will not only make the code more readable but will also easily
> > outline possible bugs or optimizations.
> >
> > 3) We try to keep everything magic numbers free, and as modular and
> > simple as
> > possible. Divide et impera!:) Whenever we have some problems with that we
> > mail each other and ask, better postpone a cool feature with magic
> > numbers/
> > memory leaks/ poor design in it then go back later and try to figure out
> > what
> > we did back there.
> >
> > We should keep mail coming, so we can have it for reference to our selfs
> > and
> > others that will be interested at later times, if they will come:)

Top posting sucks!:)