what effect the last line create
Answers
Answer:
Last line effect
When writing program code, programmers often have to write a series of similar constructs. Typing the same code several times is boring, and inefficient. That's why they use the Copy-Paste method: a code fragment is copied and pasted several times, with further editing. Everyone knows what is bad about this method: you risk easily forgetting to change something in the pasted lines, and thus giving birth to errors. Unfortunately, there is often no better alternative to be found.
Now let's speak about the pattern I discovered. I figured out that mistakes are most often made in the last pasted block of code.
Here is a simple and short example:
inline Vector3int32& operator+=(const Vector3int32& other) {
x += other.x;
y += other.y;
z += other.y;
return *this;
}
Note the line "z += other.y;". The programmer forgot to replace 'y' with 'z' in it.
You may think this is an artificial sample, but it is actually taken from a real application. Further on in this article, I am going to convince you that this is a very frequent, and common, issue. This is what the "last line effect" looks like. Programmers most often make mistakes at the very end of a sequence of similar edits.
I heard somewhere, that mountain-climbers often fall off in the last few dozen meters of their ascent. Not because they are tired; they are simply too joyful about almost reaching the top - they anticipate the sweet taste of victory, get less attentive, and make some fatal mistake. I guess something similar happens to programmers.
Now a few figures.
Having studied the bug database, I singled out 84 code fragments which I found to have been written through the Copy-Paste method. Out of them, 41 fragments contain mistakes somewhere in the middle of the copied-and-pasted blocks. For example:
strncmp(argv[argidx], "CAT=", 4) &&
strncmp(argv[argidx], "DECOY=", 6) &&
strncmp(argv[argidx], "THREADS=", 6) &&
strncmp(argv[argidx], "MINPROB=", 8)) {
The length of the "THREADS=" string is 8 characters, not 6.
In the other 43 cases, mistakes were found in the last copied code block.
Well, the number 43 looks just slightly bigger than 41. But keep in mind that there may be quite a lot of homogeneous blocks, so mistakes can be found in the first, second, fifth, or even tenth block. So we get a relatively smooth distribution of mistakes throughout blocks, and a sharp peak at the end.
I accepted the number of homogeneous blocks to be 5 on the average.
So it appears that the first 4 blocks contain 41 mistakes distributed throughout them; that makes about 10 mistakes per block.