The Last Line Effect • Hacker News Board

Re: The Last Line Effect

#21

Post by euank » Sat, Jun 07, 2014, 4:57 AM UTC

nhebb wrote: post #15

waqf wrote: post #5

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 exa…

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.

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.

Re: The Last Line Effect

#22

Post by earljwagner » Sat, Jun 07, 2014, 6:23 AM UTC

Spoom wrote: post #9

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

Re: The Last Line Effect

#23

Post by goblin89 » Sat, Jun 07, 2014, 6:27 AM UTC

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

Re: The Last Line Effect

#24

Post by ddebernardy » Sat, Jun 07, 2014, 7:51 AM UTC

waqf wrote: post #5

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 exa…

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

Re: The Last Line Effect

#25

Post by ejrowley » Sat, Jun 07, 2014, 9:11 AM UTC

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.

Re: The Last Line Effect

#26

Post by Teckla » Sun, Jun 08, 2014, 1:20 AM UTC

nhebb wrote: post #15

waqf wrote: post #5

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 exa…

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.

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.

Re: The Last Line Effect

#27

Post by girvo » Mon, Jun 16, 2014, 1:05 AM UTC

XorNot wrote: post #11

blt wrote: post #10

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.

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.