I’m going to confess to something that will drive efficiency-oriented people crazy: I actually type stuff out, even when it copy and paste is so much faster.
The reason is that I’ve been burnt too many times by things like “the last line effect”. Things don’t work, I have to go back and reason through it all again, so I figure why not write it out again, analyzing it at that time? I find it brings about a much deeper understanding of what I’m doing. It’s a bit like writing notes on paper in a lecture, then transcribing them into electronic form later.
You should also be aware of the “typo effect” :) I don’t know which one is more reliable. At least typing it out forces you to think about what you are doing.
In my past life working on molecular dynamics and other ‘scientific’ codes this exact type of error is something I’ve written myself and seen other people write… SO MANY TIMES. This article is cold comfort, but it is nice to see it quantified and laid out with examples. Many of which are extremely familiar.
Some of those may be a side effect of how people use their editor, for example something like
:s/y/z
in vim would give you this sort of error, but
:s/y/z/g
would switch both, but even using substitute is scary because what if instead of other.y is was velocity.y and you end up with velocitz.z….
All of these errors are a bit easier to avoid w/ refactoring frameworks in big changes, but the little, ok let’s generalize this to 3D is just a simple cut and paste move. Even if you type it out, it’s a problem that is so hard to solve. There’s some interesting analysis of the goto fail problem that touches on this. Raw duplicate lines are often just bugs… right? But do we check for them, lint for them in our real code?
I’ve gotten more comfortable using single-line :s since switching from vim to emacs with evil-mode. In its default configuration, the evil-mode version shows realtime incremental preview for matches/substitutions, making it a lot easier to tell at a glance if it’s doing what you want. This might also be possible with regular vim, not sure.
Some of those should result in run time issues (not only logic issues) like the example from Multi Theft Auto (is that Grand Theft Auto, BTW?). Shouldn’t that result in a seg fault?
If you’re interested in this, Steve McConnell’s Code Complete links to a whole bunch of studies which have data on where errors come from… I tried to summarize them in a talk I gave recently, the slides are here: https://kev.inburke.com/slides/errors/
I’m going to confess to something that will drive efficiency-oriented people crazy: I actually type stuff out, even when it copy and paste is so much faster.
The reason is that I’ve been burnt too many times by things like “the last line effect”. Things don’t work, I have to go back and reason through it all again, so I figure why not write it out again, analyzing it at that time? I find it brings about a much deeper understanding of what I’m doing. It’s a bit like writing notes on paper in a lecture, then transcribing them into electronic form later.
You should also be aware of the “typo effect” :) I don’t know which one is more reliable. At least typing it out forces you to think about what you are doing.
yeah, you’re not alone; i do this as well, precisely because it makes me aware of what i’m putting in.
I do as well :).
“You may think this is an artificial sample, but it is actually taken from a real application. ”
– no I actually thought this was pulled from code I’d written.
Lol, what do you mean by this?
In my past life working on molecular dynamics and other ‘scientific’ codes this exact type of error is something I’ve written myself and seen other people write… SO MANY TIMES. This article is cold comfort, but it is nice to see it quantified and laid out with examples. Many of which are extremely familiar.
Some of those may be a side effect of how people use their editor, for example something like :s/y/z in vim would give you this sort of error, but :s/y/z/g
would switch both, but even using substitute is scary because what if instead of other.y is was velocity.y and you end up with velocitz.z….
All of these errors are a bit easier to avoid w/ refactoring frameworks in big changes, but the little, ok let’s generalize this to 3D is just a simple cut and paste move. Even if you type it out, it’s a problem that is so hard to solve. There’s some interesting analysis of the goto fail problem that touches on this. Raw duplicate lines are often just bugs… right? But do we check for them, lint for them in our real code?
gotcha, I thought you were making fun of the author’s statement.
BTW, every time I use
:son a single line I wonder if it isn’t faster to do it manually and not have to check for unwanted substitutes.I’ve gotten more comfortable using single-line
:ssince switching from vim to emacs with evil-mode. In its default configuration, the evil-mode version shows realtime incremental preview for matches/substitutions, making it a lot easier to tell at a glance if it’s doing what you want. This might also be possible with regular vim, not sure.Some of those should result in run time issues (not only logic issues) like the example from Multi Theft Auto (is that Grand Theft Auto, BTW?). Shouldn’t that result in a seg fault?
Multi Theft Auto is a set of multiplayer mods for the PC versions of GTA 3, Vice City, and San Andreas.
No, it should be:
const int mjstride = countof(mag[0][0]);
Friends don’t let friends calculate sizes of arrays themselves because they always stuff it up.
Possibly something like this, I’m not sure what the context is:
Vec3 tmp = *in;
I’m going to assume the Source Engine SDK example was part of a vector/quaternion class.
Yes, but the function is called CreateQuad, I’d bet the array should contain 4 items.
Static analysis could have picked up these errors and maybe more.
Is it just me or have I read this before? I remember reading a similar article a couple years ago…
It was shared here 11 months ago: Lobsters Article
The author has just published it again on the intel site.
I see. Although I wasn’t on Lobsters then. Guess it was HackerNews or something.
If you’re interested in this, Steve McConnell’s Code Complete links to a whole bunch of studies which have data on where errors come from… I tried to summarize them in a talk I gave recently, the slides are here: https://kev.inburke.com/slides/errors/