On 13/01/2014 06:47 PM, clipka wrote:

> There is one major advantage in "commenting" your code by structuring it
> and choosing good identifiers, rather than placing comments in there:
> Comments are typically more prone to become outdated over time.

This is another of the major themes of the book. Inaccurate comments are 
arguably *worse* than no comments at all.

> (Provided of course that the code is produced and maintained in an
> environment where refactoring is encouraged. If the policy is "try to
> avoid touching any of the existing code", it is easier to fix a comment
> that has become obsolete, rather than a once-good identifier that no
> longer matches what the function or variable does.)

One of the things that frustrates me about my job is that I want to 
refactor things, and people complain that it would take too long and so 
we won't do it.

Obviously the customers aren't going to be too impressed if we spent 2 
years restructuring the codebase with no user-visible change in 
functionality. But that doesn't mean that *all* refactoring should be 
put off...

Post a reply to this message