17 ms·

Please do not delete this commented-out version

413 points by jordigh 11y ago

Havoc 11y ago
:( Disappointed. I was expecting a story along the lines of the "Magic / More Magic button" story. edit http://catb.org/jargon/html/magic-story.html http://catb.org/jargon/html/magic-story.html
- chc4 11y ago
  Same. I've heard some horror stories about programs failing to compile if you switch independent lines around or, even worst, remove some comments. Thought it would be one of those!
  - LukeShu 11y ago
    If you want a short one: It's not too hard to get flex to switch from generating compiling code to non-compiling code by removing a comment. The secret is in if the comment is "interpreted" by flex or the compiler, even thought they should both be the same.
    - dugmartin 11y ago
      I was hit with a flex compiler bug on a large project days away from a deadline. I think it was due to either the depth or shape of the ast as I was able to get it to finally compile by reordering the functions in the class. Then I added more code and broke it again.
  - a_t48 11y ago
    There are certain places in the code where I work that fail to compile if you remove whitespace\comments - there are some static variables in macros that use __LINE__ as the unique portion of the identifier - moving them around might conflict with another definition, causing multiply defined symbols.
    - kbart 11y ago
      "there are some static variables in macros that use __LINE__ as the unique portion of the identifier" Now that's a horror story, I hope I will never have to work with such code.
  - donatj 11y ago
    Once on an old TI machine my friends code continually acted oddly. BASIC. We tried and tried to debug it. We got it down to a single if statement after pondering for several minutes I erased the equality `=`, put it back, and ran it. Pure grasping at straws. Works perfectly. To this day I can't explain the magic equals. This thing had a very limited character set so a visually identical glyph is out of the question. This magical equals haunts me to this day.
    - varjag 11y ago
      I remember in some of 8-bit BASICs there were "color codes". Basically, invisible escape sequences, which could be however interpreted as numbers if encountered in the source text. Could be something along those lines.
    - pgeorgi 11y ago
      Old BASIC implementations often stored the code in a tokenized form to reduce the memory the code needs and to slightly speed up interpretation. One fun issue on C64's BASIC was that you could force the interpreter to not tokenize lines, but they were printed verbatim on "list" - totally invisible to the user. Printing the line, then having BASIC parse the same output fixed the issue. Although the error was pretty obvious IIRC (some fatal interpreter error aborting operation). I'm not sure what the TI machines did. There may have been some odd tokenization error in that line and by rewriting it, you kicked off the parser which made the bug go away.
  - vidarh 11y ago
    For compiling it's rare (though pre-processor abuse is a good way of creating evil messes like that). But totally changing runtime behaviour with seemingly unrelated code changes is usually a good indicator that you've managed to trash the stack. A compiler that manages to trash its stack, now that has potential for some extreme levels of frustration.
  - versteegen 11y ago
    That sort of thing has happened to me many times while using FreeBASIC. A few years ago the FB compiler was still young and had a myriad of bugs lurking in corner cases; I've encountered dozens of compiler crashes, strange interactions between unrelated bits of code that produced nonsensical error messages and fixed by rearranging, parsing and lexing bugs, including the lexer accepting the most remarkably garbled input, especially when I tried writing a PEG grammar for FB. Also, the preprocessor is pretty nice - looks like C's but with vastly better semantics, and if you find a bug in it, you can exploit it for even more advanced constructs! :) Like how // in early C behaved like the non-existent-at-the-time ## operator. 'STRANGE: For some reason I have to add a comment here or FreeBasic 0.24-pre doesn't compile it I've even seen what donatj said, of changing the source and then changing it back in order to remove an error. That sort of thing is generally a problem with the build system not producing reproducible results, such as not files not being recompiled when necessary. Since I have my own DSL that spits out FB code, and the FB code produced in different modules can have hidden conflicts, I've actually seen that one multiple times (my own fault). Really, the amazing thing is that just a few years later FB is actually pretty stable. I don't mean to put it down; I'm quite impressed with their work.
jheriko 11y ago
maybe a long time ago this was a sensible function to have... but i wonder why this is here at all? myself from the 1990s would wonder as well. file i/o functions in the c standard library make this a pointless exercise today... emacs. an anachronism made of other anachronisms...
steyh 11y ago
Why would you leave old code commented out when you can easily look at earlier versions of code with you source code manager?
- schoen 11y ago
  The comment itself addresses that: it says people will forget that it exists.
  - aaronbrethorst 11y ago
    The GP's point still stands. Just because the comment offers an explanation doesn't mean it's right.
    - Azkar 11y ago
      I feel like there is a big difference between "right" and practical. The world isn't black and white, the authors clearly have had problems when the comment was removed, so it's probably better to just keep it there. I personally hate when commented out code are checked in to source, but put in a situation where the "right" thing increases the likelihood human error, I'll pick the "wrong" way every time.
      - aaronbrethorst 11y ago
        How about a smaller comment that says something like: /* Here's the deal...Check out what this used to look like at http://example.com. */
        gsb 11y ago
        Except in this case, when the comment was written http hadn't been invented yet :)
        joepvd 11y ago
        We have a winner of this discussion!
craigds 11y ago
This doesn't seem all that awful. If the old code is significantly more readable, then perhaps it serves as good documentation about the new code. It is somewhat surprising that this would last 30 years though. In our huge codebase, barely any lines have survived 8 years. Even less so the comments.
- choward 11y ago
  No matter how I look at this, it is terrible. If this is okay, where do you draw the line? How do I know which commented out code is okay to commit and which isn't? I understand the point of doing it, but there are many other solutions that are all better.
  - ajuc 11y ago
    > If this is okay, where do you draw the line? This argument can be used to ban anything. Where do you draw the line? Jokes aside, one possible line is "it should make sense after a while of considering alternative solutions".
  - marcoperaza 11y ago
    >How do I know which commented out code is okay to commit and which isn't? By exercising judgment. Thank God that's still required, else we'd be out of a job ;)
- throwaway2048 11y ago
  The actual lines themselves may not have changed much in your codebase, but unless you are diciplined about stuff like not introducing whitespace change noise, its very easy to rototill an entire codebase over a peroid of years.
  - nitrogen 11y ago
    Using git add -p helps immensely with this, since it highlights trailing whitespace in red and each change can be approved separately. It takes a few days at most to get used to using the -p flag, and it's worth it.
sergiotapia 11y ago
That source code looks HORRIBLE. Is it just because of the language or because the person who wrote had no other choice? http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4887597a1c52b8277eabeb4d9484c75b1bc9429d http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=488759... It must have been done for a reason right, emacs is incredibly old in tech years and solid as a rock.
- sputnik27 11y ago
  Oh, god, so awful. All those ifdefs.. Funny: Tried to find the comment commenting it out. I found it. #IF 0. Wow.
  - jff 11y ago
    That's a pretty standard way to comment out a huge chunk of code, because /* */ will get screwed up if there's another comment using the same convention inside, and putting // in front of every single line looks bad/makes copying code around painful. #if 0 is also a convenient way to flip bits of test/debug code on and off.
    - provemewrong 11y ago
      That's actually neat! Haven't touched C/C++ beyond university and didn't know about that.
  - kbart 11y ago
    #if 0 <...> #else <...> #endif Is a pretty standard way to switch between new/old code while refactoring to check if behavior/output matches. Just change 0 to 1 to switch between "versions".
- noobermin 11y ago
  FWIW, I've seen worse code in closed source, computational codes. Still, I always thought GNU were in a better category than the rest of us.
  - 11y ago
carussell 11y ago
A while back, I found the following amusing comment in the source to GNU tar:[1] /* Parse base-64 output produced only by tar test versions 1.13.6 (1999-08-11) through 1.13.11 (1999-08-23). Support for this will be withdrawn in future releases. */ I did some digging then and found at that it had been introduced in a commit that was (at that time) almost 10 years old, to the day.[2] 1. http://git.savannah.gnu.org/cgit/tar.git/tree/src/list.c?id=445293654d92a1dabb04255547730b35c5cde387#n829 http://git.savannah.gnu.org/cgit/tar.git/tree/src/list.c?id=... 2. http://git.savannah.gnu.org/cgit/tar.git/commit/?id=e4e624848b53ac02f1212af2209a63d28e40afec http://git.savannah.gnu.org/cgit/tar.git/commit/?id=e4e62484...
stevebmark 11y ago
Committing commented out code means you don't know how to use your version control system. A comment with hash of the commit of the old code, or a command to show an older version of the file using your vcs system, is much better, and more team-friendly.
- lqdc13 11y ago
  Sure but then you switch Version Control systems later and the hash/vcs command may not mean anything.
  - nailer 11y ago
    I wasn't around when rcs was a thing, but cvs to svn and svn to git preserved history.
    - revelation 11y ago
      It will automagically scan through all files and replace what looks like a revision number with the correct git hash?
      - asdfaoeu 11y ago
        I don't know about the cvs to svn migration but migrating from git to svn you generally can keep the original svn commit numbers in the history such that you can look up svn revision numbers like that.
        jheriko 11y ago
        he means replacing comments mentioning revision numbers. no source control migration does this - it would be harmful if done unchecked (revision numbers like 1 will turn into compile errors or very confused comments in the most naive implementation, for example)
  - LukeShu 11y ago
    Exactly. Emacs has changed VCS at least 4 times since the code was commented out. (pre-RCS (no VCS?) -> RCS -> CVS -> bzr -> git) I've had codebases with references to bug IDs... from 3 bug trackers ago.
Justsignedup 11y ago
Funny how the emacs vs vim battle ended: "VIM is the worst written software in existence today. So we deleted a ton of it and rewrote it as neovim"... Waiting on neoemacs.
- microcolonel 11y ago
  Emacs has pretty decent code quality. Contributing is also still doable, unlike with VIM. NeoVIM is mainly about the personal cost of contributing to VIM, protection of ancient platforms, etc. Emacs doesn't have these problems for a contributor.
- deleted 11y ago
  [deleted]
- teddyh 11y ago
  > Waiting on neoemacs You mean Guile Emacs: http://www.emacswiki.org/emacs/GuileEmacs http://www.emacswiki.org/emacs/GuileEmacs
- krylon 11y ago
  There is an editor, zile I think, that started out as a lightweight emacs clone but was eventually rewritten to be to Lua what GNU Emacs / XEmacs is to Lisp. I am not sure how far along they are, but I like the idea, because Lua is a really sweet language for this kind of task.
amichal 11y ago
For all the folks saying the comment itself is bad... Please explain why? All i can think is that adding a date and author might be nice so the current maintainers can give some thought to if we care about those old subtle bugs x decades later without digging through 3+ changes (guess) to version control systems.
- pyre 11y ago
  Well, the other question is does it even need to be in the code? Could there be a documentation / spec file somewhere that uses this code as the reference implementation, and just add a comment that says "see spec file" next to the code?
  - pbalau 11y ago
    After 15+ years writing software, I can guarantee you that keeping 2 files in sync (eg the source file linked to the spec file) for more than foo days is not going to happen.
- lmm 11y ago
  Trying to use this to catch subtle bugs is the worst kind of "the implementation is the spec". If you can't document what it does except in executable code, you don't understand what it does, and you need to go back to requirements gathering and then write some tests for the important cases. Or, better still, write the actual code in a way that's readable and expresses the intent.
Nelson69 11y ago
It is possible, or even likely, that a repository switch could lose that history on a project like emacs. Guile now has an elisp interpreter and guile itself has JIT capabilities as well as a number of other features elisp hackers have grumbled about over the years. It's been mostly one man's work but it has spanned years to get guile-elisp to where it is. The discussions about migrating to it have been somewhat interesting to read. You have a remarkably solid, cross platform, well tested product and they're very very cautious to harm that, even with big speed and feature improvements on the table. It's one of the few good examples of "maybe you want to think twice about fixing something that isn't broken." Then when/if they do fix it, I bet you'll be able to build it with the old elisp for 20 years, just in case something isn't quite right...
- zephod 11y ago
  > It is possible, or even likely, that a repository switch could lose that history on a project like emacs. Surely the "D" in DVCS means that many thousands of copies of the project history would be available around the world?
  - LukeShu 11y ago
    When the code was commented out, it would be several decades before Emacs would be switched in to a DVCS, then another 7 years from when the "please don't delete this" comment was added. Even if it was in the DVCS history, and there was a comment pointing to a commit ID, that would have been rendered nonsensical by the conversion from bzr to git.
    - paulddraper 11y ago
      Nonsensical, but still accessible
    - philh 11y ago
      I'd be somewhat surprised if the bzr->git conversion did in fact mess those up. I was following ESR's blog when he was doing the conversion. He seemed to feel very strongly that the conversion should not mess things up like that. (His goal was that the history should look like it would have done, if people had always been using git.) On the other hand, I'm less confident about the conversion to bzr. And anyway the relevant question is not "would it have broken?" but "did people have reason to expect it would break?" And on the third hand, a commit id could be referenced by author and timestamp, which would be invariant under (competent) repo conversions.
Walkman 11y ago
There are tens of thousands of lines commented out in the codebase at my company... When I say "We should delete all of them" they defend "it will be good sometime" LOL. That's why we have a 500k LOC codebase and developing a feature takes weeks and months instead of days. I'm not allowed to refactor...
- theophrastus 11y ago
  As something of a computational geneticist, i really appreciate this comment. because there are exon sequences in DNA, which are expressed as mRNA and often translated to proteins -- let's say "compiled"; and intron sequences which are spliced away and currently unused. However introns are the stuff of past and future genes and controls, just like lines of code commented out. They are like boxes of stuff in your attic, currently not used, but very handy when conditions change.
  - jheriko 11y ago
    and just like life you pay for it by having to maintain and copy all of that extra genetic mass... much as the programmer pays by having more content to navigate, where most of it is not part of the program code.
    - mc808 11y ago
      And by the time you uncomment it, the rest of the organism/code has mutated so much that the legacy snippet does something totally surprising or even destructive.
      - deleted 11y ago
        [deleted]
    - XorNot 11y ago
      I have this argument with people about comments in configuration files on production systems. Their argument is "it explains the configuration". My argument is that it's more important to be able to quickly see what configuration is actually applied (which usually fits in a terminal window without scrolling) then it is to redundantly store help-text on the server (which also makes it hard to read what is enabled).
giberson 11y ago
>we leave this version here commented-out, because the code is very complex and likely to have subtle bugs. If bugs _are_ found, it might be of interest to look at the old code and see what did it do in the relevant situation. Here are two better alternative solutions: * comments (in natural language not code) that describe what the code should do * test cases: to dictate what code should do and prove it does do it
- bastawhiz 11y ago
  It's a bit ironic that there's a longer comment describing why the code shouldn't be removed than there are comments describing what the code _actually does_ or _why_ inline.
- pyre 11y ago
  You missed: * Comments referencing the original code by date / version / commit id. Date and version are relevant because the comment might not get updated if there is ever another VCS migration.
- Johnny555 11y ago
  That might be workable idea if the guy writing the replacement code has such a perfect understanding of the original code that he can spell out every assumption and edge condition that the code covers (as well as write tests to cover all conditions). The best you can hope for is comments and tests that cover the new author's impression of what the old code was doing, which is not necessarily the same as what the old code did. In this case, since he apparently doesn't feel that he has that perfect understanding, he left the original code there, so when someone says "Hey! I counted on behavior XXX, this change broke my workflow!". And any change no matter how trivial or "correct" always breaks someone's workflow. https://xkcd.com/1172/ https://xkcd.com/1172/
- ajross 11y ago
  That's the kind of smug naivete that makes young programmers so insufferable. Your use of "should" in your two sentences is a hidden, inappropriate abstraction. You're positing the existence of a "correct design" for expand-file-name and working backwards to how you'd write it in a modern ground-up development project. The actual problem at hand was rewriting that function in a way that doesn't break the uncounted thousands of usages in the wild, which depend on the self-described "complex and likely to have subtle bugs" original implementation.
gonyea 11y ago
If you think this is crazy, never ~ever~ look at what Mainframes are running.
- jdcskillet 11y ago
  I was just thinking the same thing... We have lines of commented out code from 1988 (yes. that is a correct date) that people flat out refuse to delete. I am so glad I got out of that mess...
  - krylon 11y ago
    In all fairness, I have had to touch somebody else's code on a few occasions where they did not use any kind of VCS, and I was very reluctant to flat out delete code, so I did the same thing described in the linked page - comment out the original code and add an explanation why I replaced or removed it, along with a date. And when reading somebody else's code, I tend to appreciate if the code carries its history with it, at least to a degree. What I really do not like, though, is when there is a piece of commented-out code with no explanation of why it's there in the first place or why it was commented out.
makecheck 11y ago
Generally I find all copies to be bloat. Seeing the original code will not necessarily explain old behavior. When you make a copy, how much are you planning to copy? To debug ancient code that calls 5 functions, you might need access to the histories of those 5 functions; and the histories of any functions they call, and heck maybe you only saw correct behavior on a certain OS or with certain input (none of which you may have access to). If you don't have all those histories, the "correct old code" you are looking at may even lie to you, as it suggests it is calling functions you think you are familiar with but those functions have changed in some important way. After enough time passes — and at the rate this industry moves, time is short — the only thing that really matters is whether or not the program currently does what its current users require. And if it doesn't, you define what behavior you need it to have and find a way to fix it.
sxates 11y ago
My question is - has anyone needed to refer back to the old code in the last 30 years? I can understand wanting to have the old code around for easy reference in case you need to debug the refactored version, but if no bugs have come up in the last 30 years (or even, say, the last 5), it seems pretty safe to say the new code is solid.
- cfcef 11y ago
  Another question: is the old code even valid in any sense compared to the current code? Since the original was written before 1985, then 99.9% of the people running Emacs will be running it on an OS that did not exist in any form in 1985 (Linux, Mac OS X, Windows, Android, etc) and the rest will be running on OSes which have changed substantially or been replaced entirely since then (SunOS->Solaris).
  - kbart 11y ago
    That's the beauty of C -- you don't have to rely on OS, so a code written 30 years ago is still working today.
    - cfcef 11y ago
      Of course C relies on an OS. The point of an OS is securely mediating access to resources; a C program is going through the OS, using syscalls, in order to do stuff like 'write a file'. Which bears a certain resemblance to what this code is doing...
      - kbart 11y ago
        Let me repeat myself -- "you don't have to". C runs well on bare metal, that's why most bootloaders, kernels and low level drivers use it. Of course, you can make as many dependencies as you wish, but unlike high level languages, C doesn't rely on OS for it's core features.
      - deleted 11y ago
        [deleted]
lanstein 11y ago
lol #ifdef VMS[0] [0] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4887597a1c52b8277eabeb4d9484c75b1bc9429d http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=488759...
mrfusion 11y ago
I think ides should have a really easy way to see old code. I'm thinking like arrow buttons next to each function and you can browse though older versions. It's true in theory all your old code is stored in vcs but it's such a bear to actually go look at it.
- voltagex_ 11y ago
  I can imagine an OSX Time Machine style interface to Git that would be quite cool.
  - phaer 11y ago
    Like https://github.com/pidu/git-timemachine https://github.com/pidu/git-timemachine for emacs?
- lotyrin 11y ago
  Does your IDE not?
  - mrfusion 11y ago
    Not in one or two clicks away in a way that doesn't take my focus away from what I'm looking at.
    - lotyrin 11y ago
      It's Context menu -> Git -> Show history for function in Jetbrains products. Gives all the commits with changes inside the function, shows each one side-by-side.
      - thecatspaw 11y ago
        oh wow, very neat. Thanks
- ChristianBundy 11y ago
  Git blame?
stcredzero 11y ago
There are places in Smalltalk code where you see: false ifTrue: [ "Some code to debug to help understand..." ]. In VisualWorks, you can double-click next to the 1st square bracket to select the code, then instantly execute it or debug it. The reason why it's not simply commented out, is that automated refactorings in the Smalltalk Refactoring Browser can then touch the commented-out code. (St RB used to be guaranteed to always execute strict refactorings and produce correct code.) Often such code can even use values from the current scope, so a separate debug session can be spawned to see what it "would have been like" then dismissed with no consequences. It's stuff like that which made Smalltalk an uber-environment back in the day.
- matthavener 11y ago
  In clojure, you see something similar at the bottom of files: (comment (def some-state (create-state)) (some-fn [1 2 3]) (do-something some-state) ) The compiler ignores the block, but in a REPL enabled editor, you can evaluate the forms to possibly view current state, or run functions that test behaviors or probe runtime state.
  - krat0sprakhar 11y ago
    Or the equivalent #_(def some-state (create-state)) (some-fn [1 2 3]) (do-something some-state))
    - vijaykiran 11y ago
      I guess you meant: #_((def some-state (create-state)) (some-fn [1 2 3]) (do-something some-state)) oh, and you can't have "invalid" code in (comment), but in #_ you can.
      - okal 11y ago
        #_ comments out the form it precedes. You do not need to surround it with an extra pair of parentheses. Didn't know about the difference in behaviour with regard to invalid code. Thanks for that. EDIT: Leaving this here for context. I'd missed the fact that they weren't all enclosed in a single form to begin with. Parent's solution is correct in light of that.
jonathaneunice 11y ago
Modern version control systems (Git, Hg, etc.) do a great job of storing file commits. They're very "flat," however. A file is a file is a file, and there's no good mechanism for storing tightly-linked documentation about the evolution of a project. Commented-out code is just one ad hoc way developers try to tack on that kind of information (often in clumsy, likely-to-be-obsoleted-or-forgotten ways).
mtanski 11y ago
There's an exception to every rule, like in this case. It drives me perpetually batty when folks blindly stick to process, best practices, convention even when it doesn't make sense.
kazinator 11y ago
Yes, if the function breaks, do we care what some code did in the same situation that was removed 30 years ago? I mean, let's look at it like this: does the author of the removed code have a vote in what should happen, through the comment? If it's so important, why was it removed? How do we even know that the new code did something wrong? We do not know that in relation to the old function; we know that in relation to some modern criterion. Maybe it completely bombs (irrelevant that the old code didn't bomb, or whether or not it did), or that returns some result someone doesn't like (without regard for what the old code did), or that violates some documentation. We can decide today what the code should do, and fix it, or its specification or both.
chris_wot 11y ago
If you think that's bad, try looking at the LibreOffice source code. I think I found a 15 year old bug the other day [1] [2], but I only noticed this when I was trawling through the history of the file "outdev3.hxx", which via cgit was a pain in its own right. There have, in fact, been 5 source code repository switches in LibreOffice over the last 30 years. [3] It started with some sort of proprietary version from 1988 to 2000 so there is no history at all from this period (which I think is a great loss...), from 2000 to 2009 they used CVS, then from 2008 to 2009 they used SVN, then from 2009 to 2011 it was Mercurial, then from 2011 to 2014 it was back to SVN, and LibreOffice started using git from the very start. One of the worst practices that the OpenOffice.org team had was to get a whole bunch of work, bundle it up into a single commit and then note that there were multiple fixes in the commit. This makes it nigh-on impossible to untangle what fixed what. They apparently branched in SVN, then took the branch and merged it, but then blatted the original branch so now this is all lost in history. And if you've ever read some of the most crufty parts of LibreOffice (cough VCL cough) then you'd understand that actually reading good commits is really very important for moments you think "what on EARTH is that code doing?!?"... 1. https://bugs.documentfoundation.org/show_bug.cgi?id=96826 https://bugs.documentfoundation.org/show_bug.cgi?id=96826 2. http://randomtechnicalstuff.blogspot.com.au/2016/01/possible-15-year-old-regression.html http://randomtechnicalstuff.blogspot.com.au/2016/01/possible... 3. https://archive.fosdem.org/2014/schedule/event/exploring_openoffice_history_using_git_grafts/ https://archive.fosdem.org/2014/schedule/event/exploring_ope...
Tinned_Tuna 11y ago
I'm surprised that we're still using this as a bit of a hack in the future. In the project I'm working on, when we substantially optimise a section of code, we move the un-optimised, believed-good, version. It becomes an oracle against which the optimised version is tested on both manually and randomly generated test cases. I'm not saying that the above solution should have been deployed at the time, but perhaps it could be moved in that direction now that we have these techniques and tools to hand. Could such a solution work well here? Perhaps, it would be even more useful, as tests would be likely to fail if the optimisation was bad, rather than just assisting with debugging after the fact.
V-2 11y ago
Yes, VCS doesn't give you a guarantee of storing your history (in an accessible way, I mean - "if a tree falls in a forest...") FOREVER, especially if you switch VCS systems on the way. However, commenting some code out also doesn't mean it won't rot. Methods/procedures around it will be refactored, variables renamed - in long time perspective, in a different landscape it can become incomprehensible and useless anyway. Just because some abstraction (version control) can be a bit leaky and one shouldn't rely on it absolutely, doesn't justify succumbing to some other illusion. Commenting code out is not equal to hibernation and it doesn't make it immune to flowing time. You uncomment it one day, you discover it stinks to heaven high - especially if it was complex from the start - and isn't informative at all. "But that's not the case here!" - well, guess what: version control failing to do what it's supposed to also isn't the case here, if you can still access commits from 1986, as someone pointed out: http://git.savannah.gnu.org/cgit/emacs.git/log/?ofs=124080 http://git.savannah.gnu.org/cgit/emacs.git/log/?ofs=124080

413 points by jordigh 11y ago

Havoc 11y ago

:( Disappointed. I was expecting a story along the lines of the "Magic / More Magic button" story. edit http://catb.org/jargon/html/magic-story.html http://catb.org/jargon/html/magic-story.html

chc4 11y ago
Same. I've heard some horror stories about programs failing to compile if you switch independent lines around or, even worst, remove some comments. Thought it would be one of those!
- LukeShu 11y ago
  If you want a short one: It's not too hard to get flex to switch from generating compiling code to non-compiling code by removing a comment. The secret is in if the comment is "interpreted" by flex or the compiler, even thought they should both be the same.
  - dugmartin 11y ago
    I was hit with a flex compiler bug on a large project days away from a deadline. I think it was due to either the depth or shape of the ast as I was able to get it to finally compile by reordering the functions in the class. Then I added more code and broke it again.
- a_t48 11y ago
  There are certain places in the code where I work that fail to compile if you remove whitespace\comments - there are some static variables in macros that use __LINE__ as the unique portion of the identifier - moving them around might conflict with another definition, causing multiply defined symbols.
  - kbart 11y ago
    "there are some static variables in macros that use __LINE__ as the unique portion of the identifier" Now that's a horror story, I hope I will never have to work with such code.
- donatj 11y ago
  Once on an old TI machine my friends code continually acted oddly. BASIC. We tried and tried to debug it. We got it down to a single if statement after pondering for several minutes I erased the equality `=`, put it back, and ran it. Pure grasping at straws. Works perfectly. To this day I can't explain the magic equals. This thing had a very limited character set so a visually identical glyph is out of the question. This magical equals haunts me to this day.
  - varjag 11y ago
    I remember in some of 8-bit BASICs there were "color codes". Basically, invisible escape sequences, which could be however interpreted as numbers if encountered in the source text. Could be something along those lines.
  - pgeorgi 11y ago
    Old BASIC implementations often stored the code in a tokenized form to reduce the memory the code needs and to slightly speed up interpretation. One fun issue on C64's BASIC was that you could force the interpreter to not tokenize lines, but they were printed verbatim on "list" - totally invisible to the user. Printing the line, then having BASIC parse the same output fixed the issue. Although the error was pretty obvious IIRC (some fatal interpreter error aborting operation). I'm not sure what the TI machines did. There may have been some odd tokenization error in that line and by rewriting it, you kicked off the parser which made the bug go away.
- vidarh 11y ago
  For compiling it's rare (though pre-processor abuse is a good way of creating evil messes like that). But totally changing runtime behaviour with seemingly unrelated code changes is usually a good indicator that you've managed to trash the stack. A compiler that manages to trash its stack, now that has potential for some extreme levels of frustration.
- versteegen 11y ago
  That sort of thing has happened to me many times while using FreeBASIC. A few years ago the FB compiler was still young and had a myriad of bugs lurking in corner cases; I've encountered dozens of compiler crashes, strange interactions between unrelated bits of code that produced nonsensical error messages and fixed by rearranging, parsing and lexing bugs, including the lexer accepting the most remarkably garbled input, especially when I tried writing a PEG grammar for FB. Also, the preprocessor is pretty nice - looks like C's but with vastly better semantics, and if you find a bug in it, you can exploit it for even more advanced constructs! :) Like how // in early C behaved like the non-existent-at-the-time ## operator. 'STRANGE: For some reason I have to add a comment here or FreeBasic 0.24-pre doesn't compile it I've even seen what donatj said, of changing the source and then changing it back in order to remove an error. That sort of thing is generally a problem with the build system not producing reproducible results, such as not files not being recompiled when necessary. Since I have my own DSL that spits out FB code, and the FB code produced in different modules can have hidden conflicts, I've actually seen that one multiple times (my own fault). Really, the amazing thing is that just a few years later FB is actually pretty stable. I don't mean to put it down; I'm quite impressed with their work.

jheriko 11y ago

maybe a long time ago this was a sensible function to have... but i wonder why this is here at all? myself from the 1990s would wonder as well. file i/o functions in the c standard library make this a pointless exercise today... emacs. an anachronism made of other anachronisms...

steyh 11y ago

Why would you leave old code commented out when you can easily look at earlier versions of code with you source code manager?

schoen 11y ago
The comment itself addresses that: it says people will forget that it exists.
- aaronbrethorst 11y ago
  The GP's point still stands. Just because the comment offers an explanation doesn't mean it's right.
  - Azkar 11y ago
    I feel like there is a big difference between "right" and practical. The world isn't black and white, the authors clearly have had problems when the comment was removed, so it's probably better to just keep it there. I personally hate when commented out code are checked in to source, but put in a situation where the "right" thing increases the likelihood human error, I'll pick the "wrong" way every time.
    - aaronbrethorst 11y ago
      How about a smaller comment that says something like: /* Here's the deal...Check out what this used to look like at http://example.com. */
      - gsb 11y ago
        Except in this case, when the comment was written http hadn't been invented yet :)
      - joepvd 11y ago
        We have a winner of this discussion!

craigds 11y ago

This doesn't seem all that awful. If the old code is significantly more readable, then perhaps it serves as good documentation about the new code. It is somewhat surprising that this would last 30 years though. In our huge codebase, barely any lines have survived 8 years. Even less so the comments.

choward 11y ago
No matter how I look at this, it is terrible. If this is okay, where do you draw the line? How do I know which commented out code is okay to commit and which isn't? I understand the point of doing it, but there are many other solutions that are all better.
- ajuc 11y ago
  > If this is okay, where do you draw the line? This argument can be used to ban anything. Where do you draw the line? Jokes aside, one possible line is "it should make sense after a while of considering alternative solutions".
- marcoperaza 11y ago
  >How do I know which commented out code is okay to commit and which isn't? By exercising judgment. Thank God that's still required, else we'd be out of a job ;)
throwaway2048 11y ago
The actual lines themselves may not have changed much in your codebase, but unless you are diciplined about stuff like not introducing whitespace change noise, its very easy to rototill an entire codebase over a peroid of years.
- nitrogen 11y ago
  Using git add -p helps immensely with this, since it highlights trailing whitespace in red and each change can be approved separately. It takes a few days at most to get used to using the -p flag, and it's worth it.

sergiotapia 11y ago

That source code looks HORRIBLE. Is it just because of the language or because the person who wrote had no other choice? http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4887597a1c52b8277eabeb4d9484c75b1bc9429d http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=488759... It must have been done for a reason right, emacs is incredibly old in tech years and solid as a rock.

sputnik27 11y ago
Oh, god, so awful. All those ifdefs.. Funny: Tried to find the comment commenting it out. I found it. #IF 0. Wow.
- jff 11y ago
  That's a pretty standard way to comment out a huge chunk of code, because /* */ will get screwed up if there's another comment using the same convention inside, and putting // in front of every single line looks bad/makes copying code around painful. #if 0 is also a convenient way to flip bits of test/debug code on and off.
  - provemewrong 11y ago
    That's actually neat! Haven't touched C/C++ beyond university and didn't know about that.
- kbart 11y ago
  #if 0 <...> #else <...> #endif Is a pretty standard way to switch between new/old code while refactoring to check if behavior/output matches. Just change 0 to 1 to switch between "versions".
noobermin 11y ago
FWIW, I've seen worse code in closed source, computational codes. Still, I always thought GNU were in a better category than the rest of us.
- 11y ago

carussell 11y ago

A while back, I found the following amusing comment in the source to GNU tar:[1] /* Parse base-64 output produced only by tar test versions 1.13.6 (1999-08-11) through 1.13.11 (1999-08-23). Support for this will be withdrawn in future releases. */ I did some digging then and found at that it had been introduced in a commit that was (at that time) almost 10 years old, to the day.[2] 1. http://git.savannah.gnu.org/cgit/tar.git/tree/src/list.c?id=445293654d92a1dabb04255547730b35c5cde387#n829 http://git.savannah.gnu.org/cgit/tar.git/tree/src/list.c?id=... 2. http://git.savannah.gnu.org/cgit/tar.git/commit/?id=e4e624848b53ac02f1212af2209a63d28e40afec http://git.savannah.gnu.org/cgit/tar.git/commit/?id=e4e62484...

stevebmark 11y ago

Committing commented out code means you don't know how to use your version control system. A comment with hash of the commit of the old code, or a command to show an older version of the file using your vcs system, is much better, and more team-friendly.

lqdc13 11y ago
Sure but then you switch Version Control systems later and the hash/vcs command may not mean anything.
- nailer 11y ago
  I wasn't around when rcs was a thing, but cvs to svn and svn to git preserved history.
  - revelation 11y ago
    It will automagically scan through all files and replace what looks like a revision number with the correct git hash?
    - asdfaoeu 11y ago
      I don't know about the cvs to svn migration but migrating from git to svn you generally can keep the original svn commit numbers in the history such that you can look up svn revision numbers like that.
      - jheriko 11y ago
        he means replacing comments mentioning revision numbers. no source control migration does this - it would be harmful if done unchecked (revision numbers like 1 will turn into compile errors or very confused comments in the most naive implementation, for example)
- LukeShu 11y ago
  Exactly. Emacs has changed VCS at least 4 times since the code was commented out. (pre-RCS (no VCS?) -> RCS -> CVS -> bzr -> git) I've had codebases with references to bug IDs... from 3 bug trackers ago.

Justsignedup 11y ago

Funny how the emacs vs vim battle ended: "VIM is the worst written software in existence today. So we deleted a ton of it and rewrote it as neovim"... Waiting on neoemacs.

microcolonel 11y ago
Emacs has pretty decent code quality. Contributing is also still doable, unlike with VIM. NeoVIM is mainly about the personal cost of contributing to VIM, protection of ancient platforms, etc. Emacs doesn't have these problems for a contributor.
deleted 11y ago
[deleted]
teddyh 11y ago
> Waiting on neoemacs You mean Guile Emacs: http://www.emacswiki.org/emacs/GuileEmacs http://www.emacswiki.org/emacs/GuileEmacs
krylon 11y ago
There is an editor, zile I think, that started out as a lightweight emacs clone but was eventually rewritten to be to Lua what GNU Emacs / XEmacs is to Lisp. I am not sure how far along they are, but I like the idea, because Lua is a really sweet language for this kind of task.

amichal 11y ago

For all the folks saying the comment itself is bad... Please explain why? All i can think is that adding a date and author might be nice so the current maintainers can give some thought to if we care about those old subtle bugs x decades later without digging through 3+ changes (guess) to version control systems.

pyre 11y ago
Well, the other question is does it even need to be in the code? Could there be a documentation / spec file somewhere that uses this code as the reference implementation, and just add a comment that says "see spec file" next to the code?
- pbalau 11y ago
  After 15+ years writing software, I can guarantee you that keeping 2 files in sync (eg the source file linked to the spec file) for more than foo days is not going to happen.
lmm 11y ago
Trying to use this to catch subtle bugs is the worst kind of "the implementation is the spec". If you can't document what it does except in executable code, you don't understand what it does, and you need to go back to requirements gathering and then write some tests for the important cases. Or, better still, write the actual code in a way that's readable and expresses the intent.

Nelson69 11y ago

It is possible, or even likely, that a repository switch could lose that history on a project like emacs. Guile now has an elisp interpreter and guile itself has JIT capabilities as well as a number of other features elisp hackers have grumbled about over the years. It's been mostly one man's work but it has spanned years to get guile-elisp to where it is. The discussions about migrating to it have been somewhat interesting to read. You have a remarkably solid, cross platform, well tested product and they're very very cautious to harm that, even with big speed and feature improvements on the table. It's one of the few good examples of "maybe you want to think twice about fixing something that isn't broken." Then when/if they do fix it, I bet you'll be able to build it with the old elisp for 20 years, just in case something isn't quite right...

zephod 11y ago
> It is possible, or even likely, that a repository switch could lose that history on a project like emacs. Surely the "D" in DVCS means that many thousands of copies of the project history would be available around the world?
- LukeShu 11y ago
  When the code was commented out, it would be several decades before Emacs would be switched in to a DVCS, then another 7 years from when the "please don't delete this" comment was added. Even if it was in the DVCS history, and there was a comment pointing to a commit ID, that would have been rendered nonsensical by the conversion from bzr to git.
  - paulddraper 11y ago
    Nonsensical, but still accessible
  - philh 11y ago
    I'd be somewhat surprised if the bzr->git conversion did in fact mess those up. I was following ESR's blog when he was doing the conversion. He seemed to feel very strongly that the conversion should not mess things up like that. (His goal was that the history should look like it would have done, if people had always been using git.) On the other hand, I'm less confident about the conversion to bzr. And anyway the relevant question is not "would it have broken?" but "did people have reason to expect it would break?" And on the third hand, a commit id could be referenced by author and timestamp, which would be invariant under (competent) repo conversions.

Walkman 11y ago

There are tens of thousands of lines commented out in the codebase at my company... When I say "We should delete all of them" they defend "it will be good sometime" LOL. That's why we have a 500k LOC codebase and developing a feature takes weeks and months instead of days. I'm not allowed to refactor...

theophrastus 11y ago
As something of a computational geneticist, i really appreciate this comment. because there are exon sequences in DNA, which are expressed as mRNA and often translated to proteins -- let's say "compiled"; and intron sequences which are spliced away and currently unused. However introns are the stuff of past and future genes and controls, just like lines of code commented out. They are like boxes of stuff in your attic, currently not used, but very handy when conditions change.
- jheriko 11y ago
  and just like life you pay for it by having to maintain and copy all of that extra genetic mass... much as the programmer pays by having more content to navigate, where most of it is not part of the program code.
  - mc808 11y ago
    And by the time you uncomment it, the rest of the organism/code has mutated so much that the legacy snippet does something totally surprising or even destructive.
    - deleted 11y ago
      [deleted]
  - XorNot 11y ago
    I have this argument with people about comments in configuration files on production systems. Their argument is "it explains the configuration". My argument is that it's more important to be able to quickly see what configuration is actually applied (which usually fits in a terminal window without scrolling) then it is to redundantly store help-text on the server (which also makes it hard to read what is enabled).

giberson 11y ago

>we leave this version here commented-out, because the code is very complex and likely to have subtle bugs. If bugs _are_ found, it might be of interest to look at the old code and see what did it do in the relevant situation. Here are two better alternative solutions: * comments (in natural language not code) that describe what the code should do * test cases: to dictate what code should do and prove it does do it

bastawhiz 11y ago
It's a bit ironic that there's a longer comment describing why the code shouldn't be removed than there are comments describing what the code _actually does_ or _why_ inline.
pyre 11y ago
You missed: * Comments referencing the original code by date / version / commit id. Date and version are relevant because the comment might not get updated if there is ever another VCS migration.
Johnny555 11y ago
That might be workable idea if the guy writing the replacement code has such a perfect understanding of the original code that he can spell out every assumption and edge condition that the code covers (as well as write tests to cover all conditions). The best you can hope for is comments and tests that cover the new author's impression of what the old code was doing, which is not necessarily the same as what the old code did. In this case, since he apparently doesn't feel that he has that perfect understanding, he left the original code there, so when someone says "Hey! I counted on behavior XXX, this change broke my workflow!". And any change no matter how trivial or "correct" always breaks someone's workflow. https://xkcd.com/1172/ https://xkcd.com/1172/
ajross 11y ago
That's the kind of smug naivete that makes young programmers so insufferable. Your use of "should" in your two sentences is a hidden, inappropriate abstraction. You're positing the existence of a "correct design" for expand-file-name and working backwards to how you'd write it in a modern ground-up development project. The actual problem at hand was rewriting that function in a way that doesn't break the uncounted thousands of usages in the wild, which depend on the self-described "complex and likely to have subtle bugs" original implementation.

gonyea 11y ago

If you think this is crazy, never ~ever~ look at what Mainframes are running.

jdcskillet 11y ago
I was just thinking the same thing... We have lines of commented out code from 1988 (yes. that is a correct date) that people flat out refuse to delete. I am so glad I got out of that mess...
- krylon 11y ago
  In all fairness, I have had to touch somebody else's code on a few occasions where they did not use any kind of VCS, and I was very reluctant to flat out delete code, so I did the same thing described in the linked page - comment out the original code and add an explanation why I replaced or removed it, along with a date. And when reading somebody else's code, I tend to appreciate if the code carries its history with it, at least to a degree. What I really do not like, though, is when there is a piece of commented-out code with no explanation of why it's there in the first place or why it was commented out.

makecheck 11y ago

Generally I find all copies to be bloat. Seeing the original code will not necessarily explain old behavior. When you make a copy, how much are you planning to copy? To debug ancient code that calls 5 functions, you might need access to the histories of those 5 functions; and the histories of any functions they call, and heck maybe you only saw correct behavior on a certain OS or with certain input (none of which you may have access to). If you don't have all those histories, the "correct old code" you are looking at may even lie to you, as it suggests it is calling functions you think you are familiar with but those functions have changed in some important way. After enough time passes — and at the rate this industry moves, time is short — the only thing that really matters is whether or not the program currently does what its current users require. And if it doesn't, you define what behavior you need it to have and find a way to fix it.

sxates 11y ago

My question is - has anyone needed to refer back to the old code in the last 30 years? I can understand wanting to have the old code around for easy reference in case you need to debug the refactored version, but if no bugs have come up in the last 30 years (or even, say, the last 5), it seems pretty safe to say the new code is solid.

cfcef 11y ago
Another question: is the old code even valid in any sense compared to the current code? Since the original was written before 1985, then 99.9% of the people running Emacs will be running it on an OS that did not exist in any form in 1985 (Linux, Mac OS X, Windows, Android, etc) and the rest will be running on OSes which have changed substantially or been replaced entirely since then (SunOS->Solaris).
- kbart 11y ago
  That's the beauty of C -- you don't have to rely on OS, so a code written 30 years ago is still working today.
  - cfcef 11y ago
    Of course C relies on an OS. The point of an OS is securely mediating access to resources; a C program is going through the OS, using syscalls, in order to do stuff like 'write a file'. Which bears a certain resemblance to what this code is doing...
    - kbart 11y ago
      Let me repeat myself -- "you don't have to". C runs well on bare metal, that's why most bootloaders, kernels and low level drivers use it. Of course, you can make as many dependencies as you wish, but unlike high level languages, C doesn't rely on OS for it's core features.
    - deleted 11y ago
      [deleted]

lanstein 11y ago

lol #ifdef VMS[0] [0] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4887597a1c52b8277eabeb4d9484c75b1bc9429d http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=488759...

mrfusion 11y ago

I think ides should have a really easy way to see old code. I'm thinking like arrow buttons next to each function and you can browse though older versions. It's true in theory all your old code is stored in vcs but it's such a bear to actually go look at it.

voltagex_ 11y ago
I can imagine an OSX Time Machine style interface to Git that would be quite cool.
- phaer 11y ago
  Like https://github.com/pidu/git-timemachine https://github.com/pidu/git-timemachine for emacs?
lotyrin 11y ago
Does your IDE not?
- mrfusion 11y ago
  Not in one or two clicks away in a way that doesn't take my focus away from what I'm looking at.
  - lotyrin 11y ago
    It's Context menu -> Git -> Show history for function in Jetbrains products. Gives all the commits with changes inside the function, shows each one side-by-side.
    - thecatspaw 11y ago
      oh wow, very neat. Thanks
ChristianBundy 11y ago
Git blame?

stcredzero 11y ago

There are places in Smalltalk code where you see: false ifTrue: [ "Some code to debug to help understand..." ]. In VisualWorks, you can double-click next to the 1st square bracket to select the code, then instantly execute it or debug it. The reason why it's not simply commented out, is that automated refactorings in the Smalltalk Refactoring Browser can then touch the commented-out code. (St RB used to be guaranteed to always execute strict refactorings and produce correct code.) Often such code can even use values from the current scope, so a separate debug session can be spawned to see what it "would have been like" then dismissed with no consequences. It's stuff like that which made Smalltalk an uber-environment back in the day.

matthavener 11y ago
In clojure, you see something similar at the bottom of files: (comment (def some-state (create-state)) (some-fn [1 2 3]) (do-something some-state) ) The compiler ignores the block, but in a REPL enabled editor, you can evaluate the forms to possibly view current state, or run functions that test behaviors or probe runtime state.
- krat0sprakhar 11y ago
  Or the equivalent #_(def some-state (create-state)) (some-fn [1 2 3]) (do-something some-state))
  - vijaykiran 11y ago
    I guess you meant: #_((def some-state (create-state)) (some-fn [1 2 3]) (do-something some-state)) oh, and you can't have "invalid" code in (comment), but in #_ you can.
    - okal 11y ago
      #_ comments out the form it precedes. You do not need to surround it with an extra pair of parentheses. Didn't know about the difference in behaviour with regard to invalid code. Thanks for that. EDIT: Leaving this here for context. I'd missed the fact that they weren't all enclosed in a single form to begin with. Parent's solution is correct in light of that.

jonathaneunice 11y ago

Modern version control systems (Git, Hg, etc.) do a great job of storing file commits. They're very "flat," however. A file is a file is a file, and there's no good mechanism for storing tightly-linked documentation about the evolution of a project. Commented-out code is just one ad hoc way developers try to tack on that kind of information (often in clumsy, likely-to-be-obsoleted-or-forgotten ways).

mtanski 11y ago

There's an exception to every rule, like in this case. It drives me perpetually batty when folks blindly stick to process, best practices, convention even when it doesn't make sense.

kazinator 11y ago

Yes, if the function breaks, do we care what some code did in the same situation that was removed 30 years ago? I mean, let's look at it like this: does the author of the removed code have a vote in what should happen, through the comment? If it's so important, why was it removed? How do we even know that the new code did something wrong? We do not know that in relation to the old function; we know that in relation to some modern criterion. Maybe it completely bombs (irrelevant that the old code didn't bomb, or whether or not it did), or that returns some result someone doesn't like (without regard for what the old code did), or that violates some documentation. We can decide today what the code should do, and fix it, or its specification or both.

chris_wot 11y ago

If you think that's bad, try looking at the LibreOffice source code. I think I found a 15 year old bug the other day [1] [2], but I only noticed this when I was trawling through the history of the file "outdev3.hxx", which via cgit was a pain in its own right. There have, in fact, been 5 source code repository switches in LibreOffice over the last 30 years. [3] It started with some sort of proprietary version from 1988 to 2000 so there is no history at all from this period (which I think is a great loss...), from 2000 to 2009 they used CVS, then from 2008 to 2009 they used SVN, then from 2009 to 2011 it was Mercurial, then from 2011 to 2014 it was back to SVN, and LibreOffice started using git from the very start. One of the worst practices that the OpenOffice.org team had was to get a whole bunch of work, bundle it up into a single commit and then note that there were multiple fixes in the commit. This makes it nigh-on impossible to untangle what fixed what. They apparently branched in SVN, then took the branch and merged it, but then blatted the original branch so now this is all lost in history. And if you've ever read some of the most crufty parts of LibreOffice (cough VCL cough) then you'd understand that actually reading good commits is really very important for moments you think "what on EARTH is that code doing?!?"... 1. https://bugs.documentfoundation.org/show_bug.cgi?id=96826 https://bugs.documentfoundation.org/show_bug.cgi?id=96826 2. http://randomtechnicalstuff.blogspot.com.au/2016/01/possible-15-year-old-regression.html http://randomtechnicalstuff.blogspot.com.au/2016/01/possible... 3. https://archive.fosdem.org/2014/schedule/event/exploring_openoffice_history_using_git_grafts/ https://archive.fosdem.org/2014/schedule/event/exploring_ope...

Tinned_Tuna 11y ago

I'm surprised that we're still using this as a bit of a hack in the future. In the project I'm working on, when we substantially optimise a section of code, we move the un-optimised, believed-good, version. It becomes an oracle against which the optimised version is tested on both manually and randomly generated test cases. I'm not saying that the above solution should have been deployed at the time, but perhaps it could be moved in that direction now that we have these techniques and tools to hand. Could such a solution work well here? Perhaps, it would be even more useful, as tests would be likely to fail if the optimisation was bad, rather than just assisting with debugging after the fact.

V-2 11y ago

Yes, VCS doesn't give you a guarantee of storing your history (in an accessible way, I mean - "if a tree falls in a forest...") FOREVER, especially if you switch VCS systems on the way. However, commenting some code out also doesn't mean it won't rot. Methods/procedures around it will be refactored, variables renamed - in long time perspective, in a different landscape it can become incomprehensible and useless anyway. Just because some abstraction (version control) can be a bit leaky and one shouldn't rely on it absolutely, doesn't justify succumbing to some other illusion. Commenting code out is not equal to hibernation and it doesn't make it immune to flowing time. You uncomment it one day, you discover it stinks to heaven high - especially if it was complex from the start - and isn't informative at all. "But that's not the case here!" - well, guess what: version control failing to do what it's supposed to also isn't the case here, if you can still access commits from 1986, as someone pointed out: http://git.savannah.gnu.org/cgit/emacs.git/log/?ofs=124080 http://git.savannah.gnu.org/cgit/emacs.git/log/?ofs=124080