The Last Line Effect(viva64.com)
viva64.com
The Last Line Effect
http://www.viva64.com/en/b/0260/print/
26 comments
> * People make mistakes in any line, but they often unconsciously review them and spot the mistake while they're writing the next line.
I came in to say something similar. I've lost count of the number of times I did that myself.
That said, the automatic review and error spotting invariably prompts me to review the entire thing with greater attention once done with the whole. So the reason the last line doesn't get a proper review may also turn out to be the lack of hard deadline (I've been blessed by seldom having one).
I came in to say something similar. I've lost count of the number of times I did that myself.
That said, the automatic review and error spotting invariably prompts me to review the entire thing with greater attention once done with the whole. So the reason the last line doesn't get a proper review may also turn out to be the lack of hard deadline (I've been blessed by seldom having one).
Good points. One more:
* Getting interrupted partway through the edits. I call this the "working out of your home office when you have kids" error.
Now, I don't copy-paste-edit similar lines anymore. I find that editing is often slower than typing the line from scratch.
* Getting interrupted partway through the edits. I call this the "working out of your home office when you have kids" error.
Now, I don't copy-paste-edit similar lines anymore. I find that editing is often slower than typing the line from scratch.
I think that's a function of text editor or workflow often.
A vim user that makes heavy use of recording and/or search-replace will be able to do large copy-paste-edits very quickly.
In fact, I think this might be another potential source of error. Depending on how the recording is done, or how an edit is scripted, it's very likely that the first and last lines are the two special cases. The first line, however, will be given the most scrutiny. This leaves another potential source of "last-line" errors; the use of editor features that make such a line the exception.
A vim user that makes heavy use of recording and/or search-replace will be able to do large copy-paste-edits very quickly.
In fact, I think this might be another potential source of error. Depending on how the recording is done, or how an edit is scripted, it's very likely that the first and last lines are the two special cases. The first line, however, will be given the most scrutiny. This leaves another potential source of "last-line" errors; the use of editor features that make such a line the exception.
Getting interrupted partway through the edits. I call this the "working out of your home office when you have kids" error.
I'm interrupted by my boss far, far more often than I'm interrupted by my kid. A dozen times a day isn't unusual.
I'm interrupted by my boss far, far more often than I'm interrupted by my kid. A dozen times a day isn't unusual.
I agree, although I will say this happened to me yesterday, and I'm certain it was due to the anticipation of finishing the task.
Some of the examples were probably written all at once, but in some examples the last case was probably added some time later. The pattern followed by the previous cases was no longer fresh in the mind, and a mistake was made.
I just wrote a script (https://github.com/Glank/repeat_test) to see if I could catch these sorts of errors. It does OK. I looked for repeated lines based on their levenshtein percent difference. Then for those repeating groups, if the percent difference between any of the lines is an outlier it returns a positive result.
In my experience this effect is real, but I wouldn't always see it in the last line. A coworker proved this to me years ago by making me keep a tally when errors were caused by copy-and-pasted code, versus all other causes. Copy-and-paste won hands down.
I hear you on copy & paste. I think the last line effect is real, because your attention moves. Interesting article.
The last line often has something extra - a semicolon or parentheses - or something missing, like no comma in an enum or no `&&` in a long chained conditional. Maybe that triggers the "gorilla on the basketball court" effect, and we miss the error in the meat of that line because we're focusing on the difference.
It is one of the more foolish things that programming languages leave around though. If I'm writing an enum which is bracket closed, then don't make leaving in an extra comma an error if it's unambiguous.
As I recall I think most of the brackety languages actually do ignore it now? So it's a good way to mitigate at least that small problem.
As I recall I think most of the brackety languages actually do ignore it now? So it's a good way to mitigate at least that small problem.
Hack (Facebook's PHP-derived statically typed scripting language) definitely does allow it, which is nice.
In fact, over on #hhvm I was told that Facebook's Hack style guide requires a trailing comma, which I think is a good thing and will catch a lot of silly errors.
In fact, over on #hhvm I was told that Facebook's Hack style guide requires a trailing comma, which I think is a good thing and will catch a lot of silly errors.
Yes, I noticed this a lot with Javascript: I would often have a trailing comma at the last element of an array or object. Most browsers would let it go unremarked but it was stupidly a halting error in some versions of IE.
Anyway, when I made my own Vim syntax highlighter for JSON, I spent a fair amount of effort in getting such a trailing comma highlighted as an error: https://github.com/elzr/vim-json
Anyway, when I made my own Vim syntax highlighter for JSON, I spent a fair amount of effort in getting such a trailing comma highlighted as an error: https://github.com/elzr/vim-json
Sometimes copy paste is unavoidable, but a lot of times it can be replaced with a loop over a constructed array of "things that change" that achieves the same goal. I've been trying to do this recently in the spirit of DRY; it has the side benefit of often making the code quite a bit more readable.
Yes, and sometimes you want to loop over something that can't be expressed with existing syntax.
That's the benefit of Lisp-style macros:
http://www.paulgraham.com/avg.html
I find it ironic that we use programming editors that are extremely good at copy-pasting (vi, emacs for instance) only to avoid using those features because we know they are somewhat evil (introduce those kind of bugs, "prevent" proper factoring).
This is really interesting. I just looked over some code I wrote this morning. There were 2 LLE errors. I'm sure I would have caught them in testing after lunch but, woah. For the life of me, I can't reconstruct my mental state when I edited those code bits though, so I don't know what the root of the error is. I think now though, I'll be on the lookout and perhaps gain some insight.
In retrospect, I've had quite a few of these - once pointed out as a pattern, it's fairly easy to see it's a "thing".
I wonder what sort of IDE or other tooling could be put in place to hint those errors out of existence.
In retrospect, I've had quite a few of these - once pointed out as a pattern, it's fairly easy to see it's a "thing".
I wonder what sort of IDE or other tooling could be put in place to hint those errors out of existence.
Maybe the IDE could highlight what you have not changed after duplicating a line, like an inline diff.
In case you don't know: the site in question is from a company that makes a static analyzer that spots such issues.
I would be more skeptical, but this just happened to me this morning!
I try to discipline myself to retype code instead of copy-pasting (unless it's lengthy, then I should refactor instead of copy-pasting). It always saves more time that it takes to retype. But sometimes I'm lazy.
I try to discipline myself to retype code instead of copy-pasting (unless it's lengthy, then I should refactor instead of copy-pasting). It always saves more time that it takes to retype. But sometimes I'm lazy.
Another possible symptom is a merge conflict.
Programmer A makes a change that adds a list of things out of one thing and checks in. Programmer B checked out the "one thing" version and made an update to it. They check in, and they now need to deal with a merge conflict into a list of things that they now need to expend mental energy understanding. Mistakes get made.
Programmer A makes a change that adds a list of things out of one thing and checks in. Programmer B checked out the "one thing" version and made an update to it. They check in, and they now need to deal with a merge conflict into a list of things that they now need to expend mental energy understanding. Mistakes get made.
This is potentially an interesting effect and worthy of some consideration, but the analysis needs to include some regression of this possible factor:
An increased number of errors on "return" lines.
Which naturally should be more frequently last lines than otherwise.
An increased number of errors on "return" lines.
Which naturally should be more frequently last lines than otherwise.
I would agree. Anecdotally, from me writing this kind of code requires a conscious effort to not make a mistake specifically closer to the end of the series.
Of course, the ideal way to avoid such problems is to embrace the lack of patience and properly structure the code. :)
Of course, the ideal way to avoid such problems is to embrace the lack of patience and properly structure the code. :)
An interesting article and I am guilty of copy and paste errors myself. But the bias towards the last line may be because those mistakes are tested less then other parts i.e. in an if statement early conditions mean the final condition is never tested.
* People make mistakes in any line, but they often unconsciously review them and spot the mistake while they're writing the next line. In the case of the last line there's no such automatic review.
* (plausible in some of the examples, not all of them) The last line was added by copy–paste at a later date than all the others.