how to reduce bugs due to incorrect indentation

[msustik]

I had a bug in a Python script recently. The code in question was something 
along the lines of:

if a == 1:
x = y
else:
x = z
y = z + y
z = z + 1

While editing this file I accidentally pushed TAB on the line with 'y = z + y'.

My changes were elsewhere and I did not notice the above one line change when I 
looked at the diffs before commit. I should have noticed it...

It was rare that a was 1 and therefore the problem did not show up for a while. 
(I know I should have had tests exercising all cases...)

When the bug showed up, it was kind of difficult to remember what was the 
original intent. Fortunately, looking at old versions allowed me to find the 
problem commit and the bug.

Any suggestion on how to avoid this type of error in the future?

Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to reduce bugs due to incorrect indentation

[msustik]

Thanks for all the suggestions!
Best,
-Matyas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to reduce bugs due to incorrect indentation

[msustik]

On Thursday, February 6, 2014 12:29:36 PM UTC-8, Roel Schroeven wrote:
> 
> My suggestion: configure your editor to insert the appropriate amount of 
> 
> spaces instead of a tab when you press the tab key.

You misunderstood the problem, but managed to start a Tab war! :-)

My emacs inserts 4 spaces in python mode when I press the tab key. Python uses 
the indentation to decide how many lines following the else are executed in the 
else branch or after the else branch (always that is).

By pressing inadvertently the Tab key I changed the semantics of the code while 
it is still syntactically correct and PEP8 compliant. This was indeed a user 
error and my question was towards practices reducing the chance of this 
happening again.

Based on the responses I arrived to the conclusion that there is no better 
solution than trying to be careful and have good testing suites.

It would be possible to disable the Tab key completely and type in the spaces 
all the time. (It is much less likely that one would press the space bar 
accidentally four times or hold it down to get 4 spaces by mistake.)

Unfortunately this means giving up the indentation help of the editor and that 
will slow down coding. It will also lead to many indentation mistakes during 
development (most of which will be caught right away however. Maybe a coloring 
of the background based on tab position could assist in this.

I also considered adding an extra blank line after the if-else block (similarly 
for loops) in the hope that it would reduce the chance of missing an 
inadvertent indentation after the block.

However, this defeats somewhat the python paradigm that got rid of closing 
braces and endif-s etc. used in other languages to allow more compact code.

-Matyas


> 
> 
> 
> 
> 
> Best regards,
> 
> Roel
> 
> 
> 
> -- 
> 
> "Met een spitsvondig citaat bewijs je niets."
> 
>  -- Voltaire

-- 
https://mail.python.org/mailman/listinfo/python-list