+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17)
+---- Forum: 6.5 Identifiers (https://forum.misra.org.uk/forumdisplay.php?fid=32)
+---- Thread: Rule 5.6 / Rule 5.7 (/showthread.php?tid=289)
Rule 5.6 / Rule 5.7 - sparker - 20-07-2006
I'm confused by the difference between the two examples in these two rules. In R5.6 we're shown that it is ok to reuse the structure member identifier \"next\" since \"member names are less likely to be confused\", and in R5.7 we're shown that members of two different structure types cannot have the same name (\"speed\").
Is the intention that one deviates from R5.7 leaving R5.6 to catch the most important cases? If so that isn't very clear from the text.
(Overall I'd be surprised if anyone ever sticks to R5.7 since it means that every identifier in your program, even every local, has to differ from every other. That means no \"i\", \"j\", \"p\", \"speed\", \"rpm\", ..., \"index\", etc.)
Re: Rule 5.6 / Rule 5.7 - bmerkle - 21-07-2006
sparker Wrote:Is the intention that one deviates from R5.7 leaving R5.6 to catch the most important cases? If so that isn't very clear from the text.I would agree that the example is a bit unfortune and it gets not very clear.
.
sparker Wrote:(Overall I'd be surprised if anyone ever sticks to R5.7 since it means that every identifier in your program, even every local, has to differ from every other. That means no "i", "j", "p", "speed", "rpm", ..., "index", etc.)
I assume they mean "identifer of (different) name spaces" (see R5.6).
As R5.6 carifies this has nothing to do with scope, so your program can contain i, j, p as loop variables (in various scopes) and still is compliant ;-)
Overall my point (i am NOT speaking for MISRA-C consortium) regarding identifiers is that they are not *so* very important. Most customers anyway have their own "naming-rules" and if you look at "coding-guidelines" in companies, they often deal with this issue (and unfortunately the largest part are often naming conventions, whereas the "real" stuff is missing. ;-)
Fortunately the real stuff is provided by MISRA-C, so I would perhaps deviate from R5.6 and R5.7 but use my own naming rule.
two other interessting points: (my observations)
1. often identifieres are confused because their names are different (so misra compliant) but they closely match (only some characters differ), e.g.
srv, svr, etc... Some lint-like-tools have add-ons that catch such candidates.
2. If you make a (very) rigorous naming schema you easily end up with either unreadable names or very long names (which could violate R5.1)
just my 3 cents,
kind regards,
Bernhard.
- misra-c - 23-08-2006
MISRA-C meeting 23-8-2006
It is the experience of members of the committe that rule 5.7 can be sensibly applied to and is common in safety-critical software.
Quote:1. often identifieres are confused because their names are different (so misra compliant) but they closely match (only some characters differ), e.g.
srv, svr, etc... Some lint-like-tools have add-ons that catch such candidates.
2. If you make a (very) rigorous naming schema you easily end up with either unreadable names or very long names (which could violate R5.1)
Poor implementations can lead to unreadable long parameter names.
Good implementaion works, and is shown to avoid problems.