Re:JPL Institutional Coding Standard for the C Programming L...
by coldtea on Monday February 18, 2019 @11:40AM
(#19191906)
>Which brings us back full circle to the point I was originally trying to convey: if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard.
Only if the "more convoluted and harder-to-read code" is worse than what the standard tries to avoid.
A standard that calls for not allocating memory dynamically for example might result in less elegant code than one that does, for example, but that's not a "clear failure" since that away it avoids the uncertainty and variable runtime performance that malloc brings.
I'm addressing the general claim here, that "if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard" -- not specifically where the particular no-goto rule was justified.
A standard can be perfectly valid and good in restricting things even if that forces programmers to write "less elegant code" -- as long as this is necessary to fulfil some other objective of the standard (e.g. easy formal verification or real-time behavior).
Only if the "more convoluted and harder-to-read code" is worse than what the standard tries to avoid.
A standard that calls for not allocating memory dynamically for example might result in less elegant code than one that does, for example, but that's not a "clear failure" since that away it avoids the uncertainty and variable runtime performance that malloc brings.
I'm addressing the general claim here, that "if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard" -- not specifically where the particular no-goto rule was justified.
A standard can be perfectly valid and good in restricting things even if that forces programmers to write "less elegant code" -- as long as this is necessary to fulfil some other objective of the standard (e.g. easy formal verification or real-time behavior).