19-04-2018, 04:50 PM
Yes, this rule is a bit of a pain to live with at times. Unfortunately, functional safety standards (i.e. 61508 and derivatives) require that functions have a single point of exit - the rule is there to support that objective.
Personally, I see no issue with using a deviation supported with a "Reason" of code-quality.
It's worth noting that MISRA C:2012 has reduced the enforcement level of this rule to "Advisory", which makes it easier to manage as it could be set to "Disapplied" when using MISRA Compliance:2016.
There is also another compliant coding pattern that can be used which avoids the risk of failing to detect an error and that has better readability:
Personally, I see no issue with using a deviation supported with a "Reason" of code-quality.
It's worth noting that MISRA C:2012 has reduced the enforcement level of this rule to "Advisory", which makes it easier to manage as it could be set to "Disapplied" when using MISRA Compliance:2016.
There is also another compliant coding pattern that can be used which avoids the risk of failing to detect an error and that has better readability:
Code:
int CheckIsOk()
{
int err = E_UNEXPECTED;
if ( currentObject == NULL )
{
err = E_ERR_1;
}
else if ( !IsClassValid( id ) )
{
err = E_ERR_2;
}
else
{
currentObject->test();
err = E_OK;
}
return err;
}
<t></t>