

The Last Line Effect - adamnemecek
https://software.intel.com/en-us/blogs/2015/04/22/the-last-line-effect

======
mrspeaker
More discussion on it here, from a year ago:
[https://news.ycombinator.com/item?id=7858612](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..."

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

~~~
danvideo
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?

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

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

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

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

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

------
mrbig4545
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

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

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

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

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

------
Aliyekta
[http://img-9gag-fun.9cache.com/photo/ae0WYVq_460sv.mp4](http://img-9gag-
fun.9cache.com/photo/ae0WYVq_460sv.mp4)

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

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

