3. Better education will not prevent programming bugs. Better process and mechanical checking will.
I don't know if this is what you meant by mechanical checking, but I highly rate two things to reduce bugs:
(1) Checking that the output of the entire system is 100% (and I meant 100% literally in every sense of the word) accurate, not just that the smaller unit tests pass or that the output "looks right".
(2) Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.
As a dev with a data science background, I'm always impressed how many bugs pure devs are able to smuggle in whenever the task involves any kind of data, despite extensive unit testing. I check out their code, run it once, and immediately see the output is wrong and then they have to go back and debug. If we just check our output that wouldn't be the case!
int[10] a;
a[10] = 3; // Error, array index out of bounds
The idea is to allow powerful metal code, while providing constructs that make errors much less likely. For example,
if (a < b < c)
is allowed by C, but few C programmers can tell you what it means, and the appearance of it in code is almost always a bug. Instead of educating programmers with "don't do that", D makes it illegal. (If you really want it, you'd have to write it as: `(a < b) < c`. But notice you have to make an effort to write code that way, it is highly unlikely to be accidentally written.)
> Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.
I find it useful to go back through the logic a couple months later. I usually find a lot to improve :-)
I don't know if this is what you meant by mechanical checking, but I highly rate two things to reduce bugs:
(1) Checking that the output of the entire system is 100% (and I meant 100% literally in every sense of the word) accurate, not just that the smaller unit tests pass or that the output "looks right".
(2) Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.
As a dev with a data science background, I'm always impressed how many bugs pure devs are able to smuggle in whenever the task involves any kind of data, despite extensive unit testing. I check out their code, run it once, and immediately see the output is wrong and then they have to go back and debug. If we just check our output that wouldn't be the case!