Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add C compiler base options guidelines #63

Open
wants to merge 3 commits into
base: wip/coding_guidelines
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
97 changes: 95 additions & 2 deletions source/development/coding_style.rst
Original file line number Diff line number Diff line change
@@ -1,4 +1,97 @@
.. _coding_guidelines:

Coding Guidelines and Style
===========================
Coding Guidelines
=================

This document specifies a set of coding guidelines, including code style,
formatting, file structuring and organization that shall be applied when
contributing code to the Bao project. We strive to ensure that most of the
guidelines can be automatically checked or even enforced by the CI pipeline and
minimize guidelines that can not be automatically addressed. In cases where it
is not feasible to automatically enforce certain guidelines, the responsibility
lies with the code reviewers and maintainers to ensure that these guidelines
are adhered to as closely as possible.

C Language
----------

The coding style and guidelines for C development are heavily influenced and
constrained by the MISRA C:2012 guidelines, which should take precedence above
all others in this document or elsewhere.

All C projects should support either the GCC compiler, the Clang compiler or
both. If one compiler is supported for given project, it must be so for all
supported target architectures.
Comment on lines +23 to +24
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be too strict, for example for tricore


For reach guideline we try to provide a set of compiler options which enforce
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For reach guideline we try to provide a set of compiler options which enforce
For each guideline we try to provide a set of compiler options which enforce

the rule, a mapping to a MISRA C:2012 and tools available in the :ref:`CI
infrastructure <ci>` that can check if this guideline is being adhered to.

Compiler Configuration
**********************

- The C11 version shall be used.

Compiler options: `-std=c11`.
MISRA C:2012 : R1.1

- No language extensions shall be allowed.

Compiler options: `-pedantic -pedantic-errors`.
MISRA C:2012 : R1.1

- Treat all warnings as errors so no warnings can be ignored.

Compiler options: `-Werrors`.

- Enable all recommended warnings.

Compiler options: `-Wall -Wextra`.
Comment on lines +33 to +49
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- The C11 version shall be used.
Compiler options: `-std=c11`.
MISRA C:2012 : R1.1
- No language extensions shall be allowed.
Compiler options: `-pedantic -pedantic-errors`.
MISRA C:2012 : R1.1
- Treat all warnings as errors so no warnings can be ignored.
Compiler options: `-Werrors`.
- Enable all recommended warnings.
Compiler options: `-Wall -Wextra`.
R1. **The C11 version shall be used.**
- Compiler options: `-std=c11`. MISRA C:2012 : R1.1
R2. **No language extensions shall be allowed.**
- Compiler options: `-pedantic -pedantic-errors`. MISRA C:2012 : R1.1
R3. **Treat all warnings as errors so no warnings can be ignored.**
- Compiler options: `-Werrors`.
R4. **Enable all recommended warnings.**
- Compiler options: `-Wall -Wextra`.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO, i'd prefer this type of format so if we want to reference one rule we can use the enumeration (e.g., R1, etc)

image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree


Directory and file Structure
****************************

Pre-processor directives and macros
***********************************

Header Files
************

Variable Declarations, Qualifiers and Initializations
*****************************************************

Functions
*********

Statements
**********

Expressions
***********

Literals
********

Identifiers and Naming
**********************

Inline Assembly
***************

Compiler Directives, Intrinsic and Attributes
**********************************************

Assertion, Error Handling and Sanity checking
*********************************************

Comments, Documentation and License
***********************************

Coding Style and Formatting
***************************

Keyword Usage
*************

Libraries and Headers
*********************