5 ms·

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 somet

• 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).
      • donatj 11y ago
        I'd say leave the comments in the config file and instead add a sanity check quick scan output to your application itself. Dev ops surely aren't as knowledgeable about the implications of config changes as the developers and notes about the potential downsides of changes are important.
      • ak4g 11y ago
        Can you not tell from the running system what the currently-applied values are? That would address your concern. OTOH, if a nonsensical value without a comment (and, at a minimum, an indication of who made the change, when, and a reference to a bug/case/URL with the full details) is present, you have nothing to work with. Your only option is to change it and see if production breaks, and that is never an option until until production is already broken. At which point, you always discover that there are, in fact, multiple configuration values set that make no sense.
        • joepvd 11y ago
          Configuration files are the main initial resource for information about the configuration. If there is no reason to suspect that reality mismatches configuration, there's no reason to go down that rabbit hole. What the current configuration _means_, however, is a different matter. I have worked on systems where the explanatory comments are only accessible in a different system. One more extra hurdle, whether they are helpful or not...
        • XorNot 11y ago
          An additional point is that most of the time config-dumps from a running program include ALL configuration settings. 95% of the time it's simply not important - what I actually want to know is "what is not set to its default". Which means I need the config files. I'm not against ALL comments - i.e. if something has a non-obvious external issue, that's worth noting. But people argue that the very verbose default comments, for example, should be left in - that's pointless, and potentially hazardous.
          • semi-extrinsic 11y ago
  • jzwinck 11y ago
    The source control system is like an attic (some even use that term). Commenting out code is more like leaving those dusty boxes in the dining room. I suppose one little old box might be ok if it has sentimental value.
    • ska 11y ago
      Not in the living room. On your desk. This is one of the things revision control is for, after all. If you are really worried your tools aren't up to the task of finding the old versions, you leave a one line comment with tag and rev.
  • echelon 11y ago
    It's so much more wonderfully complicated than this. Introns can change the local conformation of DNA, act as enhancers, impact splicing, etc. The genome is an incredibly vibrant machine (ecosystem, really) -- it's nothing at all like linear code. Just because it's non-coding doesn't make it "junk DNA".
    • SapphireSun 11y ago
      I've, in the past years ago, encountered a language bug in Perl 5. Adding a comment made the code work, removing it caused bizarre behavior.... Sounds like an intron with epigenetic effects to me. ;D
    • dsuth 11y ago
      Are there any good breakdowns for laymen you could point to about this behaviour? It sounds fascinating.
  • nickodell 11y ago
    Indeed. DNA is the original DVCS.
• deleted 11y ago
  [deleted]
• coliveira 11y ago
  When I am in such environments what I always to is to add some little cleanup to features that I am adding. In a code review, it is always easy to justify that I am also removing these 5 lines that surround the code and are not needed anymore. It takes time, but it helps.
  • Walkman 11y ago
    it's really hard (and you have to be really brave) to do that without any tests. (Of course the code bases have no tests at all...)
    • coliveira 11y ago
      When I am modifying code this assumes that I am testing that part of the code. That's the whole idea behind the cleanup I mentioned.