Hacker News Reader

Comment by antonpirker | Hacker News Reader

Why should he/she want to find out?

"It worked different three months ago...". But I agree that this is no reason to gave to wade through commented out sections[1] but to simply use the powers of <vcs-of-choice> diff.

[1] Including if(0){} abominations

In my day job, I sometimes get told to make changes that I suspect will cause problems in some edge case which we might not see for months. It seems like the responsible thing to do is to leave the trustworthy version of the code there for the benefit of whoever has to fix the problem when the shit hits the fan.

I understand that reality is more complex than this, but

git bisect

That should identify the/your commit in (usually) < 10 tests. At which point the previous code is still intact.

git blame

and look at the problematic lines, see who changed it and when. Now look at the git log (filtered just for this file if you want) and identify the last changes to this part of code that way.

More complex than just

// timestamp, initials: Changed foo, commenting the following 100 lines out

maybe, but makes the day to day code so much more readable.

When the code was rewritten for efficiency. Whenever I read 'clever' code I wish I had an 'idiot' version that was written purely for me to understand.

So true. Whenever having to write a complicated code, I always keep a simple pseudo code in comments. That helps me both to understand later what I wanted to achieve, as well as help me focus on actual implementation details after figuring out he high level algorithm.

Reply on news.ycombinator.com