Regarding Rule 4 - No Large Function - I think John Carmack had a pretty good explanation on why that's not really a good thing:
http://number-none.com/blow/john_carmack_on_inlined_code.htm...
http://number-none.com/blow/john_carmack_on_inlined_code.htm...
>fighter) went a step further. It disallowed both subroutine calls and
>backward branches, except for the one at the bottom of the main loop.
>Control flow went forward only. Sometimes one piece of code had to leave
>a note for a later piece telling it what to do, but this worked out well
>for testing: all data was allocated statically, and monitoring those
>variables gave a clear picture of most everything the software was doing.
>The software did only the bare essentials, and of course, they were
>serious about thorough ground testing.
>No bug has ever been found in the "released for flight" versions of that code.
I was pretty excited to learn more about that style, and then I came across...
https://www.flightglobal.com/FlightPDFArchive/1989/1989%20-%...
...but I'd still like to know more about this style of programming, and languages that facilitate programming in that manner.
Which is to say, a serious problem, but if we take "bug" to mean a difference between designed function and realized function, not a "bug", and therefore not something which should tarnish the record of the coding style to which the bug-free nature of the Grippen software is attributed. The problem seems to have been at a different level than coding.
But I just don't buy that this was not a software fault. It clearly was a case of a faulty software specification.
> The problem seems to have been at a different level than coding.
This makes me queasy. Software engineers working on these sorts of systems -- -- or at least a few senior ones -- should understand enough of the domain to say "this spec is not adequate" or "bad things might happen under conditions xyz; what's the correct behavior in these cases?". And of course all software should notice and then degrade gracefully when assumptions are observably violated.
To absolve the software engineer of any responsibility for understanding the context surrounding his software is to wrongly assume there's not much to software engineering beyond programming to someone else's spec.
Really long functions that have very low complexity (very few nested control structures, ideally none) and do not contain any loops that aren't trivial are easy to reason with. They are essentially the one case I'm familiar with where longer is not worse after a point.