The Last Line Effect | Hacker News Reader

The Last Line Effect

software.intel.com

113 pointsadamnemecek18 comments

More discussion on it here, from a year ago: https://news.ycombinator.com/item?id=7858612

I was thinking about this article recently after I realized I had made this mistake and was wondering if there'd be any consistent way to check for this, like some kind of clippy: "so it looks like you're copy-pasting a pattern incorrectly..."

kind of like the error check excel does when it finds inconsistent equation in an array or cells

yeah, great example, that could also help define the scope - in what ways does the excel feature solve the problem and it what ways does it need to be expanded for code specific issues?

It did seem somewhat familiar but I the publication date was today so I thought that I was imagining it.

PVS-Studio includes analyses like that: http://www.viva64.com/en/a/0077/#ID0EISSQ

As an old habit before I knew about "paste" mode in vim, I transcribe code instead of using copy and paste. This allows me to make adjustments to the variable names and other stylistic changes, and also gives me a better chance of understanding the code.

When I am looking at someone else's code that was built mostly by copy-and-paste, it is jarring to have changes in style, indentation, and quality from piece to piece. Also there tend to be lines of code that don't do anything. Especially beginners will just paste code and then change it until it "works", which leaves a incredible mess.

I see this all the time. Your brain starts to move on to the next task before you actually complete what you are doing.

It seems like he's maybe miscounting some errors here.

Several of his examples involve duplicate lines or blocks, but he considers the error to occur in the last duplicate, rather than the first.

It seems equally valid to consider that an error on the previous lines, and more valid to consider it an error equally shared among all duplicated blocks.

Also, a simple hypothesis for why errors show up at the end: We tend to add new cases at the end of a block of similar code, and bugs are more likely to exist in more-recently added code because it's had less time to be discovered and fixed.

> t seems equally valid to consider that an error on the previous lines

No, because people usually write it top-down.

So, if I have to do something like:

a1 = 5 * b1 + 1; a2 = 5 * b2 + 1;

for multiple items, I'm going to copy one of the lines written manually then paste it at the end (because the first ones are right)

Also paste more lines than needed (because it's an estimate) is a common bug, and you'll end up with a redundant line at the end.

Reminds me of road safety advice as a disproportionate number of incidents occur within the first and last miles.

A similar effect is witnessed with crime and when I worked in retail we had training to help us focus on the first and last 30 minutes of the day as these were when staff (for whatever reason) paid least attention and it was believed that this was known and taken advantage of.

It's just a human pattern, that appears in many tasks we undertake. It doesn't surprise me that it appears in coding.

Copy and pasting blocks? That's a red flag right there, remember that next time you're doing it, and think how you could do it without the copy and pasting

How would you do it in many of those cases? For instance:

  ax[i] = bx[i]
  ay[i] = by[i]
  az[i] = bz[i]

Can the languages used write this in a better way?

I do agree that having inner functions and making them easy to define is better, but it's not always possible. In F# I could write:

  let assign i (a,b) = a[i] <- b[i]
  [ax,bx; ay,by; az,bz] |> Seq.iter (assign i)

But that's allocating a list (and if I closed over i, it'd allocate a closure too). Really good macro support would fix this, though. And it's only marginally better in this case. (For more elaborate cases it might be easier to scan.)

I like the parallel that the author draws in the article to the idea of mountain climbers falling. As we draw near the finish line, our elation rises. We can see it, taste it, feel it, and in our hurry to cross it, we lose it, cause we aren't paying attention to what we are doing.

We have a saying in the mountain climbing world: The finish line is at the bottom, not the top. It's important to consider this when climbing both up and down.

Good point, and what you say is the accurate observation: it is when descending that more accidents happen, not when reaching the top.

http://img-9gag-fun.9cache.com/photo/ae0WYVq_460sv.mp4

Looking at this, I find it amazing that I have very, very little code that is so repetitive as examples shown in the article.

Same here! These examples reminds me of how I used to write code half a decade ago.

Now I simply abuse the compiler's ability to inline small functions automatically and I create functions for every single repetition pattern I find.

Reply on news.ycombinator.com