Coding Rules

The code in OpenSAF adheres to varios coding guides:

• For code written in C, we follow the Linux kernel coding style
• For code written in C++, we follow the Google C++ Style Guide
• For code written in C, C++ and shell scripts, we also follow Linux Standard Base

Coding Guidelines

C code should follow the Linux kernel coding style, and C++ code should follow Google C++ Style Guide. One thing in particular to keep in mind is that C code should be indented with tabs, whereas C++ code should be indented with spaces. Also check that you don't add trailing white space at the end of the lines. The [Emacs] configuration example will configure the editor to highlight trailing whitespace in red to make it easy to detect. The [NetBeans] configuration instruction will set an option to remove trailing whitespace from modified lines when saving a file. You can use the [static analysis] tools (using the cpplint and checkpatch build targets in OpenSAF) to check if the code violates some of the coding rules - but be aware that these tools don't check all the coding rules and that they can give false positives.

Currently not all code follows the coding rules unfortunately, so when modifying existing code you may have to follow the indentation style in that particular file. But remember that the style guides talk about much more than just indentation. No matter how the file you are editing is indented, you should still follow other guidelines, e.g. avoid C++ features that are discouraged by the C++ Style Guide.

Thread Safety

Most OpenSAF programs are multi-threaded, and code in shared libraries can be linked with application programs, which we must assume can also be multi-threaded. Therefore, you should always be careful to avoid using C library functions that are not thread-safe. We have compiled a table of all [Unsafe and Obsolete Functions] that should be avoided in multi-threaded programs.

Portability

For both C and C++ you should check that all the functions you are using listed in Linux Standard Base. For example, if you intend to use a funcion in GNU libc, you should first check that both the function itself and any preprocessor macros (e.g. for constants) are listed in the Data Definitions for libc. Similarly, when writing shell scripts, make sure the commands you use are listed in Commands and Utilities. Do not use GNU extensions for your shell commands (e.g. bash extensions), since this is not portable and may not work if the command is provided by BusyBox.

Make sure the code you write works on different processor architectures: any combination of 32/64-bit word size and big/little endian should work. It should also be possible to use OpenSAF in a heterogenous cluster, i.e. a cluster containing nodes with different processor architectures.

In-service Upgradeability

It should be possible to upgrade OpenSAF without a cluster restart. This means that during the upgrade, some nodes in the cluster will be running with the old release of OpenSAF, wheras other (already upgraded) nodes will be running with the new release.

Backwards compatibility

Make sure your changes are backwards compatible from an application perspective. By this is meant that any correctly written application that works with the old release of OpenSAF should also work with the new release. This applies both to binaries compiled with the old release, as well as source code.