Three Questions About Each Bug You Find (1989) | Hacker News Reader

Three Questions About Each Bug You Find (1989)

multicians.org

62 pointsleoc14 comments

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

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

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

Or even -10[x], if you're really into using a silly index.

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];

In Perl, just set "$[ = 17;" to make all of your arrays 17-indexed:

http://search.cpan.org/dist/perl-5.19.0/ext/arybase/arybase....

This is the sort of language feature we should all be implementing.

I can imagine myself hunched over my keyboard at 3am swearing quietly and trying to figure out why the hell this is happening to me right now.

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.

4) whodunit?

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.

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

Reply on news.ycombinator.com