Spacing conventions

[Chris Angelico]

On Sat, Sep 30, 2017 at 3:46 AM, Steve D'Aprano
<steve+python at pearwood.info> wrote:
> On Fri, 29 Sep 2017 03:01 pm, Chris Angelico wrote:
>
>> On Fri, Sep 29, 2017 at 2:38 PM, Steve D'Aprano
>> <steve+python at pearwood.info> wrote:
>>> On Thu, 28 Sep 2017 03:56 pm, Bill wrote:
>>>
>>>> I worked in maintenance programming.  You got the hand you were dealt!
>>>> And you weren't allowed to "improve" the code unless the customer
>>>> contracted you to do so.
>>>
>>> How do you tell the difference between a bug fix and an code improvement, if
>>> the behaviour of the program remains the same?
>>
>> If the behaviour remains *exactly* the same, then it's a code
>> improvement (aka a refactoring), not a bug fix. Or, looking at it
>> another way: if there is absolutely no change to behaviour, how could
>> you tell that there was a bug in it?
>
> Well obviously you fix the bug, not just refactor and keep the bug. Sorry if
> that wasn't clear enough.
>
>
>> And yes, trying to convince a customer that it's worth paying for
>> improvements that don't change anything visible is hard.
>
> The point of refactoring is to make it easy to fix the bug:
>
> "Two hours refactoring, plus thirty seconds to fix the bug; versus 18 hours to
> fix the bug without refactoring."
>
> Plus or minus six weeks on each of those times *tongue pressed firmly in cheek*
>
>
> But more seriously, I'm not suggesting you refactor the whole code base. You
> only refactor the bit you are touching *right now*.

This is the easy one. You're touching this code, you improve it. That
applies to most things - style issues, local variable names, whatever.
You don't make sweeping changes, but when you're messing with things
anyway, you can clean things up.

> Don't even mention refactoring. That sounds like an improvement, and they said
> they don't want improvements.
>
> But even the most unreasonable client will surely understand that before you can
> fix the bug, you have to find it, and that requires understanding the code.
> Cleaning up the *immediately relevant section of code* (giving variables
> meaningful names, extracting common functionality, etc) is part of the
> necessary process of understanding the code and finding the cause of the bug in
> the shortest possible time, and the fact that you end up with cleaner code and
> less technical debt at the end is a happy accident. That's not why you did it,
> so technically all you did was fix the bug, exactly as told.
>
> (They didn't tell you *how* to fix the bug. If they knew how, they wouldn't need
> you.)

The trouble is that sometimes the refactoring doesn't pay for itself
with today's bug, but it might with tomorrow's bugs. Do you spend two
hours refactoring and bugfixing, or one hour just fixing the bug and
coping with the mess?

> But I bet that for *most*
> customers, if you give them the choice between:
>
> (1) Minimize the number of lines of code changed; or
>
> (2) Minimize the number of dollars on the invoice
>
> they'll usually prefer (2).

The improvement won't minimize the number of dollars on *this*
invoice. Can you sell them a line item of "future bug fixes will take
less time"? You can't put an actual figure on it ("will save 0.5 hours
per fortnight for the next year"), but you know the benefit is real.
That's why it's hard to sell the refactor.

ChrisA