Hacker News Reader

Comment by theophrastus | Hacker News Reader

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.

View on HN

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".

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

Are there any good breakdowns for laymen you could point to about this behaviour? It sounds fascinating.

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.

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.

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.

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.

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).

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.

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.

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...

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.

While I agree useless comments are bad, especially in production, is there any reason why you don't just have a macro in your editor (assuming vim here) to do

  :view
  :g/^\s*#/d

(this sets vim into read-only mode and then deletes all comment lines, assuming # for comments).

in general with code, if it needs explaining with comments then its not written cleanly. sometimes there are confusing external considerations, like mathematical algorithms or additional constraints - that is what comments are for imo, explaining things external to the code that are required to understand it.

comments like "does this" are telling you the name of the function that the following code should be in.

... so unless your scripts/configuration data are written in a very esoteric language or format i'm inclined to agree with your point very strongly.

grep -v "^#" config-file

Comments in configuration files that document the particular value of the setting ("why do we have this set this way") or other such subtleties make sense. Comments in configuration files that document the setting itself definitely don't.

Unfortunately, many distributions ship configuration files in /etc with a pile of commented-out defaults and documentation, on the theory that doing so makes them easy to edit.

Personally, I prefer the current approach of not shipping a file in /etc at all, shipping the defaults in /usr if anywhere, and thus reducing the file in /etc to actual configuration.

Indeed. DNA is the original DVCS.

Reply on news.ycombinator.com