The table below documents the compliance or otherwise with the rules defined in issue 1 of the "C and C++ Coding Standard" prepared by the ESA Board for Software Standardisation and Control (BSSC). The first column reports the number of the rule as it is given in the ESA document. The second column states whether the rule is adopted in the OBS frameworks. In case of rejection or partial acceptance, an explanation is provided.

N. Adoption in the OBS Frameworks
0 Adopted in Full. Deviation from rules are documented in this table or directly in the source code.
1 Not applied to the current version of the framework. This rule should be applied by end-users who intend to use the framework in their projects.
2 Adopted in Full. Software is developed in development environments that provide automatic makefile facilities
3 Adopted in Full.
4 Adopted in Full.
5 Not applied to the current version of the framework. See also rule 11.
6 Adopted in Full.
7 Adopted in Full.
8 Adopted in Full.
9 Not Applicable. No debugging code is present in OBS Framework code.
10 Not Applicable. No debugging code is present in OBS Framework code.
11 Not applied to the present version of the framework: no special tools were used to check compliance with coding rules.
12 Adopted in Full.
13 Not Applicable. Only C++ code is used.
14 Adopted in Full.
15 Adopted in Full.
16 Adopted in Full.
17 Adopted in Full.
18 Adopted with a line length of TBC characters.
19 Rejected. Including one-line blocks in braces makes code less readable.
20 Adopted in full. Bracing style is automatically applied by MS Visual Studio editor. This rule is however regarded as not very important because this and other advanced development environment automatically highlight matching braces.
21 Adopted in full. Indentation style is automatically applied by MS Visual Studio editor.
22 Adopted in Full.
23 Adopted in Full.
24 Adopted in Full.
25 Adopted in Full.
26 Adopted in Full.
27 Adopted in Full.
28 Adopted in Full.
29 Adopted in Full. Additionally, PR5.1 is introduced to particularize this rule.
30 Adopted in Full.
31 Adopted in Full.
32 Adopted in Full.
33 Adopted in Full.
34 Adopted in Full.
35 Adopted in Full.
36 Rejected. Rule would make changes to the code or to the library/module structure very difficult.
37 Adopted in Full.
38 Adopted in Full. Project-specific naming conventions are defined here.
39 Rejected. Rule would make name excessively long.
40 Adopted in Full.
41 Rejected. Function names are treated like variable names. This is in accordance with standard contemporary practice.
42 Adopted in Part. Prefix or suffixes are not always used. See the project specific naming conventions.
43 Adopted in Full. More specific naming patterns are used in this project than are specified by these rules. See the project specific naming conventions for details.
44 Adopted in Part. See the project specific naming conventions for details on how class names are to be constructed.
45 Adopted in Full.
46 Adopted in Part. Explanatory comments are not always provided as this can be confusing and is unnecessary for simple variables.
47 Adopted in Full.
48 Adopted in Full.
49 Adopted in Full.
50 Adopted in Full.
51 Rejected. This rule is regarded as unnecessary because only small number of closely related declarations ever appear close to each other.
52 Adopted in Full.
53 Not Applicable. All code is in C++.
54 Adopted in Full.
55 Adopted in Full.
56 Adopted in Full.
57 This Rule is not Understood.
58 Adopted in Full.
59 Adopted in Full.
60 Adopted in Full. This rule is also applied to class methods.
61 Adopted in Full.
62 Not Applicable. All code is in C++.
63 Adopted in Full.
64 Adopted in Full.
65 Rejected. JavaDoc-style of function and method definition is used.
66 Adopted in Full.
67 Adopted in Full.
68 Adopted in Full.
69 Adopted in Full.
70 Rejected. This rule is unnecessary in view of project-specific rule PR2.2 and PR2.3.
71 Not Applicable. See rule 70.
72 Rejected. This rule is unnecessary in view of project-specific rule PR2.7 and PR2.8.
73 Adopted in Full. See also Rule 65.
74 Adopted in Full.
75 Adopted in Full.
76 Rejected. This rule is unnecessary in view of project-specific rule PR2.5.
77 Not Applicable. See rule 76.
78 Not Applicable. See rule 70.
79 Not Applicable. See rule 70.
80 Not Applicable. Operator overloading is not used in OBS Framework.
81 Adopted in Full.
82 Adopted in Full.
83 Adopted in Full.
84 Adopted in Full.
85 Adopted as amended by project-specific rule PR6.1.
86 Not Applicable. Templates are not used in the OBS Framework.
87 Not Applicable. Templates are not used in the OBS Framework.
88 Not Applicable. Exceptions are not used in the OBS Framework.
89 Not Applicable. Exceptions are not used in the OBS Framework.
90 Not Applicable. Exceptions are not used in the OBS Framework.
91 Adopted in Full.
92 Adopted in Full.
93 This Rule is not Understood.
94 Not Applicable. Operator overloading is not used in OBS Framework.
95 Adopted in Full.
96 Adopted in Full.
97 Adopted in Full.
98 Adopted in Full.
99 Rejected. This rule is superceded by project-specific rule PR7.4.
100 Not Applicable. The malloc operator is not used in OBS Framework.
101 Not Applicable. The realloc operator is not used in OBS Framework.
102 Adopted in Full.
103 Not Applicable. Dynamically allocated memory is never released in the OBS Framework.
104 Rejected. This rule is unnecessary in view of project-specific rule PR2.2. See also project-specific rule PR7.4.
105 Adopted in Full. Project specific rule PR7.3 specifies how the rule is interpreted.
106 Rejected. This rule is superceded by project specific rule PR7.1.
107 Rejected. The OBS Framework does not contain any code that is not intended to be reached.
108 Adopted in Full.
109 Adopted in Full.
110 Adopted in Full.
111 Not Applicable. Pre-processor macros are not used in the OBS Framework (see also project specific rule PR9.2).
112 Not Applicable. Pre-processor macros are not used in the OBS Framework (see also project specific rule PR9.2).
113 Adopted in Full.
114 Adopted in Part. This rule is assumed to refer to the use of typedef to rename primitive types. This rule is adopted in most cases. In a few cases, raw primitive types are used where the memory and code impact of switching to a different type would be limited.
115 Adopted in Full.
116 Adopted in Full.
117 Adopted in Part. Assumptions about data representations are necessary when writing to or reading from hardware registers and I/O ports.
118 Adopted in Full.
119 Adopted in Full.
120 Adopted in Full.
121 Adopted in Full.
122 Adopted in Full.
123 Adopted in Full.
124 Adopted in Full.
Contact Us | The OBS Framework Project