From WhitixDoc

Developer guidelines

Coding standards Submitting patches

This document explains the general Whitix coding standards and style. These should be employed in any Whitix-related project. Most of the standards here will cover C programs.

Contents 1 Indenting and whitespace 2 Operators 3 Control structures 4 File header and includes 4.1 Functions 4.2 Constants 4.3 Variables 4.4 Structures 4.5 File names 5 Function calls 6 Function declarations 7 Comments 8 Compiler warnings 9 Sample

Indenting and whitespace

Use tabs for indentation, and use whitespace to improve readability where possible. If in doubt, use whitespace.

Operators

In a C program, use a space between binary operators such as +, -, ||, && (e.g. a + b, rather than a+b), for the sake of readabililty.

Control structures

File header and includes

In the kernel, all files should be prefixed with the license information, like so:

/*  This file is part of Whitix.
 *
 *  Whitix 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.
 *
 *  Whitix 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 Whitix; if not, write to the Free Software
 *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 *
 */

Functions

Function names should be in CamelCase, should contain a verb (poll, do, write), and, if in a large program, should contain the module's name as a prefix. For example, VfsPollFd. This leads to shorter identifiers and is easier to type on most keyboards.

Constants

If defined using #define, the constant should be in capital letters, and words separated by underscores, like so: #define ONE_HUNDRED 100

Variables

Variable names should be CamelCase, and be as descriptive as possible (without sacrificing typability). For example, int aliveProcesses;.

Structures

Structure names should be in CamelCase.

File names

File names should always be in lowercase, with words separated by underscores. For example, open_file.c.

Function calls

Function declarations

Large or important functions should have a comment describing exactly what the function does, what it takes and what it returns.

/***********************************************************************
 *
 * FUNCTION: <function name>
 *
 * DESCRIPTION: <description>
 *
 * PARAMETERS: <explanation of each parameter>
 *
 * RETURNS: <return code>
 *
 ***********************************************************************/

Comments

The use of C-style comments (/* */) is strongly encouraged, rather than C++ style comments (//).

Compiler warnings

Programs should be developed, where possible, to not produce compiler warnings upon compilation. Using the GCC compiler, this option can be enabled using -Wall, and the use of -Werror (warnings are displayed as errors) is encouraged.

Sample