4 ms·

Three Questions About Each Bug You Find (1989)

62 points by leoc 9y ago

gizmo686 9y ago
>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 9y ago
  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).
  - tacostakohashi 9y ago
    Or even -10[x], if you're really into using a silly index.
  - Iv 9y ago
    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];
- MichaelBurge 9y ago
  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.pm http://search.cpan.org/dist/perl-5.19.0/ext/arybase/arybase....
  - c0nfused 9y ago
    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.
ktRolster 9y ago
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?"
andirk 9y ago
4) whodunit?
- TheDong 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        "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.
Timothycquinn 9y ago
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.
deleted 9y ago
[deleted]
tapanjk 9y ago
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.

62 points by leoc 9y ago

>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 9y ago
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).
- tacostakohashi 9y ago
  Or even -10[x], if you're really into using a silly index.
- Iv 9y ago
  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];
MichaelBurge 9y ago
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.pm http://search.cpan.org/dist/perl-5.19.0/ext/arybase/arybase....
- c0nfused 9y ago
  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.

ktRolster 9y ago

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

andirk 9y ago

4) whodunit?

TheDong 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      "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.

Timothycquinn 9y ago

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.

deleted 9y ago

[deleted]

tapanjk 9y ago

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.