libcamera/vivid.git - libcamera pipeline handler for VIVID

diff options

Diffstat (limited to 'src/qcam/assets/feathericons/edit.svg')

0 files changed, 0 insertions, 0 deletions

.. SPDX-License-Identifier: CC-BY-SA-4.0 .. _coding-style-guidelines: Coding Style Guidelines ======================= These coding guidelines are meant to ensure code quality. As a contributor you are expected to follow them in all code submitted to the project. While strict compliance is desired, exceptions are tolerated when justified with good reasons. Please read the whole coding guidelines and use common sense to decide when departing from them is appropriate. libcamera is written in C++, a language that has seen many revisions and offers an extensive set of features that are easy to abuse. These coding guidelines establish the subset of C++ used by the project. Coding Style ------------ Even if the programming language in use is different, the project embraces the `Linux Kernel Coding Style`_ with a few exception and some C++ specificities. .. _Linux Kernel Coding Style: https://www.kernel.org/doc/html/latest/process/coding-style.html In particular, from the kernel style document, the following section are adopted: * 1 "Indentation" * 2 "Breaking Long Lines" striving to fit code within 80 columns and accepting up to 120 columns when necessary * 3 "Placing Braces and Spaces" * 3.1 "Spaces" * 8 "Commenting" with the exception that in-function comments are not always un-welcome. While libcamera uses the kernel coding style for all typographic matters, the project is a user space library, developed in a different programming language, and the kernel guidelines fall short for this use case. For this reason, rules and guidelines from the `Google C++ Style Guide`_ have been adopted as well as most coding principles specified therein, with a few exceptions and relaxed limitations on some subjects. .. _Google C++ Style Guide: https://google.github.io/styleguide/cppguide.html The following exceptions apply to the naming conventions specified in the document: * File names: libcamera uses the .cpp extensions for C++ source files and the .h extension for header files * Variables, function parameters, function names and class members use camel case style, with the first letter in lower-case (as in 'camelCase' and not 'CamelCase') * Types (classes, structs, type aliases, and type template parameters) use camel case, with the first letter in capital case (as in 'CamelCase' and not 'camelCase') * Enum members use 'CamelCase', while macros are in capital case with underscores in between * All formatting rules specified in the selected sections of the Linux kernel Code Style for indentation, braces, spacing, etc * Header guards are formatted as '__LIBCAMERA_FILE_NAME_H__' Order of Includes ~~~~~~~~~~~~~~~~~ Headers shall be included at the beginning of .c, .cpp and .h files, right after the file description comment block and, for .h files, the header guard macro. For .cpp files, if the file implements an API declared in a header file, that header file shall be included first in order to ensure it is self-contained. The headers shall be grouped and ordered as follows: 1. The header declaring the API being implemented (if any) 2. The C and C++ system and standard library headers 3. Other libraries' headers, with one group per library 4. Other project's headers Groups of headers shall be separated by a single blank line. Headers within each group shall be sorted alphabetically. System and library headers shall be included with angle brackets. Project headers shall be included with angle brackets for the libcamera public API headers, and with double quotes for other libcamera headers. C++ Specific Rules ------------------ The code shall be implemented in C++17, with the following caveats: * Type inference (auto and decltype) shall be used with caution, to avoid drifting towards an untyped language. * The explicit, override and final specifiers are to be used where applicable. * Smart pointers, as well as shared pointers and weak pointers, shall not be overused. * Classes are encouraged to define move constructors and assignment operators where applicable, and generally make use of the features offered by rvalue references. Object Ownership ~~~~~~~~~~~~~~~~ libcamera creates and destroys many objects at runtime, for both objects internal to the library and objects exposed to the user. To guarantee proper operation without use after free, double free or memory leaks, knowing who owns each object at any time is crucial. The project has enacted a set of rules to make object ownership tracking as explicit and fool-proof as possible. In the context of this section, the terms object and instance are used interchangeably and both refer to an instance of a class. The term reference refers to both C++ references and C++ pointers in their capacity to refer to an object. Passing a reference means offering a way to a callee to obtain a reference to an object that the caller has a valid reference to. Borrowing a reference means using a reference passed by a caller without ownership transfer based on the assumption that the caller guarantees the validity of the reference for the duration of the operation that borrows it. 1. Single Owner Objects * By default an object has a single owner at any time. * Storage of single owner objects varies depending on how the object ownership will evolve through the lifetime of the object. * Objects whose ownership needs to be transferred shall be stored as std::unique_ptr<> as much as possible to emphasize the single ownership. * Objects whose owner doesn't change may be embedded in other objects, or stored as pointer or references. They may be stored as std::unique_ptr<> for automatic deletion if desired. * Ownership is transferred by passing the reference as a std::unique_ptr<> and using std::move(). After ownership transfer the former owner has no valid reference to the object anymore and shall not access it without first obtaining a valid reference. * Objects may be borrowed by passing an object reference from the owner to the borrower, providing that * the owner guarantees the validity of the reference for the whole duration of the borrowing, and * the borrower doesn't access the reference after the end of the borrowing. When borrowing from caller to callee for the duration of a function call, this implies that the callee shall not keep any stored reference after it returns. These rules apply to the callee and all the functions it calls,


context:
space:
mode: