Re: [Lightbringer-devel] Developer Guidelines

[<oza...@gm...>]

On 30/08/05, Team Digital <tea...@gm...> wrote:
> Hello All,
>              I'm now getting on track with the development, sorry for
> my absense :( but it was home related issue.Below is a sample set of
> Guidelines that we would
> like to implement,with respect to development.These were conceived to
> streamline development and provide a starting point to new
> developers.Any and all input would be welcomed and we can vote on any
> aspects that may be disputed :).
>=20
> 1. Coding Style
>     As we all have our own diverse coding styles, a single agreed upon
> style (e.g. K & R ) with a corresponding indentation ( 4 spaces tab
> width?) would give
> all the sourcefiles a uniform and intuitive appearance. There is also
> the issue of the various platforms that the developers might use and
> the different
> CR/LF characters that they use, using the gnu indent program may
> eliminate this problem.This, most likely, will be a topic that may
> need some voting as it may
> require the change of many of our ingrown habits (guilty :) ). You can
> vote by simply replying to this thread with your votes/comments and
> your suggested Styles, Naming Conventions and Indentation formats.
>=20
my vote goes to K&R because it gives smaller source files and easier readin=
g.
about tab space, we should put tab not spaces then everybody can use
their prefered tab width with their prefered editor. i always put tab,
not spaces.
Naming Convention; i have no idea. i don't use one.

> 2. Updating
>     With respect to updating the cvs directory,two notification
> approaches were concieved.
>=20
> i. After all updates, a cvs comment must be added, this comment must
> include the authors name and the changes made.
>=20
> ii. A Changes File could be created that will contain information
> about contributions.Here is the suggested format of this file.
>=20
> *****************************
> DATE
> AUTHOR
> COMMENTS
> FILES-UPDATED
> *****************************
>=20
> The Changes File is merely for archival and troubleshooting
> purposes,one should be created per module,we can use either one of
> these schemes or a mix of both, we're open to any other suggestions.
>=20
makes sence a lot
> 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).
>=20
makes sence
> iv. File Creation
> Any new files created should be followed by an announcment via the mailin=
g list.
>=20
yep
> v. File Deletion
> Ads above, any removal of files (whether created by you or not).Should
> be preceded be a request to the project leaders and a notification to
> the developers
> via the mailing list.
>=20
nice
> 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. e.g.
>=20
> *******************************
> FILENAME:
> PURPOSE:
> NOTES:
> EXPORTED FUNCTIONS:
> ******************************
>=20
> Also before every function a section must be created that should
> contain the following information:
>=20
> /*
> function name
> function parameters
> function comments
> */
>=20
return info should be there, too.
> These may be painful initially but they may be (hopefully)rarely updated.
>=20
> 4. Tools
> Since there are two development platforms currently in use, this is
> even more important.It is the sole responsibility of the developer to
> maintain the versions that are currently supported. We will try ,as a
> team, to choose the most generic tools that can be used to create the
> sources, A development platform thread will be created to facilitate
> this, It will contain all the software and their versions used to
> create the program.As such all new and current members will be asked
> to maintain a certain development environment depending on platform.
> This is another topic that may/may not require voting.
>=20
> This is all that I have for now,as I expect that we will need to
> formalize and standardise on these practices, since it was suggested
> in a recent post that a
> complete code rewrite be done,this may end up being relatively
> painless.I'm looking forward to your correspondence on this topic and
> your votes :).
>=20

--=20
Ozan