Rule 3-4-1 and defining constants in one place

[rrosier]

If one were to use the strategy of defining all the constants used within a file at the top of the file, either as static const or in an unnamed namespace, but some of the constants are used in multiple places and others are only used in single places, then those that are only used in single places will violate Rule 3-4-1.

If those that are used only in single places are subsequently moved into blocks with reduced scope, then the constants are scattered around the file.

This could create a maintenance headache because it is more difficult for a developer to find a constant.

Furthermore, if a developer needs to use a singly-used constant now in another place, they might not realise that the constant has already been defined (and then widen its scope) but instead add in a new singly-used constant of reduced scope in the new place.

It there some way to put all of the defined constants into a well-known location, but then not violate Rule 3-4-1 for the singly-used ones?

[dg1980]

I don't think that this rule was meant to be relevant for constants (values that can not be changed) because the text only talks about variables (identifiers with values that can be changed).

But once again, we need an official clarification because the rule text leaves room for interpretation (which is a bad thing in most specifications btw.).

[rrosier]

Indeed, because if one wishes to use the strategy of putting all the constants in one well-known place and then have a commercial Static Analysis tool check that code and then the static analysis tool pulls out all the constants that are only used in single places elsewhere in the code:

Then in order to comply with MISRA, one has to either:

1. Create an individual guideline violation approval and associated deviation record for each individual violation, or
   
2. Create a generic deviation permit together with our reasoning for allowing such a class of deviations, or
   
3. Convince the toolset vendor that the rule was not intended to be applied in this way and that this is a false-positive.

For cases ( a ) and ( b ), should a customer specify that Rule 3-4-1 is completely Mandatory and that no violations are allowed under any circumstances, then the code would not meet such a requirement.

However, for case ( c ), the code would not have any violations, but it would be necessary to convince the toolset vendor that this situation was a false-positive and that the rule was not meant to be applied this way.

I was hoping for some clarity here so that if I have a discussion with the toolset vendor I have some evidence regarding how MISRA intended this rule to be applied.

[misra cpp]

This rule was not intended to apply to constants, and will be clarified for the next version