On 13-1-2014 21:00, Orchid Win7 v1 wrote:
> 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...

When I was working with a colleague we sometimes split. One did all the 
interaction with users and the other did the cleanup in a branch.
Now I am just by myself I need to do it incrementally, which does not 
work, because I do too many things already. But basically you should 
think of it as on-the-fly-garbage-collection. (With the disadvantage 
that you first need to cleanup and rewrite to support that)

-- 
Everytime the IT department forbids something that a researcher deems
necessary for her work there will be another hole in the firewall.

Post a reply to this message