Spacing conventions

[Bill]

Steve D'Aprano 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?

They ran the Unix command "diff" to double-check that nothing 
unaccounted for got added to the source code as they did new builds.    
The "rule" was you could "fix" the code if you were already there, in 
the immediate vicinity. In retrospect, this certainly helped to keep 
"human error" from sneaking in.
>
>
>> I maintained for-loops (containing
>> for-loops)... hundreds of lines long.   Would you be searching for break or
>> continue?  : )
> It depends on whether it was relevant to the bug or not.
>
> I've never felt the urge to search for some arbitrary keyword when debugging.
> Why search for break or continue? How do you know the bug has anything to do
> with one of them?
>
> I would start with narrowing down where the bug occurs. Hopefully the stacktrace
> or error gives a line number. Then work backwards from there.
>
> I certainly wouldn't say "Oh, the code crashed on line 587. I'll do a quick
> search for the closest break statement and start working from there."
>
> What do you do?
>
>
>