[Opengl3dwm-devel] TRUE/FALSE and stuff

[Zarnick <p.z...@gm...>]

Ok, so the true/false sucess/failure pair is right seted now, plus I've  
made some modification on the FMSystem module, I've made one big include  
to include all the defines and includes needed by the files, this way we  
don't have to change everything in all files. ;)

Also, I'm copying the e-mail of bulibuta, with coments:

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Ok, already done that ;) and I happily agree with that

--------------------------------------------------------------------------------
As far as DEBUG switch that's a sane solution. And I'm all for it.
--------------------------------------------------------------------------------

Well, if you thinkg, we already are debuggin, since we are compiling with  
-ggdb -g3 options, but I think a DEBUG switch is a good way, just  
elaborate a little more what you are thinking. :D

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Ok for me
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Also ok for me
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Also ok for me, just with one resalve...we should put a comment on the  
piece that has the magic number/mem leak/seg.fault/etc. saying that it has  
this, why it has this(or what were you thinking when you make this way and  
it has this), the date, revision number you were working(if possible), and  
if you have any ideia for correcting it.
--------------------------------------------------------------------------------
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:)
--------------------------------------------------------------------------------
Ok by me, and already using it, this way we can also keep logs of our  
ideias.
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/