Thread: [Opengl3dwm-devel] TRUE/FALSE and stuff...
Status: Pre-Alpha
Brought to you by:
zarnick
Menu
▾
▴
opengl3dwm-devel
|
From: Zarnick M. <p.z...@gm...> - 2006-03-31 02:48:22
|
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 >=3D 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. ---------------------------------------------------------------------------= ----- 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. -- -=3D=3DZarnick=3D=3D- |
|
From: <bul...@gm...> - 2006-04-01 18:07:31
|
On Friday 31 March 2006 04:01, Zarnick Maelstorm wrote: > 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 > Ok. So that subject is closed. > --------------------------------------------------------------------------- >----- 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. > Yes, but we'll have to give away release builds too, and the end-user will not want a debug bloated binary. This is again a glance in the future:) > --------------------------------------------------------------------------- >----- 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 Ok. I'm glad you find it good:) > --------------------------------------------------------------------------- >----- 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 Ok then, we have to set some standard now. Here's a wikipedia link: http://en.wikipedia.org/wiki/Indent_style I use BSD-style, check it out in the link above. There are other types. we should decide on a single indention style and move on:) We also should settle on variable naming convention. I suggest we follow hungarian notation, in it's real sense, not the missunderstood MS one, where it only means prefixing with default language types. Some links: http://www.joelonsoftware.com/articles/Wrong.html > --------------------------------------------------------------------------- >----- 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. Yeah, that's correct. If something cryptic must be used, we should comment it well so that a smarter person will be able to make it better at a later time:) > --------------------------------------------------------------------------- >----- 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. > -- Yeah. > -==Zarnick==- > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Opengl3dwm-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengl3dwm-devel |
|
From: Zarnick M. <p.z...@gm...> - 2006-04-02 14:51:05
|
Ok, so I've been reading on the literature bulibuta told us to read, and I do sugest we keep using the K&R ident style, plus I'm OK with Hungarian variables, we just have to make it correct, and we all must agree upon the notation, anyone has some ideias? Zarnick On 4/1/06, bul...@gm... <bul...@gm...> wrote: > On Friday 31 March 2006 04:01, Zarnick Maelstorm wrote: > > 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 includ= e > > to include all the defines and includes needed by the files, this way w= e > > 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 stat= ed, > > Alon, the errors are <0 and the different types of success results are = >=3D > > 0. > > > > So I suggest we use this scheme. > > -----------------------------------------------------------------------= ---- > >----- Ok, already done that and I happily agree with that > > > > Ok. So that subject is closed. > > > -----------------------------------------------------------------------= ---- > >----- 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 wi= th > > -ggdb -g3 options, but I think a DEBUG switch is a good way, just > > elaborate a little more what you are thinking. > > > > Yes, but we'll have to give away release builds too, and the end-user wil= l not > want a debug bloated binary. This is again a glance in the future:) > > > > -----------------------------------------------------------------------= ---- > >----- 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 w= ill > > make for new devels and people how look at our code for bugs a much eas= ier > > job. > > -----------------------------------------------------------------------= ---- > >----- Ok for me > > Ok. I'm glad you find it good:) > > > -----------------------------------------------------------------------= ---- > >----- 2) We all use the same indention, code alingement, naming scheme e= tc. > > This will not only make the code more readable but will also easily out= line > > possible bugs or optimizations. > > -----------------------------------------------------------------------= ---- > >----- Also ok for me > > Ok then, we have to set some standard now. Here's a wikipedia link: > http://en.wikipedia.org/wiki/Indent_style > > I use BSD-style, check it out in the link above. There are other types. w= e > should decide on a single indention style and move on:) > > > We also should settle on variable naming convention. I suggest we follow > hungarian notation, in it's real sense, not the missunderstood MS one, wh= ere > it only means prefixing with default language types. Some links: > > http://www.joelonsoftware.com/articles/Wrong.html > > > > -----------------------------------------------------------------------= ---- > >----- 3) We try to keep everything magic numbers free, and as modular an= d > > 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 numb= ers/ > > memory leaks/ poor design in it then go back later and try to figure ou= t > > 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. > > Yeah, that's correct. If something cryptic must be used, we should commen= t it > well so that a smarter person will be able to make it better at a later > time:) > > > -----------------------------------------------------------------------= ---- > >----- 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. > > -- > > Yeah. > > > -=3D=3DZarnick=3D=3D- > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > > that extends applications into web and mobile media. Attend the live > > webcast and join the prime developer group breaking into this new codin= g > > territory! > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=12164= 2 > > _______________________________________________ > > Opengl3dwm-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opengl3dwm-devel > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Opengl3dwm-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengl3dwm-devel > -- -=3D=3DZarnick=3D=3D- |
Thanks for helping keep SourceForge clean.
X