how to reduce bugs due to incorrect indentation

Chris Angelico rosuav at
Thu Feb 6 05:47:14 CET 2014

On Thu, Feb 6, 2014 at 2:08 PM, Dan Sommers <dan at> wrote:
> On Wed, 05 Feb 2014 19:02:09 -0800, msustik wrote:
>> 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?
> I think you just mentioned the best suggestions:  (a) have a good
> collection of unit tests (where "good" means data and branch coverage),
> and (b) look carefully, or have someone else look carefully, at every
> commit.

Yep, I'd agree with that. Additionally, a habit of small and
conceptual commits helps hugely, even if you don't look at them too
carefully as they go through; get familiar with 'git gui blame' or
whatever the equivalent is for your system (or just browsing through
'gitk' or equiv) and you can go back in time to pin down
bugs. I had to fight heavily to get my boss to understand this,
because he said he _never_ went back through the repo's history;
meanwhile, I was doing so frequently, and knowing exactly what code
was changed, when, and why. His attitude to bugs was "don't make any,
and you're a bad programmer if you do". My attitude to bugs was, and
is, "be honest with yourself, you will make them, so design your
systems to handle that".

When your commits are small and tidy, you can often find bugs really
REALLY easily just by looking at the commit that changed some
particular line. With gitk, I'll often make a dummy edit to a line,
then highlight the red "this line deleted" line in the uncommitted
changes display, right-click, "Show origin of this line".
Alternatively, 'git blame' or other annotation can work, but I
generally find that annotating a whole file is overkill and trying to
ask for annotations of one small section is tedious. But whichever way
you do it, you should be able to VERY quickly go from "Hmm, I wonder
why this is indented like this?" to "Here's the commit that made it
like that", and then you can easily decide whether it was right or

Of course, your commit messages have to be useful. I can't honestly
say my own commit messages are perfect, but at least they're not like

Note to future readers: That link will take you to the most recent
commits on that repo. It may be (it may be!) that, by the time you
look at it, he'll have changed his practice and started writing
exemplary messages. If so, just page back through the history and find
how it looked in 2014. :)


More information about the Python-list mailing list