
Three Questions About Each Bug You Find (1989) - leoc
http://www.multicians.org/thvv/threeq.html
======
ktRolster
_1\. Is this mistake somewhere else also?_

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?"

------
gizmo686
>Do all my arrays have the same origin?

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.

~~~
ktRolster
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).

~~~
Iv
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

    
    
        dx = *(ptr+1)-*(ptr-1);
    

which is essentially the same as

    
    
        dx = ptr[1] - ptr[-1];

------
Timothycquinn
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.

------
tapanjk
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.

------
andirk
4) whodunit?

~~~
TheDong
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.

~~~
joshribakoff
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.

~~~
sdenton4
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.

~~~
andirk
"great things about code review is that it diffuses blame" Yes! A code author
and code reviewer(s) have equally signed off on it.

Personally I always want to know if something I did has affected people in
whatever way so that I can learn from it.

