This a technique employed with great success by OpenBSD. Theo de Raadt says, "Can you imagine if a Boeing engineer didn't fix all instances of a wiring flaw?"
When I was learning Haskell, I actually was able to answer no to this question. The Array [0] data type in Haskell lets (requires) you to specify the bounds (upper and lower) when you create a new Array, and I ended up mixing 0 indexed and 1 indexed arrays throughout my program.
[0] Which you should almost never use. Use Data.Vector or Data.Sequence instead.
Interestingly, you can do the same in C. For example:
int *x = malloc(sizeof(int)*100);
x = x + 50;
Then you can use negative indexes, and this is actually valid code:
x[-10] = 1337;
I've only had use for that one time, when I was doing some kind of graph processing and it was convenient/efficient to have the origin in the middle of the array (instead of translating on each access).
I read that with a combination of fascination and nausea.
Well played.
But actually I remember that it can occasionally be used in image processing too, when you would use a pointer to iterate through an image, I would routinely use things like
Definitely common sense if you really care about writing good maintainable code. I never read this article and am a self taught programmer but always follow these steps when I have the time to do so. If I don't have the time, I log an issue to follow up later.
This is an excellent post. Have you come across more recent posts that also take into consideration today's microservices and web programming based environments? Share links, please.
Blaming people is almost never a good idea. It can very easily lead to a toxic environment.
It's often helpful to know who did it and have that person involved in fixing it and looking for other cases since they're likely to know that area of the code and best understand the thought process that ended up there.
However, it should never be done with any sort of 'blame' or 'fault'. It's something to handle with care.
If a particular person keeps breaking things by skipping code reviews and such then you may already have a toxic environment. That person needs to be talked to, not necessarily chastised, but talked to for sure.
Ahhhhhh!!!! Skipping code reviews is asking for breakages! And it's not even that person's fault, if the broader team allows unreviewed coffee to be checked in.
Of course, one of the other great things about code review is that it diffuses blame, and allows us to focus on other things. If Dev A introduced a bug even after Dev B reviewed the code, then the root problem isn't that Dev A is a dummy.
One needs some openness to changing process to prevent future bugs; process questions are a key part of a postmortem.
This a technique employed with great success by OpenBSD. Theo de Raadt says, "Can you imagine if a Boeing engineer didn't fix all instances of a wiring flaw?"