[mapserver-dev] Friendly reminder: Coding Style conventions

[Daniel Morissette]

Hi Devs, Release Manager speaking.

We don't have many coding style conventions for MapServer, but there are 
a few that we all seem to agree to and that we should try to follow.

Some of you may have received Trac tickets about this earlier today for 
specific files that were added in 6.0 and that we should try to fix 
before they are released for the first time in 6.0. Fixing them now 
before they are first released will make it easier to port patches in 
the future between 6.0 and 6.x releases.

So here we go, a friendly reminder to all devs of some coding style and 
committer conventions, following the quick code review that I made for 6.0:

1- Please include the standard mapserver header at the top of every 
source file. See mapserver.h or other .c files for an example.

2- Do not use TABs, use spaces instead to indent your code. The 
convention in MapServer source is that all tabs should be converted to 
the right amount of spaces so that indent is right in any editor, no 
matter what the tab size setting is in the editor. (Most editors have a 
setting to automatically convert tabs to spaces to help avoiding this 
problem in the future)

3- Avoid committing DOS CR/LF line breaks in the SVN repository. I don't 
see this as a mandatory requirement, but it's a nice to have. The most 
common source of this problem is files originally created on Windows 
with DOS CR/LF, and then copied to a Linux box and committed to SVN from 
the Linux box.

4- SVN Propset. New files should have the following SVN properties set. 
The svn:eol-style is especially important to prevent problems with DOS 
CR/LF between Windows and Linux:

    svn propset svn:keywords "Author Date Id Revision" myfile.c
    svn propset svn:eol-style native myfile.c

5- Trac and SVN commit notes:
Please don't forget that when committing something to SVN, the SVN 
comment should include a ref to the ticket number (e.g. #1234), and the 
Trac comment should include a reference to the changeset (e.g. r11223). 
This makes it easier to find our way through revisions when we need to 
track down problems with a given changeset or ticket.

6- HISTORY.TXT
Please don't forget that when committing a bug fix in a beta or a stable 
release branch, we try to include a one-liner in the HISTORY.TXT 
describing each fix from the users point of view and linking to the 
ticket number. This is then used to report the list of changes in later 
betas or point release announcements.

-- 
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000