quakeforge/doc/CodingStyle

130 lines
3.6 KiB
Plaintext
Raw Normal View History

QuakeForge Coding Style
~~~~~~~~~~~~~~~~~~~~~~~
You /WILL/ indent with hard tabs, or you will be harmed. :) You can
format for whatever tab spacing you like, but if you indent with spaces
you will be hurt and you will have deserved it. :)
For best results, and to keep other developers from saying things like
"what bastard formatted this?", you should use 4-space tabs, because
that's what id used and what most of us use. This is only a guideline,
though, not a requirement.
Each source file should have a standard comment, formatted as in the
example below.
When you create a new source file, make sure you put an RCS ID below the
opening comment. One of the things this lets us do is use the "ident"
tool (comes with RCS) to identify all of the source files compiled into
an executable. This is done by embedding [dollar sign]Id: [dollar sign]
into the file, and CVS will automagically add the version information to
the source file.
All source files MUST #include "config.h" if the symbol HAVE_CONFIG_H
is defined. Likewise, no source file may be compiled multiple times to
produce different object files -- one source, one object.
Atop each function you write, you should attach a /* */ comment heading,
containing the name and a short, DESCRIPTIVE summary of the function's
purpose. Indent both of these with one or more tabs. The function is to
immediately follow the heading, with no space between. When you move or
rename a function, or change what it does, change the heading to match.
The return type should be located on the line previous to the function's
name, and the function's name should begin with the very first character
of a line. This is to facilitate easy searches for a function using the
simple regular expression "^FuncName".
Functions that do not take a value should be explicitly declared to
accept void, not simply ().
On brace style: QuakeForge code uses "cuddled" braces, also called K&R
and the One True Brace Style (yes, it really is called that), so-called
because it is the brace style used by the creators of the C language.
Please use a prefix for new functions. The currently-defined prefixes
are described below:
Cross-target prefixes:
IN_ Input
JOY_ Joystick (called by IN_* functions)
R_ Rendering
S_ Sound
VID_ Low-level video
Target-specific prefixes:
CL_ Client
GL_ OpenGL rendering
QFGL_ OpenGL portability aids
SNDDMA_ DMA Sound (called from S_*)
SV_ Server
SW_ Software rendering
X11_ X11R6-specific window handling
An example:
/*
filename.c
Description of this file
Copyright (C) 2002 Your Name <your@email.addr>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public
License along with this program; if not, write to:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
*/
static const char rcsid[] =
"$Id$";
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
/*
SECTION_FunctionName
Description
*/
returntype
SECTION_FunctionName (args)
{
type var;
for (var = 0; var; var++) { // do something silly
:
:
}
}
For switch statements:
switch (expr) {
case X: // foo
:
:
break;
case Y: // bar
:
:
break;
default: // fallthrough
whatever;
}