anchor.diff:  = Rant: The Teletubbies "Documentation" Pitfall
  +
  +== Disclaimer
  +
  +I am not Uncle Bob's nephew, but if you already have read Clean Code, 
  +chances are you will not learn much from this post.
   
   == Typical example
   
  
positive.code:                 // call nice service to fetch foo
                  Foo foo = _niceService.fetchFoo(parameter);
  
                  // [...] 200 lines with comments+code like that
                  return new SomeResult(foo, ...);
          }
  ----
  
  Indeed, the bad side effect of this kind of brain-dead comments is
  that it *prevents* the original authors to take a step back and ask 
  themselves: is the code readable enough this way? 
  
  Or future authors: can the method I am changing  be improved?
  
  If you get used to this kind of comments, you will most likely focus
  your reading on them and live in the illusion that the method is 
  readable.
  
  I have got some bad news for you: 200 lines of code for a method are
  NOT readable at all, no matter how much obsolete poetry you stick in there.
  
negative.code: Well, comments like these can *easily* get out of sync. 
  In the worst-case scenario, they become misleading.
  
  It leads to situations where you have to confront the current code
  and the outdated comment and you cannot really be sure which one 
  describes what the behavior *should* be.
  
  Comments don't run, they are just an informal bunch of text 
  and cannot be changed automatically (at least, not in a 
  100% reliable way). Their risk of becoming obsolete is therefore
  higher.
  
  To rephrase it, comments like this are part of the problem, 
  not the solution.
  
  Inline comments are just a liability.
  
  The worst part is that they often appear as a whole bunch:
  
  [source,java]
  ----
  