4 ms·

If you change code, then you should change any comments about that code. Comments that don't match the code should be flagged in code review.

• TheCondor 10y ago
  The people that make these suggestions don't do code reviews. I'm sort of surprised that the argument wasn't based upon "the principles of DRY"
• dmichulke 10y ago
  Related quote: Code never lies, comments sometimes do. - Ron Jeffries (says clojure-emacs/cider)
  • asah 10y ago
    ROFL. I get the sentiment... but respectfully disagree: code lies all the time. To make a few... - misleading function/variable names - improperly captured errors/exceptions - improperly structured locking/concurrency - code that's overly complex or naively simplistic eg naively insecure.
    • dahart 10y ago
      This is a great point, code is often very messy, and often misleading the way it's written, and often has bugs. But, fwiw my reaction to your first line is that to announce your disagreement is to not get the sentiment of the quote. What he meant was that code is executed and comments are not. When he said "code never lies" he meant that if your code is buggy, then the bugs will be experienced by users. So your point is actually orthogonal to the point being made, and doesn't either refute or support the quote.
• falcolas 10y ago
  Easy to say. Hard to implement consistently. It takes only one failure for the whole thing to fall apart; once it's fallen apart, every comment you run across becomes suspect, making the value of the comments a net negative.
  • NateDad 10y ago
    The thing is, even code can be suspect. Does ParseCommand just parse the command, or does it also run the command? If you've never come across a completely horribly badly named function/type whose original purpose has completely changed, but changing the name itself is too much work.... then you're pretty lucky. At my current job we have a type with a method called "VisitWebpage" ... its main function is to prompt for a username and password on the command line. :/