[Opengl3dwm-devel] Re: GL 3D FM
Status: Pre-Alpha
Brought to you by:
zarnick
|
From: <bul...@gm...> - 2006-03-30 22:50:39
|
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:) Use bottom posting, top posting sucks!:) |