Code Archeology – Lines of code by age | Hacker News Reader

Code Archeology – Lines of code by age

smrrd.de

47 pointssamuirai19 comments

> Remember - the lighter the color, the older the code.

I really think it should be the opposite. Recent code should be clearly visible and older code should progressively interpolate into black. The current setup is extremely unintuitive for me.

That it's so interesting. A lot of people said that to me. But to me it felt more natural to highlight old code. Probably because I had this bias in the back of my mind that old code could be bad code.

In my experience, it's often the new/changed code that is the most interesting. It's often the code that is causing some unexpected bug. 'No one sews a patch of unshrunk cloth on an old garment. Otherwise, the new patch pulls away from the old cloth, and a worse tear is made'

Physical things often become darker with age due to dirt or corrosion. Examples are wood and metal, or an old vs. a new wall painted in the same color. They all become darker over time. Therefore I think it't more intuitive to think of darker things as older.

You are ignoring survivor bias.

Old code is mostly good code. It's new code that has varying quality.

Luckily you're a programmer, and can easily change a python script!

Ha I just did a little RubyGem to find files of which x% of the lines are more than y years old - the olde_code_finder:

http://thomasleecopeland.com/2014/09/18/olde-code-finder.htm...

Actually, the first version only found files where x% of the lines were written by a particular author. Then someone gently suggested checking the line age, which made perfect sense.

If you adapted this to Wikipedia articles (a very nontrivial task) you could highlight "authority": how long has a fragment of an article withstood editors.

Phabricator offers this functionality via it's blame feature and shades of green

https://secure.phabricator.com/diffusion/ARC/browse/master/s...

Which do we prefer, though? As an industry, we seem to chose the "new shiney" way more than the alternatives. To the point that "hasn't been touched by the author in a few years" is a warning sign more than a sign of completeness.

It's not an issue of preference, but understanding. Knowing how code has evolved can help us understand it. And I particularly liked the point the author raised about comments: it's valuable to know how old a comment is, in case we suspect it no longer reflects the code.

I didn't want to make it look that way. The color indication is without any judgment. It's just interesting how code evolved over time. In fact you should reverse the color gradient or use different colours, so you can read code how you prefer it.

Yeah, I didn't really see this post as reading into it one way or the other. I was more just broadcasting how I don't know what to make of the age of code.

More, I think context plays a big role and it is difficult to see what new is brought to the table at times. Worse, what old was accidentally discarded?

Very cool idea. Somebody pointed me at https://github.com/FriedSock/smeargle which implements this for my text editor (see also https://github.com/syohex/emacs-smeargle), so I couldn't resist trying it out. But I can't think of a concrete situation when I'd want my text editor to look like these screenshots: http://imgur.com/a/ufqRV

Perforce does this with the Revision Graph/time-lapse view. Super handy feature for understanding new code and how it evolved (or regressed :-)

Really nice work, don't get beaten up because someone did it earlier or better; it's still a very valid learning experience.

This is neat. But what practical use is it?

It is basically a more nuanced version of the phylobinary tree [0] that was posted here a few days ago

[0] http://www.scott-a-s.com/phylobinary-trees/

> I don't really know if it will be useful in the future. But it's already fun to look over code...

Reply on news.ycombinator.com