Skip to content

Latest commit

 

History

History
140 lines (123 loc) · 7.12 KB

CODING_STYLE.md

File metadata and controls

140 lines (123 loc) · 7.12 KB
Raw

C Style and Coding Standards for VMEM

This document defines the coding standards and conventions for writing VMEM code. To ensure readability and consistency within the code, the contributed code must adhere to the rules below.

Introduction

VMEM coding style is quite similar to the style used for the SunOS product. A full description of that standard can be found here.

This document does not cover the entire set of recommendations and formatting rules used in writing VMEM code, but rather focuses on some VMEM-specific conventions, not described in the document mentioned above, as well as the ones the violation of which is most frequently observed during the code review. Also, keep in mind that more important than the particular style is consistency of coding style. So, when modifying the existing code, the changes should be coded in the same style as the file being modified.

Code formatting

Most of the common stylistic errors can be detected by the style checker program included in the repo. Simply run make cstyle or CSTYLE.ps1 to verify if your code is well-formatted.

Here is the list of the most important rules:

  • The limit of line length is 80 characters.
  • Indent the code with TABs, not spaces. Tab width is 8 characters.
  • Do not break user-visible strings (even when they are longer than 80 characters)
  • Put each variable declaration in a separate line.
  • Do not use C++ comments (//).
  • Spaces around operators are mandatory.
  • No whitespace is allowed at the end of line.
  • For multi-line macros, do not put whitespace before \ character.
  • Precede definition of each function with a brief, non-trivial description. (Usually a single line is enough.)
  • Use XXX tag to indicate a hack, problematic code, or something to be done.
  • For pointer variables, place the * close to the variable name not pointer type.
  • Avoid unnecessary variable initialization.
  • Never type unsigned int - just use unsigned in such case. Same with long int and long, etc.
  • Sized types like uint32_t, int64_t should be used when there is an on-media format. Otherwise, just use unsigned, long, etc.
  • Functions with local scope must be declared as static.

License & copyright

  • Make sure you have the right to submit your contribution under the BSD license, especially if it is based upon previous work. See CONTRIBUTING.md for details.
  • A copy of the BSD-style License must be placed at the beginning of each source file, script or man page (Obviously, it does not apply to README's, Visual Studio projects and *.match files.)
  • When adding a new file to the repo, or when making a contribution to an existing file, feel free to put your copyright string on top of it.

Naming convention

  • Keep identifier names short, but meaningful. One-letter variables are discouraged.
  • Use proper prefix for function name, depending on the module it belongs to.
  • Use under_score pattern for function/variable names. Please, do not use CamelCase or Hungarian notation.
  • UPPERCASE constant/macro/enum names.
  • Capitalize first letter for variables with global or module-level scope.
  • Avoid using l as a variable name, because it is hard to distinguish l from 1 on some displays.

Multi-OS support (Linux/FreeBSD/Windows)

  • Do not add #ifdef <OS> sections lightly. They should be treated as technical debt and avoided when possible.
  • Use _WIN32 macro for conditional directives when including code using Windows-specific API.
  • Use __FreeBSD__ macro for conditional directives for FreeBSD-specific code.
  • Use _MSC_VER macro for conditional directives when including code using VC++ or gcc specific extensions.
  • In case of large portions of code (i.e. a whole function) that have different implementation for each OS, consider moving them to separate files. (i.e. xxx_linux.c, xxx_freebsd.c and xxx_windows.c)
  • Keep in mind that long int is always 32-bit in VC++, even when building for 64-bit platforms. Remember to use long long types whenever it applies, as well as proper formatting strings and type suffixes (i.. %llu, ULL).
  • Standard compliant solutions should be used in preference of compiler-specific ones. (i.e. static inline functions versus statement expressions)
  • Do not use formatting strings that are not supported by Windows implementations of printf()/scanf() family. (like %m)
  • It is recommended to use PRI* and SCN* macros in printf()/scanf() functions for width-based integral types (uint32_t, int64_t, etc.).

Debug traces and assertions

  • Put LOG(3, ...) at the beginning of each function. Consider using higher log level for most frequently called routines.
  • Make use of COMPILE_ERROR_ON and ASSERT* macros.
  • Use ERR() macro to log error messages.

Unit tests

  • There must be unit tests provided for each new function/module added.
  • Test scripts must start with #!/usr/bin/env <shell> for portability between Linux and FreeBSD.
  • Please, see this and that document to get familiar with our test framework and the guidelines on how to write and run unit tests.

Commit messages

All commit lines (entered when you run git commit) must follow the common conventions for git commit messages:

  • The first line is a short summary, no longer than 50 characters, starting with an area name and then a colon. There should be no period after the short summary.
  • Valid area names are: **pmem, obj, blk, log, vmem, vmmalloc, jemalloc, test, doc, daxio, pmreorder, pool (for libpmempool and pmempool), rpmem (for librpmem and rpmemd), benchmark, examples and common (for everything else).
  • It is acceptable for the short summary to be the only thing in the commit message if it is a trivial change. Otherwise, the second line must be a blank line.
  • Starting at the third line, additional information is given in complete English sentences and, optionally, bulleted points. This content must not extend beyond column 72.
  • The English sentences should be written in the imperative, so you say "Fix bug X" instead of "Fixed bug X" or "Fixes bug X".
  • Bullet points should use hanging indents when they take up more than one line (see example below).
  • There can be any number of paragraphs, separated by a blank line, as many as it takes to describe the change.
  • Any references to GitHub issues are at the end of the commit message.

For example, here is a properly-formatted commit message:

doc: fix code formatting in man pages

This section contains paragraph style text with complete English
sentences.  There can be as many paragraphs as necessary.

- Bullet points are typically sentence fragments

- The first word of the bullet point is usually capitalized and
  if the point is long, it is continued with a hanging indent

- The sentence fragments don't typically end with a period

Ref: pmem/issues#1