how to reduce bugs due to incorrect indentation

[Chris Angelico]

On Fri, Feb 7, 2014 at 9:09 AM, Larry Martell <larry.martell at gmail.com> wrote:
> The Tab key is not evil, it's the tab character (Ctrl-I). I have been
> bitten by this many time when I had to work on a program written by
> another. They had their tab stops set at 5 or 6, mine is set at 4, or
> they did not have expandtab set, but I did. So you get either a script
> that looks misaligned, but works, or one that does not look misaligned
> but doesn't work. When I have to pick up someone else's script the
> first thing I do is replace the tabs with spaces.

All you've proven is that *mixing* spaces and tabs is evil. It's like
arguing that oil is evil because, when you mix it with water, weird
stuff happens. But that doesn't mean I want to fry my bacon in water.

Mmm, bacon.

Sorry. I'm back now. Ahem. Arguably, a better fix is to replace spaces
with tabs, because they're more obvious. But mainly, just be
consistent. Whatever one file uses, it uses exclusively. It'd be
pretty easy to create a git commit hook that checks files for leading
indentation and rejects the commit if it's mismatched; I would guess
the same is true in Mercurial.

But none of this would solve the OP's original issue. Whether it's a
tab or spaces, unexpectedly indenting a line of code is a problem.
It's no different from accidentally hitting Ctrl-T in SciTE and
reordering two lines, when one line depends on the other. It's a bug.
So you look at your commits before you make them (to give yourself a
chance to catch it quickly), and you make sure you can always look
back over your commits (in case you didn't catch it quickly). Much
better than blaming the characters involved. Poor innocent U+0009.

ChrisA