.. _code_style: =================== The libc code style =================== Naming style ============ For the large part, the libc project follows the general `coding standards of the LLVM project `_. 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.