| .. _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. |