14.1 There shall be no unreachable code

[Frank Haug]

A bright British (1) wrote \"The argument of this book – which again, surely, can only convince you insofar as what I say fits with what you know.\" (2)

According to this I thought me to know too less, because I do not understand the MISRA committee's view at all (Rule 14.1 and last contribution of 2007-12-11). This means I went to school again: Google and and electronic documents that enclose a lot of documents of todays C and C++ gurus, but publications of non-guru publishers as well. The result: \"infeasible code\" does not exist in a huge amount of IT related publications.

I'd been irritated. Anyone of us seem to be wrong here.

What are the facts ? We have reachable code and not reachable code. The MISRA committee tells us that there may be \"code, that can be reached but (may) never be executed\" (Rule 14.1). And in my request for clarification, I get additional remarks that enhance the wording confusion speaking about \"infeasible code\" and \"dead code\".

Several days I thought about how to answer on such absurd things appropriately. Firstly I thought to add some kind of \"living code\" (e.g. the brother of \"dead code\"), or \"happy code\" (the sister of ...). But this does not solve our problems pursuing to more quality in software solutions. But the MISRA committee doesn't resolve the problems either. MISRA committes' wordings are referenced nowhere, neither marked with an authors name. This works against all accepted academic standards in doing a serious scientific oriented job. It's a lack of respect against all well educated and experienced quality managers and software developers all over the world, that are forced to meet their decisions DAILY and not in 4, 5 or 6 years (when we may get a reworked MISRA publication).

I solved the problems for myself by re-structuring the related issues:

- - - - - - - - - -

I delete MISRA Rule 14.1 and substitute it with two others:

not MISRA 2004 - extension 1: avoid unreachable code - advisory
===============================================================

reason: there only can be reachable code or unreachable code. Unreachable code is not safety critical, but it reduces transparency and maintenance, therefore it should be eliminated. Because unreachable code
is not primarily dangerous, I mark it as \"advisory\".

not MISRA 2004 - extension 2: Defensive Programming - mandatory
==============================================================

always take
*) a default statement in a switch
*) a final else branch (in \"if - else if - else if - else\" (14.10) ... not necessary in \"if only\") EXCLUSIVELY to catch error conditions.

reason: changing code in an other part of the translation unit (maybe later) may lead into the default or final else branch and always should be caught.
(also see \"6.15 Switch Statements -> Switches, default, and enums!\"
Posted: Wed Jan 09, 2008 5:12 pm, by George Brown).

- - - - - - - - - -

Out of my view these two extensions cover a lot of possibilities and allows clear decisions in coding and coding evaluation. But I've forgotten an important aspect: I have to word a deviation procedure for refusing MISRA Rule 14.1: I fill it with above argumentation and a reference on this discussion thread. Now I'm MISRA compliant again.

Thanks for the recipients patience. Refinements and critisism are appreciated.

Frank (Haug), [email protected], Stuttgart, Deutschland

----------------------------------
(1) Gregory Batseon, son of the geneticist William Bateson and husband of the famous Margaret Mead
(2) Mind and Nature, out of chapter \"science never proof anything\"

BTW:
Out of 20 years of working together with informatics and mathematics, it appears to me that some of them could profit from