I think you're missing the point. Whether or not we're talking about C is a detail, what is more important is that the lessons we learn need to be encapsulated and encoded into procedures that everyone can apply and learn from.
Equivalent mistakes can be made in any language powerful enough to do real work. Off-by-one, behaving inappropriately on parameters outside those expected, lots of things can go wrong in any language. Capturing your knowledge in a form that can be used for testing is the idea, and that seems to be missing entirely from computing.
Languages can eliminate large classes of such mistakes.
Taking your own two examples: most off-by-one errors go away if you replace "for (i = 0; i < datalength; i++)" with "for i in data" or something like that; and by replacing < or <= comparisons with checks for range membership. A checklist might say - "don't have assignments in your if statement conditions like 'if (x=0)', it's risky"; but your language or tools around it may make it impossible to do it.
"Behaving inappropriately on parameters outside those expected" is correlated with the frequency of getting unexpected parameters. No static typing? You'll have to check at runtime if the parameters are of the type that you expect. Null/undefined values? Again, you may remember to check everywhere or the language can force you to check really every time, not almost every time. Niche languages like Eiffel can help you ensure that you know that the parameters are within the expected range, etc.
Capturing such knowledge and encoding in a way suitable for everyone is done in this way - it does break backward compatibility and requires rewriting code and abandoning libraries or even languages; but the checklist equivalent of "don't ever turn on the engine before checking X, even if you think it's okay" is "don't use C strcpy ever, even if you think you know it's correct there".
what is more important is that the lessons we learn need to be encapsulated and encoded into procedures that everyone can apply and learn from.
But in software, we can do better than that! We don't have to check a checklist ourselves if we can make a tool that makes it impossible to do the wrong thing (or rather, we don't have to have that thing on the checklist).
Some places do have checklists for software engineering, if not software. For example, a simplified process for deploying code might be:
1. Check that code compiles
2. Run test suite
3. Get code reviewed
4. Push to production
And having such a list does help to ensure that code doesn't get pushed to production without being tested and reviewed. But it's better to use a system which automatically runs the tests and checks that it's been reviewed before the code goes into production (unfortunately the review itself can't be automated -- though parts of it can be, and that's useful too).
Some languages, by design, exclude or drastically reduce certain classes of error.
Edit: I think I'm missing the point too. Proposing the perfect world as an engineering solution is silly. So in the context of "it's written in C", checklists would be a step forward.
Comments
I think you're missing the point. Whether or not we're talking about C is a detail, what is more important is that the lessons we learn need to be encapsulated and encoded into procedures that everyone can apply and learn from.
Equivalent mistakes can be made in any language powerful enough to do real work. Off-by-one, behaving inappropriately on parameters outside those expected, lots of things can go wrong in any language. Capturing your knowledge in a form that can be used for testing is the idea, and that seems to be missing entirely from computing.
Languages can eliminate large classes of such mistakes.
Taking your own two examples: most off-by-one errors go away if you replace "for (i = 0; i < datalength; i++)" with "for i in data" or something like that; and by replacing < or <= comparisons with checks for range membership. A checklist might say - "don't have assignments in your if statement conditions like 'if (x=0)', it's risky"; but your language or tools around it may make it impossible to do it.
"Behaving inappropriately on parameters outside those expected" is correlated with the frequency of getting unexpected parameters. No static typing? You'll have to check at runtime if the parameters are of the type that you expect. Null/undefined values? Again, you may remember to check everywhere or the language can force you to check really every time, not almost every time. Niche languages like Eiffel can help you ensure that you know that the parameters are within the expected range, etc.
Capturing such knowledge and encoding in a way suitable for everyone is done in this way - it does break backward compatibility and requires rewriting code and abandoning libraries or even languages; but the checklist equivalent of "don't ever turn on the engine before checking X, even if you think it's okay" is "don't use C strcpy ever, even if you think you know it's correct there".
But in software, we can do better than that! We don't have to check a checklist ourselves if we can make a tool that makes it impossible to do the wrong thing (or rather, we don't have to have that thing on the checklist).
Some places do have checklists for software engineering, if not software. For example, a simplified process for deploying code might be: 1. Check that code compiles 2. Run test suite 3. Get code reviewed 4. Push to production And having such a list does help to ensure that code doesn't get pushed to production without being tested and reviewed. But it's better to use a system which automatically runs the tests and checks that it's been reviewed before the code goes into production (unfortunately the review itself can't be automated -- though parts of it can be, and that's useful too).
Some languages, by design, exclude or drastically reduce certain classes of error.
Edit: I think I'm missing the point too. Proposing the perfect world as an engineering solution is silly. So in the context of "it's written in C", checklists would be a step forward.