Method C-Coding Standard

Revision: 1.
22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 1 of 40
C-Coding Standard
Document Path in STAGES:

Methods > Software Development > Software Detailed Design, Implementation and Component Test > C-Coding Standard
ZF Proprietary: Printed copies are for reference only-controlled copy located in STAGES.
Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 2 of 40
Table of Contents
1 Introduction ....................................................................................................................................... 4
1.1 Purpose and Scope ................................................................................................................... 4
1.2 Acronyms .................................................................................................................................. 4
1.3 Interpretation of Terms .............................................................................................................. 4
1.4 Definitions.................................................................................................................................. 4
1.5 Conventions in this document ................................................................................................... 5
2 C programming language standard ................................................................................................ 6
2.1 Assembly code with C ............................................................................................................... 6
3 Naming Conventions ........................................................................................................................ 6
3.1 General Rules ........................................................................................................................... 6
3.2 Types......................................................................................................................................... 7
3.3 Variables ................................................................................................................................... 8
3.3.1 Global Variables.................................................................................................................... 9
3.3.2 Local Variables ..................................................................................................................... 9
3.4 Enums ..................................................................................................................................... 10
3.5 Structures / Unions .................................................................................................................. 10
3.6 Functions ................................................................................................................................. 12
3.7 Pointers ................................................................................................................................... 13
3.8 Constants ................................................................................................................................ 13
3.9 Defines / Macros ..................................................................................................................... 13
4 Layout ................................................................................................................................................ 15
4.1 General Rules ......................................................................................................................... 15
4.2 Line Rules ............................................................................................................................... 15
4.3 Code Blocks ............................................................................................................................ 15
4.4 Condition Statements .............................................................................................................. 15
4.5 Switch Statements .................................................................................................................. 16
4.6 Spaces .................................................................................................................................... 16
4.7 Parenthesis ............................................................................................................................. 17
4.8 Local variables ........................................................................................................................ 17
4.9 Temporary Code Blocks .......................................................................................................... 17
4.9.1 Based on temporary requirements or request .................................................................... 17
4.9.2 Related with bug-fixing of supplier code ............................................................................. 18
4.10 Engineering Code Blocks ........................................................................................................ 18
5 Documenting the code ..................................................................................................................... 20
5.1 General Rules ......................................................................................................................... 20
5.2 Used Doxygen Tags ................................................................................................................ 20

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 3 of 40
5.3 Doxygen Extensions at ZF ...................................................................................................... 20

5.4 Standard comments ................................................................................................................ 20
5.5 Side comments ....................................................................................................................... 21
5.6 Inline Comments ..................................................................................................................... 21
5.7 Comments after implementation ............................................................................................. 21
5.8 TODO Comments ................................................................................................................... 22
5.9 Commenting QAC Violations .................................................................................................. 22
5.10 Commenting compiler warning................................................................................................ 23
5.11 Commenting Polyspace Violations ......................................................................................... 24
6 Design Guidelines ............................................................................................................................ 27
6.1 MISRA based guidelines ......................................................................................................... 27
7 Supportive Guidelines ..................................................................................................................... 27
7.1 Defensive and secure programming ....................................................................................... 27
8 Adherence External Standards ....................................................................................................... 29
8.1 MISRA C guidelines ................................................................................................................ 29
8.1.1 Third party software ............................................................................................................ 29
8.2 CERT-C guidelines ................................................................................................................. 29
8.3 HIS metrics .............................................................................................................................. 29
8.4 ISO 26262 ............................................................................................................................... 29
8.5 AUTOSAR ............................................................................................................................... 31
8.6 Customer requirements ........................................................................................................... 31
9 Coding Standard(s) enforcement ................................................................................................... 32
10 References ........................................................................................................................................ 33
11 List of removed rules ....................................................................................................................... 35
12 Revision History of this document ................................................................................................. 36

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 4 of 40
1 Introduction
1.1 Purpose and Scope
The purpose of this document is to define a mandatory C-code guidelines considering MISRA-C:2012, HIS,
ASPICE, AUTOSAR and ISO 26262-6. The guideline shall be followed to ensure uniformity in the code for
all ZF Division U: Electronics and ADAS projects. Such uniformity facilitates more effective design reviews
and minimizes the effort required for multiple engineers to work as a cohesive team.
The scope of this document is related to the content of C source code files.
1.2 Acronyms
MISRA Motor Industry Software Reliability Association
ISO International Organization for Standardization
ASIL Automotive Safety Integrity Level
ASAM Association for Standardization of Automation and Measuring Systems
MCD Measuring, Calibration and Diagnostics
HIS Hersteller Initiative Software
QAC Static analysis tool supplied by PRQA Programming Research
Table 1. Acronyms
1.3 Interpretation of Terms
The following rules are observed within this document:
SHALL: expresses a mandatory requirement of this document.

MUST: expresses a mandatory requirement of this document.
SHOULD: expresses a recommendation or advice. It does not express a requirement of this document.
WILL: expresses an intention. It does not express a requirement of this document.
MAY: expresses a permissible practice or action. It does not express a requirement of this document.
1.4 Definitions
Basic type / standard type Native C language types as defined in ISO/IEC 9899:1999 chapter
6.2.5
e.g. there are five standard signed integer types, designated as signed
char, short int, int, long int and long long int.
Code block / compound A block is a compound of one or several statements that begins with
statement ‘{‘ and ends with '}'.
File scope A variable or function that is only visible within one file.
Global scope A variable or function that is visible in more than one file.

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 5 of 40
Keyword Reserved C99 keywords are:

auto double int switch
break else long typedef
case enum register union
char extern restrict unsigned
const float return void
continue for short volatile
default goto signed while
do if sizeof _Bool
inline static _Complex
struct _Imaginary
Module / Component / Following EEPM glossary:

SwComponent
A software component is the smallest entity of the software
architecture with the property of a high inner and loose outer coupling
over a defined interface.
A software component is a collection of one or more software units
which contribute to a clearly defined common functionality.
Software components will be defined in software architecture.
Module / Component / A software component (SwComponent) prefix is a series of letters that

SwComponent prefix are unique for each component – list of allowed prefixes is driven by
Software Architecture definition.
Data type suffix Consists an abbreviation for the associated data type.
Table 2. Definitions
1.5 Conventions in this document

All rules are indicated by the unique identifier, visible at the most left side of the rule / page.
Example: Rule identifier shall not be changed over lifetime of this document.
Rule 000
If rule has to be removed, identifier shall be removed as well, without re-iterating remaining identifiers.
Removed identifiers shall be documented in revision history as well as in chapter 0.
Next available identifier is: Rule 133

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 6 of 40
2 C programming language standard

Rule 001 a) The ISO/IEC 9899:1999 standard (informal name: C99) shall be followed for creation of C-code
[REF-10].
Rule 002 b) The MISRA C:2012 including Amendment 1 shall be followed for creation of C-Code ([REF-11],
details in section 8.1).
Rule 120 c) The SEI CERT-C (revision 2016) shall be followed for creation of C-Code ([REF-03], details in
section 8.2).
Rule 003 d) Dynamic allocation of objects or memory space shall NOT be used.
Rule 004 e) C Standard Input / Output Library (cstdio/stdio.h) shall NOT be used.
Rule 129 f) Designated initialization shall NOT be mixed with standard initialization.
Designated initialization is recommended method as improves code readability and reduces
likelihood of mistakes, however it shall be understood that it might break compatibility with C++
standard (C++20 supports this method in limited way).
Examples:
typedef struct Diag_SensorXType_Tag
{
uint8 Data_u8;
uint32 Crc_u32;
} Diag_SensorXType;
Diag_SensorXType sensorA = {.Data_u8 = 0, .Crc_u32 = 0xFFFFFFFF}; /* OK */

Diag_SensorXType sensorB = {0, 0xFFFFFFFF}; /* OK */
Diag_SensorXType sensorC = {.Data_u8 = 0, 0xFFFFFFFF}; /* NOT OK – MIX not allowed */
2.1 Assembly code with C

Rule 005 a) Any assembly code shall be encapsulated and isolated as function. Assembly code shall NOT be
mixed with C-code as part of one function.
Rule 006 b) For any assembly function justification comment, as part of function description, shall be provided
to explain why it is required.
Note: Simple comment like "due to performance reason" is not sufficient. Full rationale is required,
e.g. how assembly code supports performance and why it is better than C-Code in this case.
3 Naming Conventions
3.1 General Rules
Rule 007 a) The first letter and only the first letter of every word in a function or variable name shall be
uppercase unless it is a local variable (e.g. CounterBuffer, GetCounterBuffer()).
Rule 008 b) In function or variable name: the underscore separator (“_”) shall only be used to separate
SwComponentPrefix or DataTypeSufix – is not allowed to be used for other purposes.
Rule 009 c) Variables and types definition shall not share the same name, regardless if upper or lower case.
Rule 010 d) All the names of functions, variables, constants, macros, defines and comments shall be in
English.
Rule 011 e) For abbreviations of names, the use of upper case and lower case letters for differentiation shall
be used. For example, the 2 abbreviations TEE and SCS combined would be spelled as a variable:
TeeScs_u8
Rule 012 f) Identifiers defined in the same name space shall NOT differ by any combination of:
o the interchange of a lowercase character with its uppercase equivalent

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 7 of 40
o the interchange of the letter "O", and the digit "0"

o the interchange of the letter "I" (uppercase "i"), and the digit "1"
o the interchange of the letter "l" (lowercase "L"), and the digit "1"
o the interchange of the letter "I" (uppercase "i"), and the letter "l" (lowercase "L")
o the interchange of the letter "S", and the digit "5"
o the interchange of the letter "Z", and the digit "2"
o the interchange of the letter "n", and the letter "h"
o the interchange of the letter "B", and the digit "8"
o the interchange of the letter sequence "rn" ("r" followed by "n"), and the letter "m"
3.2 Types
Rule 013 a) Each basic variable type shall be defined using typedef.
Rule 014 b) Custom type names shall be composed like <SwComponentPrefix>_<TypeName>Type.
Rule 015 c) All type definitions that are defined in a header file shall have a SwComponent prefix, except for
the basic types.
Rule 016 d) The following table shows the typedef names that shall be used for all basic variables. These types
are platform dependent and shall be defined in Platform_Types.h:
Basic Variable Type Size AUTOSAR / ZF typedef definition name
8-bit unsigned uint8
8-bit signed sint8
16-bit signed sint16
32-bit float (single precision) float32
64-bit float (double precision) float64
Std_ReturnType (8-bit unsigned; not a

basic type, but used for callback
status indication) Std_ReturnType
E_OK: 0, E_NOT_OK: 1
_Bool (C99 native type which could

bool
hold either “true” or “false” value)
Table 3. Type Definitions

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 8 of 40
Examples:
typedef unsigned char uint8; /* Type definition in header file Platform_Types.h */
typedef signed short sint16; /* Type definition in header file Platform_Types.h */
typedef uint8 Std_ReturnType; /* Type definition in Std_Types.h*/
typedef uint8 SqSoc_SatelitesType; /* Type definition in <SwComponentName.h>*/
3.3 Variables
Rule 017 a) The scope of each variable shall be as limited as possible.
Rule 018 b) Variables which are only used in one code block shall be also declared at the beginning of this
code block.
Rule 019 c) Each variable shall be defined on a separate line.
Rule 020 d) Usage of global variables shall be avoided. For data exchange between functions within a C-unit
local function arguments or file scope static variable is recommended. (ISO26262-6:2018, Table 3
1d).
Rule 021 e) Each instance name shall end with a data type suffix, except:
o instances of self-defined types
o 1 letter local variable used for loop control (i, j, k) – see 3.3.2 0
Rule 022 f) The following table shows the data types suffixes that shall be used for variables:
Data type
Type Definition Example
suffix
uint8 _u8 uint8 value_u8;
sint8 _s8 sint8 value_s8;
float32 _f32 float32 value_f32;
float64 _f64 float64 value_f64;
bool _bo bool value_bo;
array - _a if the type can't be

described or _aX in combination uint8 data_au8[10U];
_a or _aX
with other characters that indicate MyType data_a[10U];
array type
pointer - _p if the type can't be

described or _pX in combination uint8 *data_pu8;
_p or _pX MyType *data_p;
with other characters that indicate
pointer type
array of pointers _ap or _apX uint8 *data_apu8[5U];

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 9 of 40
uint8 data_au8[5U];
pointer to array _pa or _paX uint8 *pointer_pau8 = data_au8;
uint8 (*pointer_pau8)[5U];
function pointer - _pf to be used void (*foo_pf)();
_pf
for function pointer variables foo_pf();
enum _e MyEnumType PortValue_e;

struct
bitfield (1 bit) _b or _bo {
uint32 Val1_b : 1;
uint32 Val2_b15 : 15;
bitfield (X bits) _bX bool Val3_bo : 1;
} MyBitfieldType;
self-defined type (struct or union
No suffix MyType PortValue;
based)
Table 4. Variable Suffixes
3.3.1 Global Variables

Rule 023 a) The name of a global variable (external of file scope) shall start with a SwComponent prefix.
Rule 024 b) Global variables with external scope shall be avoided, since they lead to hidden data paths, bad
maintainability and bad code modularity (ISO26262-6:2011, Table 8 1e) - it is recommended to at
least use data access via Get/Set interfaces instead.
Rule 025 c) Software Components shall not define global data in their header files. If global variables have to
be used, the definition shall take place in the C file and appropriate extern in H file.
Examples:
Purpose / Composition SwComponent Name File Name SwComponent Prefix Interface example
Comm TxPduHandler TxPduHandler.c TxPduHandler_ void TxPduHandler_Main(void)
static uint8 Diag_LoopCounter_u8; /* file scope */

uint8 Diag_MessageCounter_u8; /* global scope - shall be avoided */
3.3.2 Local Variables

Rule 026 a) To prevent shadowing of variables in a wider scope by local scope variables the naming of local
scope variables shall differ from wider scope variables (ISO26262-6:2011, Table 8 1d) - regardless
if upper or lower case.
Rule 027 b) The first letter of a local variable name shall start with lower case.
Rule 028 c) It is recommended to provide descriptive name of loop control variable, however 1 letter names are
allowed and do not require data type suffix (i, j, k).
Examples:
void func()
{
uint8 loopCounter_u8; /* variable with local scope */
uint8 sigComKlemmen_u8; /* variable with local scope */
}

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 10 of 40
/* usage of descriptive names provides clear context of control statements */

for (uint32 messageIdx_u32 = 0; messageIdx_u32 < MESSAGE_COUNT; ++messageIdx_u32)
{
Diag_MessagePayloadValue_au8[messageIdx_u32] = 0;
}
/* no data type suffix for 1 letter loop control variable */

for (uint8 i = 0; i < MAX_RANGE; ++i)
{
Destination_au8[i] = Source_au8[i];
}
3.4 Enums
Rule 029 a) All enum identifiers that are defined in a header file shall have a SwComponent prefix.
Rule 030 b) Enum identifiers shall be written in upper case.
Rule 031 c) Enum identifiers shall have no suffix.
Examples:
typedef enum Diag_CrcDataType_Tag /* Enum type definition */
{
DIAG_CRC,
DIAG_ROM,
DIAG_END
} Diag_CrcDataType; /* enum type with SwComponent prefix */
Diag_CrcDataType Diag_Variable_e; /* Instance of enum type */
enum MyEnum /* Enum that is not a type and not used globally */
{
MONDAY = 1,
TUESDAY
};
3.5 Structures / Unions

Rule 032 a) The names of the elements of a structure / union shall start with an upper case letter.
Rule 033 b) The names of the elements of a structure / union shall NOT include SwComponent prefix.
Rule 034 c) Type names for structures / unions created with typedef shall have the suffix “Type”.
Rule 035 d) An instance of a structure / union shall not have a data type suffix unless it is an array or a pointer.
Rule 036 e) Bitfields within structures and unions are compiler / microprocessor architecture implementation
dependent. They are not recommended to be used due to code portability aspects – however they
are not prohibited.
Rule 037 f) Structure members shall be arranged in order (from largest to smallest) to minimize data padding
/ alignment effect and improve memory utilization.
Examples:
typedef struct BitMaskType_Tag
{
uint32 Val1_b : 1; /* ISO-C standard states that bit-fields */
uint32 Val2_b : 1; /* can only be defined with type int or _Bool: */
uint32 Val3_b14 : 14; /* unsigned int, signed int or _Bool */
} BitMaskType;
Bitfields can have 2 types of 1-bit values. One is a single bit with the meaning of 0 and 1. The other is
a boolean, with values true and false. These are not the same and both have specific use cases.
Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 11 of 40
The single bit is usually used to map registers where the 32 bit value is split into smaller chunks.
The second is used to simply have a boolean value in the bitfield. The data type suffix depends on which
of the 2 case is used:
typedef struct BitMaskType2_Tag
{
uint32 SingleBit_b : 1; /* single bit - assigned values should be 0U or 1U */
bool BooleanValue_bo : 1; /* boolean – assigned values should be true or false */
uint32 LongerValue_b5 : 5; /* 5 bit value */
} BitMaskType2;
BitMaskType Diag_MyBitField; /* global instance */

BitMaskType Diag_BitFieldArray_a[MAX_ELEMENTS]; /* array of BitField Structures */
typedef struct Diag_SensorXType_Tag

{
uint8 Data_u8;
uint8 Status_u8;
} Diag_SensorXType;
typedef struct Diag_ActuatorXType_Tag

{
uint8 OnValue_u8;
uint8 Status_u8;
uint8 OnTime_u8;
} Diag_ActuatorXType;
typedef struct Diag_UnitType_Tag

{
Diag_SensorXType FrontSens; /* nested structure */
Diag_ActuatorXType FrontAct; /* nested structure */
uint8 Index_u8;
} Diag_UnitType;
typedef union Diag_DeviceData_Tag

{
uint32 ActutatorData_u32;
uint8 *ActutatorDataBytes_au8[4];
} Diag_DeviceDataType;
Diag_UnitType Diag_AirBag;
Diag_AirBag.FrontAct.Status_u8 = 1U;
Structure padding example:

Data alignment is implementation dependent (processor architecture, compiler) therefore shall be carefully
analysed to be used in correct way.
Every data type in C will have alignment requirement (mandated by processor architecture, not by
language). Is it driven by desire of achieving optimal performance and to make memory access faster.
Aligning data elements allows the processor to fetch data from memory in an efficient way and thereby
improves performance.
Consider this linked-list on 64-bit ARM architecture:
struct foo10
{
uint8 Speed_u8;
struct foo10 *Next_p;
uint16 Temp_u16;
};

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 12 of 40
Compiler is going to re-layout memory and add empty space of 7 bytes (padding) after speed_u8 (in order
to align address of “next_p” to 8-bytes boundary) and 6 bytes after temp_u16. Memory would be used as
shown below:
struct foo10
{
uint8 Speed_u8; /* 1 byte */
uint8 Pad1_u8[7]; /* 7 bytes */
struct foo10 *Next_p; /* 8 bytes */
uint16 Temp_u16; /* 2 bytes */
uint8 Pad2_u8[6]; /* 6 bytes */
};
That’s 24 bytes. If we reorder by size, we get this:

struct foo11
{
struct foo11 *Next_p;
uint16 Temp_u16;
uint8 Speed_u8;
};
Considering self-alignment, we see that none of the data fields need padding. This is because the stride
address for a (longer) field with stricter alignment is always a validly-aligned start address for a (shorter)
field with less strict requirements. All the repacked struct actually requires is trailing padding:
struct foo11
{
struct foo11 *Next_p; /* 8 bytes */
uint16 Temp_u16; /* 2 bytes */
uint8 Speed_u8; /* 1 byte */
uint8 Pad_u8[5]; /* 5 bytes */
};
3.6 Functions
Rule 038 a) The name of a function shall start with a SwComponent prefix (excluding static inline functions).
Rule 039 b) Type names for function pointers created with typedef shall have the suffix “Type”.
Examples:
File Name Purpose SwComponent Prefix
Diag_DiagHandler.c Diagnostics Diag_
uint8 Diag_DummyFunction(void); /* Function with global scope */

static uint8 Diag_GetDummyValue(void); /* Function with file scope */
static inline uint8 GetRoot(unit8); /* Inline function with file scope no prefix */
typedef uint8 (*funcType)(void); /* Typedef for function pointer */
funcType foo = NULL;
Rule 040 c) For the exchange of data between C-units (C-files) function calls shall be used (ISO26262-6:2018,
Table 3 1e).
Examples:
void TempSens_SetRawValue(sint16 rawTemp_s16); /* set the temperature raw value */
sint16 TempSens_GetTemp(void); /* get the result */

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 13 of 40
3.7 Pointers
Rule 041 a) Pointers (including pointers to function) are considered unsafe and should be avoided (ISO26262-
6:2011, Table 8 1f).
Rule 042 b) Pointers shall be declared with a space character between the type and the asterix (“*”) symbol
and no space between the “*” symbol and the variable name.
Rule 043 c) If there is another keyword (e.g. const) that follows the “*” symbol, there shall be no space between
the “*” symbol and the keyword.
Examples:
uint8 *hold_pu8 = NULL; /* Pointer to U8 variable */
const uint8 *numberOfAsics_pu8 = NULL; /* Pointer to U8 variable that is constant */
uint8 *const configuration_pu8 = NULL; /* Constant pointer to U8 variable */
const uint8 *const crc_pu8 = NULL; /* Constant pointer to U8 variable that is
constant */
static const uint8 *const buffer_pu8 = NULL; /* Constant pointer to static U8 variable
that is constant */
3.8 Constants
Rule 044 a) Suffix “U”, “UL”, and “ULL” for unsigned integer constants shall be written in upper case.
Rule 045 b) Suffix “L” and “LL” for long (long) integer constants shall be written in upper case.
Rule 046 c) Suffix “F” for single precision float constants shall be written in upper case.
Rule 047 d) Start hexadecimal numbers with 0x followed by digits (0…9) or uppercase letters (A…F).
Rule 048 e) Hexadecimal numbers shall be preceded with 0 to have length of multiple of 2 (e.g. 0x01 not 0x1)
Rule 049 f) Floating point numbers shall have at least one number on each side of the decimal point.
Rule 050 g) Floating point numbers represented with exponent format shall use upper case “E” as exponent-
part.
Rule 051 h) Use numeral system (dec or hex) which suits the most for represented value, hex is not always the
best option.
Examples:
var1_u8 = 070U; /* NOT OK: Octal is not allowed by MISRA */
var2_u8 = 70U; /* OK: decimal 70 */
var3_f32 = 5.0F; /* OK: one number on each side of the decimal point */
var4_f32 = 123E-2F; /* OK: floating 1.23 */
elapsedSeconds_u32 = 0x0BCDU; /* NOT OK: Decimal would be better for seconds */
3.9 Defines / Macros

Rule 052 a) Definitions with #define shall be all upper case letters.
Rule 053 b) #define shall start with a SwComponent prefix.
Rule 054 c) Several words in a #define definition shall be separated with a “_”.
Rule 055 d) A #define shall not completely spell out a numeric value.
Rule 056 e) All macro definitions shall be written without ";" at the end of the definition.
Rule 057 f) Brackets (“(“ and “)”) shall not be used when not required, especially for numbers.
Rule 058 g) A #define shall not be used to hide partial code elements like: for, while, switch.
Rule 059 h) Function-like macro shall be avoided as it bypass type safety and impacts debugging process.
Rule 060 i) If function-like macro have to be used (there is VERY specific reason related with improvement of
speed/CPU usage/readability), detailed justification (in form of a code comments) shall be provided.
Rule 061 j) A #define shall not be used to hide any kind of data types or their objects (e.g. to rename variables,
structures, unions).

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 14 of 40
Examples:
#define DIAG_THREE_HUNDRED (300U) /* NOT OK: spells out numeric; brackets */
#define DIAG_TEMP_OFFSET 300U /* OK: no semicolon at the end as well */
#define DIAG_CURRENT_STATE Diag_DiagnosticState_u8 /* NOT OK: macro hide an object */

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 15 of 40
4 Layout
4.1 General Rules
Rule 062 a) All files shall follow the outline as defined by Templates (REF-01)
Rule 063 b) There shall be only one coding statement per line.
4.2 Line Rules

Rule 064 a) Blank lines shall be used to separate groups of declarations and statements in a function
(“paragraphing”).
Rule 065 b) A string of conditional operators that does not fit on one line shall be broken up over several lines,
breaking before the logical operators.
Rule 066 c) Length of line should be no more than 160 characters.
Examples:
/* Split a string of conditionals before logical operators */
if ((TotalCount_u16 < Needed_u16)
&& (Needed_u16 <= MAX_ALLOT)
&& (NULL == p->Next_p))
{
}
4.3 Code Blocks

Rule 067 a) A curly brace (“{“ or “}”) shall have no other characters in the same line, except for “\” or comments
or in structure definitions.
Rule 068 b) There shall be no tabs.
Rule 069 c) Each indentation shall have 4 space characters.
Rule 070 d) An empty block shall contain a semicolon.
Examples:
for (uint8 i = 0; i < LOOP_COUNT; ++i) /* Proper use of brackets and indentation */
{
if ((MyStruct_a[i].Voltage_u8 == ArgValue_u8)
&& ((MyStruct_a[i].DataFlag_b & ArgFlag_b) != 0))
{
ret_u8 = MyStruct_a[i].Counter_u8;
}
} /* comment this block */
for (uint8 i = var_u8; i > MAX_SIZE; ++i) /* Example of an empty block */

{
; /* do nothing */
}
4.4 Condition Statements

Rule 071 a) Positive logic should be preferred over negative logic of conditions.
Rule 072 b) Constant shall be placed on left side of comparison operator (“==”).
Rule 073 c) In case of any other condition operator (e.g. “>”, “<”, “!=”) constant shall be placed on right side.
Examples:
if (DIAG_TIMEOUT == timerCounter_u8) /* OK */
if (timerCounter_u8 == DIAG_TIMEOUT) /* NOT OK – constant on right side */
if (timerCounter_u8 >= DIAG_TIMEOUT) /* OK */

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 16 of 40
4.5 Switch Statements

Rule 074 a) All fall-through statements shall be commented.
Rule 075 b) A default statement shall always be used.
Rule 076 c) Each case block should be as small as possible for readability and maintainability reasons.
Consider calling an function instead of control or data flow coded directly inside of case block.
Examples:
switch (AxesColor_u8)
{
case GRAY: /* comment is necessary for this fall-through statement */
case BLACK:
Color_u8 = BLACK;
break;
case YELLOW:
Color_u8 = YELLOW;
break;
case RED:
Color_u8 = RED;
break;
default:
ErrorHandling(); /* prefer function call over extensive code in case block */
break;
}
4.6 Spaces
Rule 077 a) There shall be one space character between a keyword and an opening parenthesis.
Rule 078 b) There shall be one space character after each comma and semicolon within an expression.
Rule 079 c) Unary operators shall be written with no spaces between them and their operands (e.g. “n_u8++”,
”&n_u8”).
Rule 080 d) All non-unary assignment, arithmetic, logical and bitwise operators shall have one space before
and after them (e.g. “=”, “+”, “==”, “>>”).
Rule 081 e) The following operators shall have one space before and after them: “?”, “:” (conditional
expression).
Rule 082 f) The primary operators: -› , . , and [ ] shall not have spaces around them.
Rule 083 g) There shall be no space before an opening parenthesis following a function name.
Rule 084 h) There shall be no spaces between the parenthesis and an expression within the parenthesis.
Rule 085 i) There shall be no space between a cast and its operand.
Rule 086 j) Space rules could be ignored if would lead to worse readability of code (e.g. multiple lines of
variables initialization could adjust assignment operator “=”)
Examples:
if (Var1_u8 == Var2_u8) /* Spacing after “if” and around the non-unary operator “==” */
{
Function(Var1_u8, Var2_u8, Var3_u8); /* No space after function name. Space after comma */
Var4_u8++; /* Unary operator written without a space */
}
Var1_u8 = Var2_u8 + Var3_u8; /* Spacing before and after operator “=” and “+” */
(uint16)MyStruct_a[Var3_u8].Variable1_u8; /* No spaces here */

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 17 of 40
4.7 Parenthesis
Rule 087 a) The objects of sizeof operator shall always have parenthesis around them.
Rule 088 b) The objects of return statement shall NOT have parenthesis around them.
Examples:
uint8 func()
{
uint8 size_u8 = sizeof(uint8); /* OK: sizeof always with brackets */
uint8 size_u8 = sizeof uint8; /* NOT OK: lack of brackets is not acceptable */
return (size_u8); /* NOT OK: unnecessary brackets on return stmt. */

return size_u8; /* OK: no brackets on return statement */
}
4.8 Local variables

Rule 089 a) Local variables should only be defined at the beginning of a code block.
Rule 090 b) for-loop control variables shall be defined inside “for” statement (scope limitation see 3.3)
Examples:
void func()
{
uint8 localA_u8; /* Variable defined at the beginning of the block */
...
{
uint8 localB_u8; /* Variable defined at beginning of block */
... /* without control expression */
for (uint8 i = 0; i < RANGE_LIMIT; ++i)
{
...
}
}
...
}
4.9 Temporary Code Blocks

Temporary code blocks are related with changes intended to be reverted (not reworked) in defined future
(e.g. within next 2 releases). In order to increase visibility, awareness and ensure automated rollback
deadline detection for such changes, following rules shall be followed.
4.9.1 Based on temporary requirements or request
Applicability scope:
- Any code change implemented based on software requirements or request with limited scope of
release applicability.
- Any code change implemented as temporary interim containment (e.g. disable feature for one
release as issue mitigation).
For more details please see Work Instruction [REF-17].
Rule 121 a) Each temporary code block shall be enclosed between special markers / comments:
/*!--- TEMP_START: <REQUEST_CM_ITEM_ID> / RevertBy: <REVERT_CM_ITEM_ID> ---!*/
<newly introduced or modified code, to be reverted by agreed timeline>
/*!--- TEMP_END: <REQUEST_CM_ITEM_ID> / RevertBy: <REVERT_CM_ITEM_ID> ---!*/

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 18 of 40
where:
<REQUEST_CM_ITEM_ID>: Change Management (CM) item reference, which request
temporary implementation. Format shall include CM tool
name.
<REVERT_CM_ITEM_ID>: Change Management (CM) item reference, which will be
used to revert the changes (to be agreed with Project
Management). Using this item, CI system will monitor
revert deadline. Format shall include CM tool name.
Example:
/*!--- TEMP_START: PTC_123456789 / RevertBy: PTC_987654321 ---!*/
/* customer requested to disable failsafe detection for fault injection tests */

#define MODEMANAGER_FAILSAFE STD_OFF
/*!--- TEMP_END: PTC_123456789 / RevertBy: PTC_987654321 ---!*/
4.9.2 Related with bug-fixing of supplier code

Applicability scope:
- Any code implemented based on issue identified in supplier code, which will be reverted in defined
future (e.g. certain ZF delivery, after supplier fix integration). For more details please see Work
Instruction [REF-16].
Rule 122 a) Each supplier bug-fix code block shall be enclosed between special markers / comments:
/*!--- PATCH_START: <REQUEST_CM_ITEM_ID> / RevertBy: <REVERT_CM_ITEM_ID> ---!*/
<newly introduced or modified code, to be reverted by agreed timeline>
/*!--- PATCH_END: <REQUEST_CM_ITEM_ID> / RevertBy: <REVERT_CM_ITEM_ID> ---!*/
where:
<REQUEST_CM_ITEM_ID>: Change Management item reference, which request
temporary implementation. Format shall include CM tool
name.
<REVERT_CM_ITEM_ID>: Change Management item reference, which will be used to
revert the changes (to be agreed with Project
Management). Using this item, CI system will monitor
revert deadline. Format shall include CM tool name.
Example:
/*!--- PATCH_START: PTC_123456789 / RevertBy: PTC_987654321 ---!*/
/* supplier definition was off-by-one; causing unavailability of last HW channel */

#define ECAN_MAX_CHANNELS 6U
/*!--- PATCH_END: PTC_123456789 / RevertBy: PTC_987654321 ---!*/
4.10 Engineering Code Blocks

a) It is allowed to introduce special engineering code into repository during development phase.
b) Engineering code must fall into one of the following categories:
o Debug Code – all code, which makes debugging easier or possible. May cover
implementation like:
Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 19 of 40
Watchdog reset disabling – for breakpoint usage purpose, to avoid side effects in
▪
case of debugger command
▪ Code to send debug information on bus (e.g. CAN, SPI, UART)
▪ Logging additional information about program or data flow
o Test Code – all code, which makes testing easier or possible. May cover implementation
like:
▪ Fault injections to test fault handling functionality
▪ Program control flow changes / flow enforcement
Rule 123 c) Each part of code that meets the criteria of the above categories shall be qualified as engineering
code to which all described by this chapter rules must be applied.
Rule 124 d) Each engineering code block shall be enclosed by preprocessor directives as follow:
#ifdef <EngineeringBlockIdentifier>
#warning This part of code is intended to be disabled for release
…
/* engineering code block */
…
#endif
where:
<EngineeringBlockIdentifier>: <CategorySpecificTag>_<SwComponentPrefix>
<CategorySpecificTag>: ‘TEST’ or ‘DEBUG’ depends on block category.

Rule 125 e) By default, all engineering code blocks shall remain disabled.
Placing #define EngineeringBlockIdentifier directive directly in source code is forbidden.
f) To enable specific engineering block group an explicit EngineeringBlockIdentifier definition shall

Rule 126
be applied only as part of the compiler option (in most of compilers this is accomplished with
usage of “-D” option).
Examples:
#ifdef TEST_MESP
<code>
#endif
#ifdef DEBUG_ANALOGINPUT
<code>
#endif

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 20 of 40
5 Documenting the code

5.1 General Rules
Rule 091 a) The variables, functions etc. names shall be self-explaining.
Rule 092 b) Comments shall be in English.
Rule 093 c) Comments shall not paraphrase the code (e.g. /* Assign Value1 plus Value2 to Value3 */).
Rule 094 d) C (/* */) and C++ (“//”) style commenting may be used.
Rule 095 e) See template files for comment examples ([REF-01]).
Rule 096 f) Use doxygen conventions for standard and side comments. See [REF-02]
Rule 097 g) Provide code comments for each function.
Rule 098 h) Provide code comments in function body where meaningful (e.g. code is not self-explanatory).
Consider it especially for decision points (e.g. if-else, for, switch, while).
Rule 099 i) Code shall never be commented out, even temporarily.
Examples:
#if 0 /* NOT OK: code shall never be commented out */
void func()
{
/* if (Diag_LogErrors_bo) */ /* NOT OK: code shall never be commented out */
{
...
}
...
}
#endif
5.2 Used Doxygen Tags

Rule 100 Doxygen tool provides a lot of tags which could be used. Following tags shall be used to provide basic
descriptions of interfaces / functions:
@details description, don't copy name here!
@brief used only for side comments
@param[in] x details of parameter x
@param[out] y details of parameter y
@param[in,out] z details of parameter z
@return possible return value
5.3 Doxygen Extensions at ZF

Rule 101 Additionally we prepared a set of own tags that should be used for documenting variables:
@MAX a max value
@MIN a min value. As alternative you can put a range.
@UNIT the unit
@RESOLUTION proper resolution
@OFFSET the offset value
@REQ req_id low level requirement (optional)
5.4 Standard comments

Rule 102 a) Standard comments for shall be included above the function declaration in a H-file (see [REF-01]).
Rule 103 b) A block comment shall be used when describing the element.
Rule 104 c) Use @details
d) See template files for comment examples (REF-01).

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 21 of 40
Examples:
/**
* @details description, don't copy name here!
* @param[in] arg1_s8 describe here what is the argument for, range, etc.
* @return explain the return information
*/
uint8 Component_RadarValid(const sint8 arg1_s8);
/**
* @details local variable description
* @MAX a max value
* @MIN a min value
* @UNIT the unit
* @RESOLUTION proper resolution
* @OFFSET the offset value
*/
static uint8 Component_TempData_u8;
5.5 Side comments

Rule 105 a) Short comments should be written on the same line as the code or data definition that they describe.
Rule 106 b) Spaces shall be used to move a comment to the right in order to separate it from the code.
Rule 107 c) Use @brief
d) See template files for comment examples (REF-01).
Examples:
/**
* @details description, don't copy name here!
* whenever possible group defines into enum when they have a meaning together
*/
typedef enum Component_QualityType_Tag
{
COMPONENT_SIGNAL_BAD = 0, /** @brief short description */
COMPONENT_SIGNAL_GOOD /** @brief short description */
} Component_QualityType;
5.6 Inline Comments

a) These are easy comments to document implementation.
b) Only comments in style /* .. */ are expected (see Rule 094).
Rule 108 c) An inline comment shall be lined up with the code that it describes.
Examples:
while (EOF != var1_u8)
{
/* This is an example of an inline comment */
Function2(var1_u8);
Var1_u8 = Function1();
}
5.7 Comments after implementation

Rule 109 a) If a code block is large (more than 40 lines) or there are several nested blocks, closing braces shall
be commented to indicate which block they delimit.
Examples:
if (speed_u8 < SPEED_LIMIT)
{
/* very large code block */
} /* speed below limit */

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 22 of 40
if (var1_u8 == var2_u8)
{
/* very large code block */
} /* (var1_u8 == var2_u8) */
5.8 TODO Comments

a) TODO - special tag, placed as a comment inside a source code. It describes either field for
improvement, taken assumption or missing implementation with justification.
Rule 127 b) While creating TODO comment following rules have to be followed:
o Change Management item has to be created and it’s ID has to be added to the comment.
o Description has to be: unambiguous, complete and consistent with surrounding code.
o This field cannot be used to justify bad solutions or errors.
o This is not a place for a discussion.
o TODO documentation in the source code shall have the following format:
/* TODO: <Summary>; <FOLLOWUP_CM_ITEM_ID>

* <Description>
*/
where:
<Summary> Short, one sentence, summary of TODO item (displayed by IDE).
<FOLLOWUP_CM_ITEM_ID> Change Management (CM) item reference, which will be used to track
required effort and actions (e.g. assumption clarification). Format shall
include CM tool name.
<Description> Optional description of the related topic
Rule 128 c) FIXME and other similar tags are not allowed to be used.
Examples:
else if ((END_OF_SPEED_LIMIT == speed_value_u8)
|| (END_OF_ALL_RESTRICTIONS == speed_value_u8))
{
/* TODO: Clarify end of speed case for age_dist; PTC_4502722
* Case not clearly defined in the input requirement: SwRS_12345.
* This shall be clarified, for now the SL005_050 value is safe fallback solution.
*/
age_dist_u8 = TSM_AlgCal.AgeDist_SL005_050_u8;
}
5.9 Commenting QAC Violations

a) Coding Standards How To (e.g. MISRA-C, CERT-C, HIS metrics) is defined by [REF-03]
b) Process of justifying QAC violation or deviation is defined by [REF-07]
Rule 110 c) A comment to describe a violation to a QAC rule shall be placed on the line right before the violation.
Rule 111 d) Documentation of violation in the source code shall have the following format:
Specific deviations will be suppressed in the code using the following syntax:
For MISRA Required, MISRA Mandatory or CERT-C Rules related QAC messages:
Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 23 of 40
/* QAC_DEVIATION: <Deviation Number>

DESCRIPTION: <Message description>
JUSTIFICATION: <Deviation Reason>
SAFETY JUSTIFICATION: <individual safety justification if required for deviation request>
*/
/* QAC CCB APPROVED */ /* PRQA S <message number> [<lines>]*/
For MISRA Advisory or CERT-C Recommendation related QAC messages:

/* QAC_DEVIATION: N/A
DESCRIPTION: <Message description>
SAFETY JUSTIFICATION: <individual safety justification if required for deviation request>
*/
/* QAC CCB NOT REQUIRED */ /* PRQA S <message number> [<lines>]*/
Where:
<Deviation Number>: Change Request(s) ID of the used type of violation; could be “N/A” for MISRA
Advisory or CERT-C Recommendation related messages (see [REF-03]).
<Message description>: Short description of rule (e.g. QAC message text), preceded by Coding Standard
rule ID (e.g. MISRA or CERT-C) – this field could be multiline, especially when many rules are violated by
single code line
<Deviation Reason>: Reason / Justification for this violation; needs to also explain risk of violation – this
field could be multiline, especially when many rules are being violated by single code line
<Safety Justification>: Justification how safety is insured (this line should be left out completely if
an individual safety justification is not requested for the deviation request) – this filed could be multiline
“QAC CCB APPROVED”: Serve for easy identification that this justification had been approved by process
(see 4.8 a) – required for MISRA Required, MISRA Mandatory or CERT-C Rules related messages (see
[REF-03])
PRQA: QAC key word
S: QAC suppression command
<message number>: QAC message(s) number to suppress
<lines>: Number of physical lines to be suppressed
Examples:
/* QAC_DEVIATION: N/A
DESCRIPTION: MISRA 11.4: Cast between a pointer to volatile object and an integral type.
JUSTIFICATION: Conversion is required to get an access to memory mapped registers which are
not accessible with standard MCAL interfaces.
*/
/* QAC CCB NOT REQUIRED */ /* PRQA S 0303 1 */
volatile uint8 *regAdc_pu8 = (volatile uint8 *)ADC_REG_ADDR;
Many MISRA violated by 1 line

/* QAC_DEVIATION: 20016
DESCRIPTION: MISRA 11.4: Cast between a pointer to object and integral type.
MISRA 11.6: Casting to different object pointer type.
JUSTIFICATION: Conversion is required to perform LMU.DP test as described in AURIX Safety
Manual
*/
/* QAC CCB APPROVED */ /* PRQA S 0303, 0306 1 */
5.10 Commenting compiler warning

Rule 112 a) All compiler warnings shall be resolved, only when it is not possible and impact had been evaluated
justification shall be provided.
Rule 113 b) A comment to describe a justification of unresolved compiler warning shall be placed on the line
right before the warning source.

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 24 of 40
Rule 114 c) Documentation of justification in the source code shall have the following format:
/* COMPILER DEVIATION: <Message Number>

DESCRIPTION: <Message Description>
*/
Where:
<Message Number>: Compiler warning ID (defined by compiler e.g. “etoa:5387”, “ctc W549”)
<Message description>: Short description of warning (e.g. raised as compilation message / log)
<Deviation Reason>: Reason for this violation
Examples:
while (1)
{
;
}
/* COMPILER DEVIATION: etoa:4111
DESCRIPTION: statement is unreachable
JUSTIFICATION: prototype of API is forced by AUTOSAR specification and requires
return value; however architectural intention of this function is to do nothing if
reached
*/
return OS_E_PANIC;
5.11 Commenting Polyspace Violations

a) If a macro expands to multiple lines, use the syntax for code sections even though the macro itself
covers one line. The single-line syntax applies only to results that appear in the first line of the
expanded macro.
Rule 115 b) Each Polyspace markup comment shall be single line, otherwise Polyspace will not parse it properly.
To ease reading use word wrap option in source code editor.
Rule 116 c) Use colon (“:”) to separate fields of the Polyspace markup.
Rule 117 d) The order of the markups shall be exactly as visible in this document.
Rule 118 e) Don’t use white characters other than space
Rule 119 f) The documentation of violation in the source code shall have following format:
- For single line of code – add the following text directly before the line containing violation you want
to justify:
/* polyspace<RTE:Kind1[,Kind2]:[Severity]:[Status]> [CCB indication] : [CR No.] : [Justification
comment] */
- For multiple lines of code:

/* polyspace:begin<RTE:Kind1[,Kind2]:[Severity]:[Status]> [CCB indication] : [CR No.] :
[Justification comment] */
... Code section ...
/* polyspace:end<RTE:Kind1[,Kind2]:[Severity]:[Status]> */
g) Replace the key word (Kind1, Severity, etc.) with valued indicated in table below:
Replace Replace with
Kind1, Kind2,…, Kind[n] Use acronyms from the list. Multiple checks can be separated by comma
(i.e.: COR, ZDV).
Acronym Description
ABS_ADDR Absolute address usage

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 25 of 40
COR Correctness condition
ZDV Division by zero
FNC Function not called
FNR Function not reachable
FRV Function not returning value
IDP Illegally dereferenced pointer
OOP Incorrect object oriented programming
CPP Invalid C++ specific operations
INVALID_FLOAT_OP Invalid operation on floats
SHF Invalid shift operations
STD_LIB Invalid use of standard library routine
NIVL Non-initialized local variable
NIP Non-initialized pointer
NIV Non-initialized variable
NTC Non-terminating call
NTL Non-terminating loop
NNT Null this-pointer calling method
OBAI Out of bounds array index
OVFL Overflow
IRV Return value not initialized
SUBNORMAL Subnormal float
EXC Uncaught exception
UNR Unreachable code
ASRT User assertion
For detailed description see Polyspace documentation (Acronyms for

Checks and Code Metrics)
Severity Text that indicates how critical you consider the defect. Enter one of the
following severity:
- Low (the violation that does not impact the functionality of the SW
Component containing it)
- Not a defect (the violation that you are sure that it’s not a defect and
you have proven it)
This text populates the Severity column on the Results List pane.
Status Text that indicates that the violation had been analysed and justified

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 26 of 40
- Justified (the only possible value; required due to tool expectation)
This text populates the Status column on the Results List pane.
CCB Indication In case Polyspace CCB flow was required (red finding) and justification had
been approved use:
- CCB APPROVED
In case Polyspace CCB flow was not required (orange and gray findings)
use:
- CCB NOT REQ
CR No. The number of change request created in PTC Integrity for CCB approval or
“N/A” in case Polyspace CCB process was not required.
Justification reason Any text containing the justification described in details. Why it can’t be
fixed. Why it is not risk to justify it.
Table 5. Polyspace justification keywords

Examples:
uint8 Acm_GetMessageId(uint8 arrayIdx_u8)
{
uint8 messageId_u8;
if (arrayIdx_u8 < ACM_TOTAL_NUM_OF_CODING_MSG)

{
messageId_u8 = ACM_CODING_MESSAGE_DESCRIPTOR[arrayIdx_u8];
}
/* polyspace<RTE:UNR:Not a defect:Justified> CCB NOT REQ : N/A : This is false positive.
Proven by unit tests */
else
{
messageId_u8 = 0U;
}
return messageId_u8;
}
(void)Psm_GetVoltage(PSH_IGNP, &(kl15_local_voltage_mV));
/* polyspace:begin<RTE:ZDV:Low:Justified> CCB APPROVED : 155364 : The

obj_kl30kl15_related_data_t.kl30_sense_divider field can't equal 0 */
... Code section ...
/* polyspace:end<RTE:ZDV:Low:Justified> */

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 27 of 40
6 Design Guidelines
This section provides additional guidelines, which shall be considered during C-code development.
6.1 MISRA based guidelines
Additional guidelines based on MISRA Coding Standard Directives and Rules, which cannot be enforced
by static code analysis, therefore have to be enforced by review of the code against the C-Coding Standard.
Rule 130 a) If function returns error information, then that error information shall be tested.
Rule 131
b) Functions which are designed to provide operations on a resource (e.g. semaphore) shall be called
in appropriate sequence (e.g. “obtain” first then “release” the semaphore).
Rule 132 c) Every loop on an external condition shall be protected with a timeout detection (e.g. waiting for
hardware signal/resource).
7 Supportive Guidelines
This section provides additional guidelines, which shall be considered during C-code development, but are
not definitive rules, as usually depends on context and actual use cases in project.
7.1 Defensive and secure programming

Defensive and secure programming methods are supporting functional safety and cybersecurity aspects of
product. They are recommended for ASIL-B and highly recommended for ASIL-D software component code
(ISO 26262-6:2018 Table 1).
The goal of defensive programming is to ensure a defined behaviour of the software even in unexpected
conditions. The secure programming is the subset of defensive programming methods. It aims is to reduce
the possibility of misusing the software in order to reveal bugs, which could be exploited maliciously (reduce
attack surfaces).
To carry this out as many prerequisites, forming the basis for executing a software part, as possible are
checked before the actual task at hand is fulfilled. On top of prerequisites checks, there shall be
implemented other measures (non-exhaustive list) to make sure:
- No side effects leaks information
- Proper execution order
- Execution resources are within limits (time, memory)
In “design by contract”, contracts are defined between collaborators and C code is created under the
assumption that the collaborators honour their contracts.
In defensive and secure programming, C code shall be created with the assumption that
collaborators violate their contracts:
a) Check and sanitize your inputs with allow lists (against expected, allowed values);
b) Check and sanitize data provided / passed to external library functions;
c) Functions shall explicitly indicate error in input data;
d) Standardize error handling on your code (based on software architecture agreement / guidelines);
e) Make sure strings are properly terminated;
f) Always properly initialize your variables;
g) Understand floating point precision;
h) Prevent integer overflow or underflow;
i) Understand integer conversion rules [REF-14];
j) Always enclose header files in an include guard;

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 28 of 40
k) Make sure buffers can fit data you put into them (buffer overflow prevention) – make use of
bounds checking interfaces (e.g.: memcpy_s(), see C11 Annex K);
l) Make sure any code that deals with secret execute in constant time (assembly level);
m) Don’t implement cryptography by yourself, use well proven libraries;
n) Don’t use deprecated or broken algorithms for crypto primitives, e.g.: at least SHA2 for hash,
AES with 128-bit key, etc.;
o) Use True Random Number generator as entropy source;
p) For dealing with secrets use dedicated functions, e.g.: constant time comparison function, secure
memory clear;
q) Use HSM if available;
r) Use microcontroller trap and exception mechanism, for some level of error handling, if available.
More details on could be found in https://github.com/veorq/cryptocoding
Protect your program from invalid inputs

Trust model of the software shall be defined (by software architecture design) and then trust boundaries
shall be enforced (e.g. during code review):
a) Check the values of all data from external sources (e.g. external library or communication bus)
b) Check the values of all input parameters
c) Decide how to handle bad inputs
Example (only) of trust boundaries, which might outcome from trust model definition:
1. Don’t trust data coming from “outside world” (e.g. CAN frames), verify against expected values.
2. Don’t trust data coming from 3rd party code (e.g. AUTOSAR), verify against expected values.
3. Invoked ZF code trusts invoking ZF code (cascading trust).
4. Data shall be validated at interface level (as soon ZF developed code is executed).
5. Pointers shall be verified against NULL value (however there are still many incorrect values, which
lead to abnormal program execution, e.g. 0xFFFF_FFFF or memory corruption)
6. If during runtime global pointer from ZF code can take NULL (or any other incorrect) value, then it
also needs to be re-verified before being used (“cascading trust”; does not apply in this case).
Those trust boundaries shall are always project specific and shall be defined by software
architecture.
Possible error handling techniques

a) Return a neutral value
b) Substitute the next piece of valid data
c) Return the same as the previous
d) Substitute the closest legal value
e) Log a warning / fault
f) Return an error code
g) Handle the error in whatever way works best locally
h) Call an error-processing routine / object
i) Degradation / shutdown procedure

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 29 of 40
Exceptions
a) Protect your program to contain the damage caused by errors
b) Protect by memory, area, RAM, ROM separation
Please ensure that chosen error handling technique or protection mechanism as well as trust
boundaries are aligned with software architecture definition / guidelines.
In case trust boundaries are not provided in the project, ask project management or direct supervisor for
guidance.
8 Adherence External Standards

8.1 MISRA C guidelines
The MISRA C guidelines (2012 revision incl. Amendment 1) shall followed for C-Code creation and checked
using the PRQA QA Framework (QA-C) tool and by code review process.
MISRA compliance matrix document [REF-08] provides detailed guideline on rules enforcement. Rules are
either enforced with usage of QA-C tool or by code review process against rules defined in this document.
The standard configuration of QA-C tool will be located in the project template (see [REF-06]). Referenced
tool project template already enforces rule set defined by process metric “MISRA compliance” [REF-08].
8.1.1 Third party software

ZF expects all Third Party software to comply with all MISRA C 2012 rules.
The ZF supplier monitoring processes are responsible for ensuring third party supplier compliance to this
rule set and are responsible for approving deviations to this rule set.
8.2 CERT-C guidelines

The SEI CERT-C guidelines (2016 edition) shall be followed for C-Code creation and checked using the
PRQA QA Framework (QA-C) tool and by code review process.
CERT-C compliance matrix document [REF-15] provides detailed guideline on rules enforcement. Rules
are either enforced with usage of QA-C tool or by code review process against rules defined in this
document.
The standard configuration of QA-C tool will be located in the project template (see [REF-06]). Referenced
tool project template already enforces rule set defined by process metric “CERT-C compliance” [REF-15].
8.3 HIS metrics

The HIS metrics shall be applied and checked using the QAC tool. The standard tool configuration (see
[REF-06]) provides HIS metrics thresholds defined by process metric “HIS metrics compliance” [REF-09].
See [REF-03] for further information including the definition of these metrics.
8.4 ISO 26262

See [REF-04] for information.

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 30 of 40
The following tables show how we address the topic of coding guidelines as discussed in this standard.
ISO26262 Part 6:2018(E) Compliance
Section 5.4.3 – Table 1 – Topics to be covered by modelling and coding guidelines
1a Enforcement of low complexity HIS code metrics are applied and checked by QAC
1b Use of language subsets MISRA C rules are applied and checked by QAC
1c Enforcement of strong typing See in this document: Error! Reference source not found.
MISRA C rules are applied and checked by QAC
Polyspace code prover analysis (implicit casting and pointer issues)
1d Use of defensive implementation techniques See chapter Error! Reference source not found.
MISRA C 2012 rules are partially support defensive programming aspects

(2.1, 15.7, 16.4, 16.5)
1e Use of well-trusted design principles This topic is in relation to design guidelines rather than coding guidelines
and so is not addressed directly here.
1f Use of unambiguous graphical representation N/A for C language
1g Use of style guides See in this document: Layout and Error! Reference source not found.
1h Use on naming conventions See in this document: Error! Reference source not found.
1i Concurrency aspects This topic is in relation to design guidelines rather than coding guidelines
and so is not addressed directly here.
Section 8.4.5 – Table 6 – Design principles for software unit design and implementation
1a One entry and one exit point in subprograms and Supported by MISRA C rules analysis (15.5)
functions
1b No dynamic objects or variables, or else online test Section 2

during their creation
Supported by MISRA C rules analysis (21.3)
1c Initialization of variables Supported by MISRA C rules analysis (2.2)
Polyspace code prover analysis (detect of non-initialized or unused global

and local variables)
1d No multiple use of variable names Supported by MISRA C rules analysis (5.3)
1e Avoid global variables or else justify their usage Section 3.3.1 and 3.6
1f Restricted use of pointers Section 3.7
Supported by MISRA C rules analysis (8.13, 11.1-11.8, 18.1-6)
1g No implicit type conversions Supported by MISRA C rules analysis (11.1 - 11.8)
1h No hidden data flow or control flow Supported by MISRA C rules analysis (5.3)
1i No unconditional jumps Supported by MISRA C rules analysis (15.1 – 15.3)
1j No recursions Supported by MISRA C rules analysis (17.2)
Section 9.4.2 – Table 7 – Methods for software unit verification
1a Walk-through Code review process
1b Pair-programming Not being used.
1c Inspection Code review process
1d Semi-formal verification Not being used.
1e Formal verification Not being used.

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 31 of 40
1f Control flow analysis QA-C and Polyspace Code Prover
Checks for control flow anomalies such as non-terminating loops, non-

terminating calls or unreachable code. Check via formal verification and
semantic code analysis.
1g Data flow analysis QA-C and Polyspace Code Prover
Checks for control flow anomalies such as non-terminating loops, non-

terminating calls or unreachable code. Check via formal verification and
semantic code analysis.
1h Static code analysis QA-C and Polyspace analysis
1i Static analyses based on abstract interpretation Not being used.
1j – 1n Tests methods Addressed by Software Level Test plan [REF-13]
Table 6. ISO 26262 compliance mapping
8.5 AUTOSAR
See [REF-05] for further information.
8.6 Customer requirements

Customer specific requirements defining expectation for software code quality (e.g. metrics thresholds,
MISRA rules re-mapping, etc.) will be incorporated to project environment during execution of SW Process
Tailoring work step [REF-12].

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 32 of 40
9 Coding Standard(s) enforcement

Mandatory adherence eternal standards (e.g. MISRA-C / HIS metrics) shall be enforced automatically with
support of designated static code analysis tools. Details of enforcement method are defined in relevant
Metric of EEPM process (e.g. [REF-08]).
Rules driven by this C-Coding Standard document shall be verified in process of code review (as part of
Work Step “Implement the SW Units of the Component“ [REF-01]).
Enforcement of rules related to style of the code (e.g. parenthesis; whitespaces) is supported by CFormatter
tool [REF-14]. Tool has been designed to be compliant with this Coding Standard and its output shall not
violate any of the defined rules. In case of lack of style rule definition, CFormatter output shall be considered
as valid guideline. In case of any identified conflict with this Coding Standard, please contact author of this
Coding Standard.

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 33 of 40
10 References
Ref. Document ID Description

[REF-01] Templates Defined by STAGES:
Documents > Software Development > Software Detailed Design, Implementation and
Component Test Documents > Software Code
See: template containing the layout, structure, and sample body of a file.
[REF-02] Doxygen Code comments Framework.

http://www.stack.nl/~dimitri/doxygen/
[REF- 03] Coding Standards Defined by STAGES:

How To
Methods > Software Development > Software Detailed Design, Implementation and
Component Test > Coding Standards How To
[REF-04] ISO 26262 2nd edition Request it from ZF Standards Library:

See Access To External Standards, or directly fetch via JobRouter / Axalant tool
[REF-05] AUTOSAR www.AUTOSAR.org

Follow link “Specifications” then “Release X.Y”. Here you will find the complete
AUTOSAR documentation set.
[REF-06] QA-C Tool Defined by STAGES:

Tools > QA-C
[REF-07] Coding Standard Defined by STAGES:

Deviation Request
Component Test > Coding Standard Deviation Request
[REF-08] MISRA compliance Defined by STAGES:

metric
Metrics > First Level Metrics / KPIs > Software Development > Software Code Quality
Metrics > MISRA compliance
[REF-09] HIS compliance Defined by STAGES:

metric
Metrics > HIS metrics compliance
[REF-10] ISO/IEC 9899:1999 / Defined by STAGES:

C99 Standard
Component Test > C-Coding Standard
See Access To External Standards, or directly fetch via JobRouter / Axalant tool
Note: In order to get 1999 version please use “Global” view
[REF-11] MISRA C:2012 http://www.cirenuk.trw.com/software/misra/
[REF-12] Prepare SW Process Defined by STAGES:

Tailoring
Processes / Work Steps > Project Monitoring & Support > Software Process Excellence
> Prepare SW Process Tailoring
[REF-13] Software Level Test Defined by STAGES:

Plan
Documents > Software Development > Software Qualification Test Documents >
Software Level Test Plan
[REF-14] CFormatter tool Defined by STAGES:

Tools > CFormatter

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 34 of 40
[REF-15] CERT-C compliance Defined by STAGES:

metric
Metrics > CERT-C compliance
[REF-16] WI_ChangeInSupplier Defined by STAGES:

Deliverables
Component Test > WI_ChangeInSupplierDeliverables
[REF-17] WI_TemporaryCodeC Defined by STAGES:

hanges
Component Test > WI_TemporaryCodeChanges
Table 7. Reference

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 35 of 40
11 List of removed rules

None.

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 36 of 40
12 Revision History of this document

Revision Date Prepared By Reviewed By Changelog
1.0 2018-Apr-24 KwiatkowskiPa Adusumalli V., Initial release for GEE PI
Ahlawat M., Peri K.,
Ravuri N.,
Subramanian K.,
Tamraz D.,
1.1 2018-Apr-26 KwiatkowskiPa Adusumalli V., Reference to DocuWeb for ISO26262

Ahlawat M., Peri K.,
Ravuri N., Updated wording of chapter 5.3 (HIS metrics)
Subramanian K.,
Tamraz D.,
1.2 2018-Jul-12 KwiatkowskiPa Adusumalli V., Provided more examples of QAC justification comment
Ahlawat M., Duecker
F., Peri K., Ravuri Chapter 3.2 point b) and c) were merged together
N., Subramanian K., Line length requirement (shall) changed to
Tamraz D., recommendation (should)
Removed rule 4.4 d) A block comment shall not have
stars (“*”) on the right hand side.
Added Polyspace violation justification (provided by
Martin Gerharz team)
1.3 2018-Aug-24 KwiatkowskiPa Adusumalli V., QAC Deviation Request process required only for level
Ahlawat M., Duecker 6-8 messages
F., Peri K., Ravuri
N., Subramanian K.,
Tamraz D.,
1.4 2018-Sep-09 KwiatkowskiPa Adusumalli V., Replaced “module” with “SwComponent” and sync
Ahlawat M., Duecker definition with STAGES glossary.
F., Peri K., Ravuri
N., Subramanian K., Enforcement of C99 standard
Tamraz D., Line length is now 200 characters
New rules for Defines and Constants
1 letter loop control variable rule
_Bool type suffix and bitfield
Fixed some inconsistencies in examples
1.5 2018-Sep-27 KwiatkowskiPa Adusumalli V., Updated after review with PSE:
Ahlawat M., Duecker
F., Leuschner S., Defined suffixed for pointers of array and array of
Peri K., Ravuri N., pointer
Subramanian K., Removed “unused” member of bitfield in example
Fix formatting as underscore (“_”) wasn’t visible
Removed casting from example
Updated Condition Statements rules
Polsypace justification comment
1.6 2018-Oct-17 KwiatkowskiPa Adusumalli V., Updated code comments general rules
Ahlawat M., Duecker
F., Leuschner S.,
Peri K., Ravuri N.,
Subramanian K.,
1.7 2018-Nov-02 KwiatkowskiPa Adusumalli V., Polyspace example changed to avoid showing code
Ahlawat M., Duecker with bug
F., Leuschner S.,

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 37 of 40
Peri K., Ravuri N.,

Subramanian K.,
1.8 2018-Nov-06 KwiatkowskiPa Adusumalli V., Expanded mapping to ISO26262 standard

Ahlawat M., Duecker
F., Leuschner S.,
Peri K., Ravuri N.,
Subramanian K.,
1.9 2018-Nov-21 KwiatkowskiPa Adusumalli V., Removed Standard comment rule b] Function
Ahlawat M., Duecker prototypes in header files shall have the same function
F., Leuschner S., comment as their bodies in the C-file.
Peri K., Ravuri N.,
Subramanian K., It was in conflict with template and rule a]
1.10 2018-Dec-06 KwiatkowskiPa Adusumalli V., Update of Adherence standard chapter with references
Ahlawat M., Duecker to STAGES.
F., Gihr W.,
Leuschner S., Peri Update dead links of References.
K., Ravuri N.,
Subramanian K.,
1.11 2018-Dec-12 KwiatkowskiPa Adusumalli V., Fix of 3.3.1 enumeration and clarify scope of global
Ahlawat M., Duecker variable in those rules.
F., Gihr W.,
Leuschner S., Peri Fix code mistake/typo in Chapter 4.4
K., Ravuri N., Removed misleading example of pointer to volatile
Subramanian K., constant in chapter 3.7
1.12 2019-Feb-13 KwiatkowskiPa Adusumalli V., Mapping to customer guidelines

Ahlawat M., Duecker
F., Gihr W.,
Leuschner S., Peri
K., Ravuri N.,
Subramanian K.,
1.13 2019-Mar-15 KwiatkowskiPa Adusumalli V., Removed GEE prefix from document.
Ahlawat M., Duecker
F., Gihr W., Aligned line length to C-code templates
Leuschner S., Peri Rules for dynamically allocated memory and stdio
K., Ravuri N., library
Subramanian K.,
1.14 2019-Mar-25 RavuriN Adusumalli V., Added supportive guidelines(defensive programming)

Ahlawat M., Duecker
F., Gihr W., Exponent format for floating numbers
Leuschner S., Peri
K., Ravuri N.,
Subramanian K.,
1.15 2019-Oct-01 KwiatkowskiPa W. Forbes Updates based on Functional Safety team review:
- Reviewer evidence
- Rephrased purpose and scope of document
- Removed some definitions to avoid conflict
with ISO/IEC 9899:1999
- Add rule to explicitly force MISRA
compliance
- New example for MISRA rule justification
- Removed assertions from defensive
programming
Rule against using macro to hide variables

Replaced customer requirements mapping by
reference to work step, which will drive the activity
Update references to STAGES

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 38 of 40
1.16 2019-Oct-14 KwiatkowskiPa Adusumalli V., Basic type definition to follow C99 ISO standard
Buehler D., Gihr W.,
Goetz G., Huelsken Updated reserved keywords to C99
M., Leuschner S., Updated to cover 26262-6 2nd edition
Muppalla S.,
Paetkau V., Peri K., Information that structure padding / data alignment is
Ravuri N., implementation dependent
Schoessow P.,
Seylan I., “boolean” typedef changed to “bool” to avoid conflict
Subramanian K., with AUTOSAR standard files
1.17 2020-May-14 KwiatkowskiPa Buehler D., Limit document scope to Div. U

Ledovskich D.,
Leuschner S., Rules enforcement chapter (style rules now will be
Muppalla S., Peri K., enforced with CFormatter to reduce engineering
Ravuri N., Rogacki effort).
K. Schoessow P., Change rules of code style to achieve alignment
Subramanian K., between PSE and ADAS SW and overall consistency:
- location of asterix “*” for pointers
- return statement shall not use brackets
Global Coding Change of examples (no related rules) to ensure

Standard CCB: consistency with CFormatter:
17-Jun-2020: - no “U” suffix in bit-field definition (as type of
Marc Schaefer, bit-field is fully enforced by ISO C standard;
Patrick Niedhart, can’t be signed)
William Forbes - no brackets {} in case of switch-case (goal
(FuSa), Stephan shall always be to reduce amount of code in
Leuschner,
switch-case for readability)
Narasimha
Dachepalli, Inanc
Seylan Advice for keeping the switch statement as small / lean
as possible.
1.18 2020-May-26 KwiatkowskiPa Buehler D., Krug M., Unique identifier for each rule.
Muppalla S., Peri K.,
Schoessow P.,
Seylan I., New rules to support compliance with not statically
Thirakanam V., enforceable MISRA C 2012 guidelines:
- Dir-4.2 +Dir-4.3: Assembly code mixed with
Global Coding C (Rule 005 + 006)
Standard CCB: - Dir-4.5: Typographically unambiguous
identifiers (Rule 012)
17-Jun-2020:
- Dir-4.4: Code shall not be commented out
Marc Schaefer, (Rule 099)
Patrick Niedhart,
William Forbes
(FuSa), Stephan
Leuschner,
Narasimha
Dachepalli, Inanc
Seylan
1.19 2020-Aug-24 KwiatkowskiPa Global Coding Removed “QAC deviation list” as it was misleading
Standard CCB: wording.
26-Aug-2020: Replaced “deviation” by “violation” (in context of static
code analysis) as deviation was misleading.
Marc Schaefer,
William Forbes Changed rule 094 (C++ comments are allowed in C99)
(FuSa), Stephan
Leuschner, Matthias Added example for rule 099

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 39 of 40
Krug, Padhmaharini Reworked chapter 6.1 Defensive programming to

Srinivasan, include secure programming aspect and guidelines
Narasimha
Dachepalli, Ashok SEI CERT-C 2016 shall be followed (not an option
Chintalapati, Denis anymore):
Tamraz - Introduction of Rule 120
- Update of chapter 7.2 CERT-C guidelines
Review and support

in update of chapter
6.1 Defensive and
Secure
programming:
William Forbes, Feiri
Michael
Dr.,Szymanski
Jakub, Juszczyk
Michal,
Schwitzgebel
Sergei, Mandalia
Anil
1.20 2020-Sept-23 KwiatkowskiPa Global Coding Replaced “boolean” with “bool” in Table 4. Variable
Standard CCB: Suffixes (to be consistent with decision made in
revision 1.16)
23-Sept-2020:
Updated bit-fields example to use ZF types instead of
Marc Schaefer, native types (example consistency improvement)
Matthias Krug,
Narasimha Replaced references of QAC message levels with
Dachepalli, Ashok MISRA / CERT-C guideline names (e.g. level 5 =
Chintalapati, MISRA Advisory Rule)
1.21 2021-Feb-05 KwiatkowskiPa Global Coding Rules 121-126 for Temporary Code & Engineering
Standard CCB: Code blocks (Div. U QIP)
Rules 127-128 for TODO & FIXME comments
17-Feb-2021:
Marc Schaefer,
William Forbes,
Stephan Leuschner,
Ashok Chintalapati,
Inanc Seylan,
Matthias Krug,
Denis Tamraz
1.22 2021-Feb-05 KwiatkowskiPa Global Coding Rule 129 – do not mix standard structure members
Standard CCB: initialization with designated initializers [C99]
Rephrase of Rule 020 to avoid misunderstanding.
17-Feb-2021: Data exchange over function arguments is allowed.
Marc Schaefer, Remove bin numeral example in Rule 051 as not
William Forbes, supported in C99.
Stephan Leuschner,
Ashok Chintalapati, Added “ULL” case to Rule 044.
Inanc Seylan, New rules to support compliance with not statically
Matthias Krug, enforceable MISRA C 2012 guidelines:
Denis Tamraz
- Dir-4.7: Test error information (Rule 130)
- Dir-4.13: Enforce appropriate sequence on
resources (Rule 131)
- Dir-4.11: Validate data passed to external
library (new CyberSec guideline)
- Dir-4.1: Protect loops with timeout detection
in case of external conditions (Rule 131)

Revision: 1.22
Status: RELEASED
C-Coding Standard
Date: 17-Feb-2021
Page: 40 of 40
Examples are aligned with CFormatter style

enforcement and syntax highlighted.


Method C-Coding Standard

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Method C-Coding Standard

Uploaded by

Copyright:

Available Formats

Revision: 1.

Document Path in STAGES:

Document Path in STAGES:

5.3 Doxygen Extensions at ZF ...................................................................................................... 20

Document Path in STAGES:

MISRA Motor Industry Software Reliability Association

ISO International Organization for Standardization

ASIL Automotive Safety Integrity Level

ASAM Association for Standardization of Automation and Measuring Systems

MCD Measuring, Calibration and Diagnostics

HIS Hersteller Initiative Software

QAC Static analysis tool supplied by PRQA Programming Research

SHALL: expresses a mandatory requirement of this document.

Document Path in STAGES:

Keyword Reserved C99 keywords are:

Module / Component / Following EEPM glossary:

Module / Component / A software component (SwComponent) prefix is a series of letters that

1.5 Conventions in this document

Next available identifier is: Rule 133

Document Path in STAGES:

2 C programming language standard

Diag_SensorXType sensorA = {.Data_u8 = 0, .Crc_u32 = 0xFFFFFFFF}; /* OK */

2.1 Assembly code with C

Document Path in STAGES:

o the interchange of the letter "O", and the digit "0"

Basic Variable Type Size AUTOSAR / ZF typedef definition name

8-bit unsigned uint8

8-bit signed sint8

16-bit unsigned uint16

16-bit signed sint16

32-bit unsigned uint32

32-bit signed sint32

64-bit signed sint64

64-bit unsigned uint64

32-bit float (single precision) float32

64-bit float (double precision) float64

Std_ReturnType (8-bit unsigned; not a

_Bool (C99 native type which could

Table 3. Type Definitions

Document Path in STAGES:

uint8 _u8 uint8 value_u8;

sint8 _s8 sint8 value_s8;

uint16 _u16 uint16 value_u16;

sint16 _s16 sint16 value_s16;

uint32 _u32 uint32 value_u32;

sint32 _s32 sint32 value_s32;

uint64 _u64 uint64 value_u64;

sint64 _s64 sint64 value_s64;

float32 _f32 float32 value_f32;

float64 _f64 float64 value_f64;

bool _bo bool value_bo;

array - _a if the type can't be

pointer - _p if the type can't be

array of pointers _ap or _apX uint8 *data_apu8[5U];

Document Path in STAGES:

enum _e MyEnumType PortValue_e;

Table 4. Variable Suffixes

3.3.1 Global Variables

Comm TxPduHandler TxPduHandler.c TxPduHandler_ void TxPduHandler_Main(void)

static uint8 Diag_LoopCounter_u8; /* file scope */

3.3.2 Local Variables

Document Path in STAGES:

/* usage of descriptive names provides clear context of control statements */

/!--- TEMP_END: <REQUEST_CM_ITEM_ID> / RevertBy: <REVERT_CM_ITEM_ID> ---!/

/!--- TEMP_END: PTC_123456789 / RevertBy: PTC_987654321 ---!/

/!--- PATCH_END: <REQUEST_CM_ITEM_ID> / RevertBy: <REVERT_CM_ITEM_ID> ---!/

/!--- PATCH_END: PTC_123456789 / RevertBy: PTC_987654321 ---!/