blob: 74fe8de6d026e4e244f84dd5a281e0dd527aefcd [file] [log] [blame]
.. _code_style:
===================
The libc code style
===================
Naming style
============
For the large part, the libc project follows the general `coding standards of
the LLVM project <https://llvm.org/docs/CodingStandards.html>`_. The libc
project differs from that standard with respect to the naming style. The
differences are as follows:
#. **Non-const variables** - This includes function arguments, struct and
class data members, non-const globals and local variables. They all use the
``snake_case`` style.
#. **const and constexpr variables** - They use the capitlized
``SNAKE_CASE`` irrespective of whether they are local or global.
#. **Function and methods** - They use the ``snake_case`` style like the
non-const variables.
#. **Internal type names** - These are types which are interal to the libc
implementation. They use the ``CaptilizedCamelCase`` style.
#. **Public names** - These are the names as prescribed by the standards and
will follow the style as prescribed by the standards.
Macro style
===========
We define two kinds of macros: **code defined** and **build defined** macros.
#. **Build defined** macros are generated by `CMake` or `Bazel` and are passed
down to the compiler with the ``-D`` command line flag. They start with the
``LIBC_COPT_`` prefix. They are used to tune the behavior of the libc.
They either denote an action or define a constant.
#. **Code defined** macros are defined within the ``src/__support/macros``
folder. They all start with the ``LIBC_`` prefix. They are of two kinds
* **Properties** - Build related properties like used compiler, target
architecture or enabled CPU features defined by introspecting compiler
defined preprocessor defininitions. e.g., ``LIBC_TARGET_ARCH_IS_ARM``,
``LIBC_TARGET_CPU_HAS_AVX2``, ``LIBC_COMPILER_IS_CLANG``, ...
* **Attributes** - Compiler agnostic attributes or functions to handle
specific operations. e.g., ``LIBC_INLINE``, ``LIBC_NO_LOOP_UNROLL``,
``LIBC_LIKELY``, ``LIBC_INLINE_ASM``.
Inline functions defined in header files
========================================
When defining functions inline in header files, we follow certain rules:
#. The functions should not be given file-static linkage. There can be class
static methods defined inline however.
#. Instead of using the ``inline`` keyword, they should be tagged with the
``LIBC_INLINE`` macro defined in ``src/__support/common.h``. For example:
.. code-block:: c++
LIBC_INLINE ReturnType function_defined_inline(ArgType arg) {
...
}
#. The ``LIBC_INLINE`` tag should also be added to functions which have
definitions that are implicitly inline. Examples of such functions are
class methods (static and non-static) defined inline and ``constexpr``
functions.