© Copyright 2006 The 'Verse Project. All rights reserved.
Hosted by:
There will always be unspoken rules about what a developer is expected to do, etc in any given project. Since I like things to be in the open as much as possible, I'll attempt to air out as much as I can.
Every developer will adhere to the coding standards. Failure to do so will probably result in expulsion from the project.
Personally, I would love nothing than to have the project run Mac OSX, *BSD, Linux, windows, all the way down to BeOS/Haiku. The tech choices where made to make this as easy as possble. So, let's not ruin it with stupid coding practices.
This document which be have mirrored from here should be helpful on how to enforce strict ANSI/ISO C during compiling.
Any code that is committed to the repository will have been compiled and tested on at least two different platforms. A side effect of this is that every developer must have access to at least two different OS's.
There will always be the tempation to code now and document later. This is fine as long as no-one knows you are doing it. What I mean by this is that if by the time you commit the code to the repository, it's properly documented, then I don't care. But, never will there be undocumented code/anything in the repository.
Documentation will contain as little acronyms as possible (preferably none), and will be in complete sentences writting in proper english (ie "peeps" or any such thing never enters any documentation). Documentation will be clear, not only to you, but to other developers as well. Just keep in mind, while you write, that we aren't listening to your inner most thoughts while you were writting the documentation.
Every developer will subscribe to the general developer mailing list, as well as one(s) specific to there own project.
No developer will make any changes to a portion of a SConstruct that does not belong to their platform. If a change is/may be required on other platforms, then the developer will send an email to the list when the change is committed (preferably a heads up before hand as well).
As this is a cross-platform game, all tools will run on all platforms that the game does. Please note that this is not "a goal" of the project so much as it is a requirement.
Mind the switches used for gcc. They are there for a reason. If they generate a warning, fix it. A warning on one system might be an error on another. If a warning can't be resolved (trade one for another), document that above the offending code.
Line markers. Unix markers will be used ie \n. What this means is the those on windows will not use their native end line markers. I know that Cygwin allows for either to be used, so there really isn't any excuse for not using them. Reason is that those of us on Unix like systems don't like to see ^M's at the end of every line; makes things messy. It also plays havoc with CVS as CVS just sees a change on the line and thus creates a (probably large) differ for all lines ending in ^M (which means all of them). So, don't do it!
Hungarian notation is explicitly forbidden. The only thing that is allowed along these lines is if a variable is global. Then the name will begin with the module name eg In the render engine, global variable names will begin with render_*.
A code walk-through document will be kept for all programs in this project once the program becomes somewhat stable in its structure. This document will reflect the current state of the program. Consider this part of the documentation that has to be committed along with any changes.
Regarding bugs, they will be considered to exist on all platforms until proven otherwise. So, just because a bug is reported on a windows build does not necessarily mean that a windows developer must fix the bug. If it exists on other platforms as well, someone developing on Mac OSX might get assigned to fix the bug. The point of all this is to even out who fixes what bug so the windows people don't get overloaded (I'm thinking most users will be using windows).
Anything that has been omitted here or elsewhere, ask.