

The Last Line Effect - hiroaki
http://www.viva64.com/en/b/0260/print/

======
waqf
I'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:

* 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.

~~~
nhebb
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.

~~~
euank
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.

------
ejk314
I just wrote a script
([https://github.com/Glank/repeat_test](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.

------
JackFr
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.

~~~
mathattack
I hear you on copy & paste. I think the last line effect is real, because your
attention moves. Interesting article.

------
blt
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.

~~~
XorNot
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.

~~~
girvo
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.

------
Spoom
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.

~~~
earljwagner
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](http://www.paulgraham.com/avg.html)

------
sophacles
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.

~~~
hcarvalhoalves
Maybe the IDE could highlight what you have _not_ changed after duplicating a
line, like an inline diff.

------
joeld42
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.

------
bentcorner
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.

------
xdarnold
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.

------
goblin89
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. :)

------
ejrowley
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.

