Re: [Opengl3dwm-devel] TRUE/FALSE and stuff...

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

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-