Hacker News Reader

Comment by Osiris | Hacker News Reader

Regarding dead (as in unused) code, I keep noticing the guys on my UI development team commenting out code and then committing it to Git. I remind them periodically that they can just delete the code and if they ever need it, they can use Git to pull up historical versions of the file for reference.

View on HN

The thing is that "you can always find it back with Git" only holds when you're pretty proficient with Git (or know where to click in a UI like SourceTree, and even that takes a while to figure out). Many people basically don't get much further than commit, push, pull. For them, deleting means they need to go and ask someone like you for help to get things back. Commenting keeps them in control.

A rule that I like that is 100% enforceable: commented code is allowed, but there needs to be a comment above the code explaining why the code was commented. The effect in practice of this rule is that

    - People delete code more and comment it less
    - Readers know whether to need to pay attention to the commented code or not.

Point 1 happens the most. I begin to write down something like "keeping this code around because I'm not sure yet whether the new code is better" and then I backspace and delete the whole thing because I realise it clearly is.

to be fair, I think commenting code in a sense "works better" then "git revert" because you don't need to solve conflicts, you just keep writing code around the commented one.

I rationally know that I can remove and re-add it later and that commit/revert is better, but the pain associated with solving conflicts is strong enough that I subconsciously want to avoid it.

I think some people prefer commenting over deleting on version-control - that way, they can see how this code used to look like in the past.

It would be nice to have an emacs or vim plugin in which you select a block of code, and it slowly walks back the graph of commits, showing each commit for 5 seconds. That way you could nicely see how your code-block evolved over time... (of course in many cases the code-block itself is useless without context)

Time-traveling git blame visualization could be rad too.

You can basically do this in vim with https://github.com/tpope/vim-fugitive

:Gblame to show a git blame sidebar, and P to open the file at that commit.

I achieve the same effect regularly with hgview /path/to/file you can watch how the file changes commit by commit. Surely there's something similar for git? http://www.hgview.org/

Well I think its an out of sight, out of mind kind of thing. Something commented out is generally something you know you'll want to be referencing again. Coming back to something in the future you/your teammates might not even remember/realize that the deleted code was ever there.

Eh, think of it like a cache. "You shouldn't keep that in memory, you can get it from disk." You can lean in that direction, but it doesn't make sense as a hard rule.

I use cache style metrics for killing code too.

E.g. I might start a rewrite with:

  #if BLEEDING_EDGE ...new code... #else ...old code... #endif

Eventually moving the old code into a further removed #if 0 as the remaining bugs taper off (i.e. I'll just fix them instead of reverting back to the old code for a milestone) before deleting the old code outright.

Much like evicting data from L1, L2, L3, and finally main memory.

Sometimes I'll even write explicit comments to delete code by a certain date.

I can understand where they're coming from but, for the life of me, I can't recall the last time I needed to restore such code after a long gap. If the code's that interesting, they can either leave it on a feature branch or refactor it out into a reusable module or the like.

Second that, usually I see worthless snippets commented out. Those are good as reference for a couple of hours when you work on the code but when you are done the commented code is lie and new code is truth. Also I cannot imagine working on a piece of code without looking at git history to get context (commit messages linked issues in tracker) in this way commented code from past has no value for me at all.

The main problem I find is - when you decide you need to recall that deleted code, where will I find it?

In the repo.

With Git, I find the pickaxe tool ("git log -S") to be useful for this purpose. From the man page:

-S<string>

    Look for differences that change the number of occurrences of the specified string (i.e. addition/deletion) in a file. Intended for the scripter’s use.

    It is useful when you’re looking for an exact block of code (like a struct), and want to know the history of that block since it first came into being: use the feature iteratively to feed the interesting block in the preimage back into -S, and keep going until you get the very first version of the block.

Reply on news.ycombinator.com