"Fossies" - the Fresh Open Source Software Archive
Member "exiv2-0.27.6-Source/CODING_GUIDELINES.md" (18 Jan 2023, 4483 Bytes) of package /linux/misc/exiv2-0.27.6-Source.tar.gz:
As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format).
Alternatively you can here view
the uninterpreted source code file.
A member file download can also be achieved by clicking within a package contents listing on the according byte size field. See also the last Fossies "Diffs"
side-by-side code changes report for "CODING_GUIDELINES.md": 0.27.0_vs_0.27.1
A hint: This file contains one or more very long lines, so maybe it is better readable using the pure text view mode that shows the contents as wrapped lines within the browser window.
1. General Guidelines
- All new code must be properly tested: via unit tests (based on the
Gtest framework; see
$REPO/unitTest) or system tests
(scripts exercising the main exiv2 application; see
- Code should be simple to read and to understand.
- Do not invoke undefined behavior. [Optional] Ensure that with UBSAN,
i.e. compile your code with
-fsanitize=undefined and run
the test suite.
- Ensure that your code has no memory errors. [Optional] Use ASAN for
that, i.e. compile your code with
2. Integer and Array
- All new code that is added must be resistant to integer overflows,
thus if you multiply, add, subtract, divide or bitshift integers you
must ensure that no overflow can occur. Please keep in mind that signed
integer overflow is undefined behavior, thus you must check for
overflows before performing the arithmetic operation, otherwise the
compiler is free to optimize your check after the overflow away (this
has happened already).
- All new code must be resistant to buffer overflows. Thus before you
access arrays a range check must be performed.
- Distrust any data that you extract from images or from external
sources. E.g. if the metadata of an image gives you an offset of another
information inside that file, do not assume that this offset will not
result in an out off bounds read.
- New code must not assume the endianes and the word size of the
system it is being run on. I.e. don't assume that
sizeof(int) = 8 or that the following will work:
const uint32_t some_var = get_var();
const uint16_t lower_2_bytes = (const uint16_t*) &some_var;
since this will give you the upper two bytes on big endian systems.
If in doubt, then use the fixed size integer types like
3. Code Formatting
The project contains a
defining the code formatting of the project (more details about of this
file was defined can be found in this PR). We do not
provide it via the standard name (
.clang-format), since we
do not enforce code formatting and do not want editors to automatically
Nevertheless, we suggest you to respect the code formatting by
.clang-format and applying
clang-format to new
or existing code. You can do it by using the
command-line tool or by using one of the integration plugins provided by
various editors or IDEs. Currently we know about these integrations:
Note that some times the formatting applied to complex code might
result in some unexpected output. If you know how to improve the current
.clang-format file to deal with such cases, then please
contribute!. Otherwise, you have two options:
clang-format to individual blocks of code (avoid
to apply it over the complex piece of code).
- Indicate which parts of the code that should not be
// clang-format off
void unformatted_code ;
// clang-format on
3.1 Guidelines to Apply
- New files should follow the clang-format style.
- Old files will be completely re-formatted only if we need to touch
several lines/functions/methods of that file. In that case, we suggest
to first create a PR just re-formatting the files that will be touched.
Later we create another PR with the code changes.
- If we only need to fix a small portion of a file then we do not
apply clang-format at all, or we just do it in the code block that we
More information about clang: