[Lightbringer-devel] Developer Guidelines

[Team D. <tea...@gm...>]

On 8/30/05, Pascal Kirchdorfer <kir...@us...> wrote:
> > 1. Coding Style
> > coding styles
> If we're going to use CS and CEL we might as well take their code style?
> That would be:
> - 2 space indent,
> - 1 tab =3D 8 space,
> - no line longer 78 characters (tab=3D8),
> - CamelCase function names,
> - Class names go csClass (or in our case bolClass),
> - Interfaces go iInterface
>
> Just a suggestion, love it or hate it :)

Ok, let's see what everyone has to say, then we can decide which to use.

> > 2. Updating
> you mean commiting?
> cvs update is something else, just to avoid confusion.

Sorry if this wasn't clear, but i meant to encompass all the aspects
of Modifing the project (creating, deleting,updating).

> > ii. A Changes File could be created that will contain information
> > about contributions.Here is the suggested format of this file.
>
> What about this format?
> http://cvs.sourceforge.net/viewcvs.py/crystal/crystalcore/docs/history.tx=
t?view=3Dmarkup

This is a great format, i know some of my suggestions might be
tedious, they're a side affect of the fact that i normally code by
myself and i've been focusing on web designing for the past year :).

> 3. Documentation
> > To help us down the road in maintenance, certain information must be
> > contained in the source files.Every file must contain a section that
> > deal with the files purpose,functions contained and any relavent notes.
>
> I suggest doxygen style comments.
>
> >Also before every function a section must be created that ...
>
> doxygen comment should do fine here too
>
> Using doxygen allows us go generate nice and easy to read websites or eve=
n
> pdf files (via LaTeX).
>
> I also recommend the use of \todo, \depreciated, \bug and \test which all=
ows
> the
> generation of todo lists, bug lists, etc.

I had originally included doxygen in my first guidelines but i
misplaced the file (seriously!) and when i  had to rewrite it i didn't
include it with the rest because of time( it was long overdue ) and
forgetfullness on my part.

> > 4. Tools
> > A development platform thread will be created to facilitate
> I don't know exactly what you mean, but I just disagree :-)
> CS provied a great buildsystem that works on windows and linux just great
> and allows also platform independant code. This is possible thanks to CS'=
s
> virtual filesystem, thread wrappers and many more.
>
> That means, with the CS jamtemplate you can generate MSVC project
> files from the command line, maybe even by a cronjob?

A side-effect of my haste as stated above :). But my thoughts on this
were centered on compilers,libraries and misc. tools that we might use
to compile the sources now or in the future, just so we could have
everything documented.

> Furthermore, projects using that buildsystem are known to work on
> Windows using MSVC, mingw(gnu for windows) as well as Linux using
> GCC/Jam and MacOsX using.... whatever, I don't use macosx, but it work :)
>
> Well, those are my 2 cents...
>
> - PK
 Thanks for the feedback :).