[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E. FreeM Project Coding Standards


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.1 Module Headers

Module headers should adhere to the following format:

/*
 *                            *
 *                           * *
 *                          *   *
 *                     ***************
 *                      * *       * *
 *                       *  MUMPS  *
 *                      * *       * *
 *                     ***************
 *                          *   *
 *                           * *
 *                            *
 *
 *   mlib.h
 *    Function prototypes, structs, and macros for FreeM
 *    binding library
 *
 *  
 *   Author: John P. Willis <jpw@coherent-logic.com>
 *    Copyright (C) 1998 MUG Deutschland
 *    Copyright (C) 2020 Coherent Logic Development LLC
 *
 *   Last modified: 29 February 2020
 * 
 **/

The Star of David in module headers is a convention started by Shalom ha-Ashkenaz, the unidentified original author of FreeMUMPS/FreeM. We will continue to employ it in honor of his most valuable contribution to the MUMPS community.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.2 Variable Naming

Variables should be named in all lowercase letters, and words within them delimited by underscores, such as my_useful_variable. PascalCase and camelCase are not to be used in this codebase under any circumstances.

Constants defined via the C preprocessor should be in all uppercase letters, with words within them likewise delimited by underscores, such as:

#define MY_USEFUL_CONSTANT 1

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.3 Indentation and General Layout

This project uses four spaces for indentation. Tabs are not to be used under any circumstances, and all source files must use a linefeed character to delineate lines. If you are working on a Windows machine, you must take care to follow this, as Windows will use a carriage return followed by a linefeed by default.

This project follows a modified version of what is known as the Stroustrup indentation style.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.4 Brace Placement (Functions)

We use modern, ANSI-style function prototypes, with the type specifier on the same line as the function name. You may encounter other styles in the code, but we are transitioning to the new style as time permits.

Below is a correct example:

int main(int argc, char **argv, char **envp)
{

}

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.5 Brace Placement (if-for-while-do)

The if keyword should be followed by one space, then the opening paren and conditional expression. We also use Stroustrup-style else blocks, rather than the K&R ’cuddled’ else:

if (x) {
...
}
else {
...
}

while (1) {
...
}

for (i = 1; i < 10; i++) {
...
}

do {
...
} while (x);

Single-statement if blocks should be isolated to a single line:

if (x) stmt();

not:

if(x)
    stmt();

Notice that there is a space between if and (x), but not between stmt and (). This should be followed throughout the code.

If an if block has an else if or else, all parts of the construct must be bracketed, even if one or more of them contain only one statement:

if (x) {
    foo();
}
else if (y) {
    bar();
}
else {
    bas();
}

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.6 Labels and goto

Labels must begin in column 1, and have two lines of vertical space above and one beneath.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.7 Preprocessor Conditionals


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.8 coding standards, preprocessor conditionals

I have struggled with this, but have settled upon the standard practice of keeping them in column 1.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.9 Overall Program Spacing


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.10 The switch() Statement

We indent case one level beneath switch(), and the code within each case beneath the case. Each case should have one line of vertical whitespace above it:

switch(foo) {

    case some_const:
        foo();

        break;

    case some_other_const:
        bar();

        break;	    

    default:
        exit(1);

        break;
}

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

E.11 Comments

We use C-style comments (/* comment */) exclusively, even on single-line comments. C++ comments (// comment) are not permitted.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by John P. Willis on March 13, 2020 using texi2html 1.82.