Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Last Line Effect

viva64.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: The Last Line Effect

#11

Post by XorNot »

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.

Re: The Last Line Effect

#12

Post by ejk314 »

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.

Re: The Last Line Effect

#13

Post by mathattack »

JackFr wrote: post #7

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.

Re: The Last Line Effect

#14

Post by 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.

Re: The Last Line Effect

#15

Post by nhebb »

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.

Re: The Last Line Effect

#16

Post by bmm6o »

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…

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.

Re: The Last Line Effect

#17

Post by astrobe_ »

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.

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

Re: The Last Line Effect

#18

Post by 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.

Re: The Last Line Effect

#19

Post by jamesrom »

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…

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.

Re: The Last Line Effect

#20

Post by elzr »

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.

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

Post reply on HN