The Last Line Effect

I&#x27;m not convinced that this is necessarily caused by people losing attention while they write the last line due to anticipation of finishing the task. Other possible theories I can think of:<p>* People make mistakes in any line, but they often unconsciously review them and spot the mistake while they&#x27;re writing the next line. In the case of the last line there&#x27;s no such automatic review.<p>* (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.

I just wrote a script (<a href="https://github.com/Glank/repeat_test" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Glank&#x2F;repeat_test</a>) 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&#x27;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.

The last line often has something extra - a semicolon or parentheses - or something missing, like no comma in an enum or no `&amp;&amp;` in a long chained conditional. Maybe that triggers the &quot;gorilla on the basketball court&quot; effect, and we miss the error in the meat of that line because we&#x27;re focusing on the difference.

Sometimes copy paste is unavoidable, but a lot of times it can be replaced with a loop over a constructed array of &quot;things that change&quot; that achieves the same goal. I&#x27;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.

This is really interesting. I just looked over some code I wrote this morning. There were 2 LLE errors. I&#x27;m sure I would have caught them in testing after lunch but, woah. For the life of me, I can&#x27;t reconstruct my mental state when I edited those code bits though, so I don&#x27;t know what the root of the error is. I think now though, I&#x27;ll be on the lookout and perhaps gain some insight.<p>In retrospect, I&#x27;ve had quite a few of these - once pointed out as a pattern, it&#x27;s fairly easy to see it&#x27;s a &quot;thing&quot;.<p>I wonder what sort of IDE or other tooling could be put in place to hint those errors out of existence.

I would be more skeptical, but this just happened to me this morning!<p>I try to discipline myself to retype code instead of copy-pasting (unless it&#x27;s lengthy, then I should refactor instead of copy-pasting). It always saves more time that it takes to retype. But sometimes I&#x27;m lazy.

Another possible symptom is a merge conflict.<p>Programmer A makes a change that adds a list of things out of one thing and checks in. Programmer B checked out the &quot;one thing&quot; 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:<p>An increased number of errors on &quot;return&quot; lines.<p>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.<p>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.