Re: [Lightbringer-devel] Developer Guidelines

[Pascal K. <kir...@us...>]

> 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 = 8 space,
- no line longer 78 characters (tab=8),
- CamelCase function names,
- Class names go csClass (or in our case bolClass),
- Interfaces go iInterface

Just a suggestion, love it or hate it :)

> the different CR/LF characters that they use.
CVS should handle that, wincvs is a little bitchy, it assumes that
everything
is in Unix format and therefore change CR/LF to CR/CR/LF :/
So in the cvs repository, everything should be LF, then cvs or wincvs can
convert it to your local platform and back nicely.

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

> i. After all updates, a cvs comment must be added, this comment must
> include the authors name and the changes made.
Agreed.

> 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.txt?view=markup

You should be able to find a file in
lightbringer/bringeroflight/docs/history.txt already.

> iii. Module Creation
> Before any new modules are created a request must be sent to the
> project leaders and the other developers notified via the mailing
> list.This is merely a way
> of avoiding too many structural changes to the cvs directory
> (especially  module removal,which takes a lot of time on sourceforge).
Agreed

> iv. File Creation
> Any new files created should be followed by an announcment via the mailing
> list.
Since you can't really delete them, the should be discussed and confirmed by
an admin as well to avoid trash in the repository.

> v. File Deletion
On sourceforge you can (fortunately) not permanently delete a file. This has
to be requested by the SF staff.

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 even
pdf files (via LaTeX).

I also recommend the use of \todo, \depreciated, \bug and \test which allows
the
generation of todo lists, bug lists, etc.

> 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?

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