Fwd: Re: [airstrike] CVS accounts

Eero Tamminen oak at welho.com
Mon May 31 14:16:42 EDT 2004


Hi,

> Rule: Think before you commit, do large changes on a branch.
>
> Rule: We talk about large changes before we make them, ok! Specially
> if you are "fixing" someone elses code.

It might be enough if one just works on a one's own CVS checkout (instead
of a branch) and then before commiting stuff to someone else's code mails
a "cvs diff -ub" of the changes to the code maintainer(s) for OK.   (Code
maintainer / owner is of course Ulf, unless it's explicitly stated otherwise 
in the file)

For large stuff a bit of a discussion before hand would indeed be good. :-).
Personally I would prefer this to happen on the mailing list.

In general as this game has no other "devel" list, I would like this
list to have all of that.  Ulf, can Icculus provide mailing list archiving
too?  It would be sometimes nice to refer to an earlier mail.


> Rule: The game is written in C, not C++. We never cast from or to
>  void *.

What about use of C++ style // comments?   C99 would allow them, older
C standard versions not...


> Rule: We do not write for old and broken compilers. There may be some
> small exceptions.
>
> Rule: For inlining we use the INLINE macro.

I.e. there can be some generic macros/defines added.


> Rule: We definitely don't want any CR's in our code. Live with it.

Meaning: make sure either your editor / CVS frontend uses unix-style
newlines (LF) when commiting changes to CVS.   This concerns Windows
(CR, LF) and Mac (LF, CR) developers only I think.


On the code formatting, IMHO it's enough that one follows the conventions
in the corresponding C-file.   Ulf prefers 2 space indentation with GNU 
conventions (right?) whereas I've used on my own source files what's
recommended for the Linux kernel (I've used GNU style earlier, but with
larger projects I've come to prefer this):
	http://lxr.linux.no/source/Documentation/CodingStyle

Which one we should recommend as default? :-)


Ulf, could you add link to list of these rules to the Airstrike www-page
and/or airstrike module root?


> Maybe we should standardize on typename_t everywhere? I know I used
> struct blah somtimes, I will start to change it in places.

One more rule...


	- Eero



More information about the airstrike mailing list