[Sublime + Python Setup] The Ctrl+s "Heisenbug"

"What the **** is going on?!" I heard Keith yell.

Returning from my lunch break and in a helpful mood I grabbed my coffee mug and shuffled over to my coworker's desk.

"What's wrong?"

Keith was working on a ticket to fix an issue with our Python-based web portal. The result of some numerical calculation was way off. It seemed like a straightforward algorithmic fix…

"I think this Python code is haunted or something," said Keith as I sat down next to him. "Opening and saving this source file fixes one bug, but then 5 others show up!"

Two hours of swearing and pair-programming later, our investigation of the "haunted code" revealed the following steps to reproduce the issue:

First, we check out the original version of the affected source file from Git. Bug A shows up. So far, so expected.

Next, we open the file in Sublime Text and, without making any edits, immediately hit Ctrl+S to save it again. Now bug A is gone—only to have brand new bugs B, C, and D show up!

Umm…

We were stumped.

"Maybe it's some odd whitespace issue…"

You see, whitespace has a meaning in Python. It uses whitespace indentation levels to determine how code blocks are nested.

Personally, I really like the idea of "semantic whitespace". But occasionally it can lead to pure hell. Take a look at the screenshot below:

Running this script you'd expect to get 10 × 10 = 100 as the answer.

However, by using a mixture of space and tab (\t) characters, you can get this program to print "10"—a completely bogus answer:

For Python indenting, a tab is counted as equivalent to 8 spaces…

And code that looked correct on our screens was actually way off for the Python interpreter:

def square(x):
    result = 0
    for i in range(x):
        result += x
<\t>return result  # ← 1 tab character
^^^^               #   instead of 4 spaces

Remember, one tab is equal to 8 spaces. So this mixture of tab and spaces gets parsed as the following:

def square(x):
    result = 0
    for i in range(x):
        result += x
        return result  # ← 1 tab == 8 spaces

Now the return-statement is indented one level too far. It breaks out of the loop after the first iteration —

D'Oh!

Now by merely re-saving the file in Sublime these tab characters were converted to 4 space characters each. Thus fixing the original indentation problem, but also introducing several new ones elsewhere in the code…

Double D'Oh!

In the end Keith and I easily spent 20 or more developer hours on tracking down various bugs caused by inconsistent whitespace throughout the code base.

It was a nightmare of a bug to fix, and what frustrated me the most about it was how easily it could've been avoided in the first place:

Had we used static code analysis tools back then we would've caught these problems much more easily. Code linting tools would've simply highlighted this whitespace issue right in our editors (and on our build server):

For this reason I'm a big proponent of static code analysis tools now. They can help you detect and void certain bugs and classes of errors completely.

A code linter can catch functional bugs like misspelled identifiers, or reveal code quality issues like unused variables or imports.

I won't say automated code analysis is a miracle cure (sometimes it feels like it) —

But usually the Return on Investment for these tools is simply through the roof. They help reduce debugging and code review time with just a tiny initial time investment.

Now, as awesome as these tools sound, there are some common gotchas to integrating them with Sublime Text:

If you're not careful, integrated code linting can get overly verbose and distracting—and it can slow your editing experience down to a crawl…

To see how to set up silky smooth code linting for Python in less than 10 minutes, click here for more.

— Dan Bader