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.
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).
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...
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.
:view
:g/^\s*#/d
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.
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.