Yesterday, I shared some spicy takes. A few were particularly controversial—most notably, that I correct Gif the correct way (with a soft G)—but I also got a lot of emails asking me to elaborate on a few of them.
Today, I wanted to talk about how tabs are objectively better than spaces. This won’t take long.
Tabs let you define how big you want each indent to be, and spaces do not.
That’s what tabs are for. 1 tab, to an ide, means “you choose how many spaces this tab is, and when we commit it back to git it won’t fuck the history up.”
It was harder to explain why picking on Python for this is dumb, before gotofail… (Not saying that’s what you’re doing, but it feels close, so this is relevant.)
For whitespace, my rule is this: If any level of indentation depends on the length of any word or name, you’re doing it wrong. If using a more descriptive name causes indentation where previously there was none, that’s fine, but if moving the opening parens causes the interior to be indented more, less so. (Yes, Golang’s structs)
That’s what tabs are for. 1 tab, to an ide, means “you choose how many spaces this tab is, and when we commit it back to git it won’t fuck the history up.”
I guess they were referring to formatting other than tabs, like place of brackets and line length, which sounds like a neat idea
…until you start using languages where whitespace is the only way to distinguish code blocks. (Most notably Python.)
It was harder to explain why picking on Python for this is dumb, before gotofail… (Not saying that’s what you’re doing, but it feels close, so this is relevant.)
For whitespace, my rule is this: If any level of indentation depends on the length of any word or name, you’re doing it wrong. If using a more descriptive name causes indentation where previously there was none, that’s fine, but if moving the opening parens causes the interior to be indented more, less so. (Yes, Golang’s structs)