Hacker News Reader

Comment by kstenerud | Hacker News Reader

I settled on spaces long ago for the following reasons:

- Tabs move the cursor to the next "tab position" but are invisible, which means that whenever someone hits tab in the middle of something (accidentally or otherwise for alignment), you end up with messed up looking text and alignment as soon as you view it with a different tab size.

- Trying to enforce "tabs only for indentation" rarely works without headaches because humans.

- Using monospaced characters everywhere means that you'll never encounter positional issues ever.

I've worked in 2-space, 3-space, 4-space, and 8-space indentation houses and honestly, I don't see the point of viewing indentation in your preferred size. It's easy to adapt to the house rules, and the benefits outweigh the headaches.

View on HN

I'm a space person, but I disagree with the premise of the first two points.

Exotic alignment such as trying to align equal signs on different lines together doesn't make sense... All the different cases are too difficult to describe in simple words. So it's better to simply not do it. IMO, the only whitespace in code should be to separate different tokens/words and for indentation. Adding whitespace to create any other kinds of visual effects should be discouraged.

I ended up using spaces, entirely because of the last point and because there are many products out there which render tabs really poorly. I literally can't trust people to be sensible about how wide an indent should look.

> Exotic alignment such as trying to align equal signs on different lines together doesn't make sense

It makes a lot of sense in some situations and makes the code much more readable. A long list of declarations, configuration options, or a pattern matching block with many short cases can look a lot less chaotic when you align them. Of course it should be done in moderation. And as someone already mentioned, for things like block selection and editing it makes quite a difference.

Only if my compulsive hitting of the auto-formatting tool doesn't immediately break it.

I've seen it used to great effect for describing code sections, either using ASCII diagrams, tables, sample output, etc.

The point is, formatted monospace text will happen (albeit rarely), and when it does you want it to remain intact despite user settings.

Aligning stuff is awesome for multiline editing however. Which happens more than one night think!

How so? I.e. in what situation multiline editing works less good when things aren't aligned?

If the GP's "multiline editing" means what is also called "block selection" (e.g. using Alt + arrow keys in Notepad++), then multiline editing won't work -- logically, just simply cannot work -- unless the text is aligned. Which is one reason why I think that was what was meant.

The other reason is, this is pretty much the only reasonable interpretation of "multiline editing" I can see here. Which makes me intensely curious: What did you mean by, or think was meant by, "multiline editing"?

There's more than block selection which is actually quite limiting in comparison with the other possibilities. What I do often (SublimeText, VSCode for instance) is select a token, select a bunch of occurrences of that over multiple lines, then start editing from there. So in the case of e.g. unaligned equal signs select the first one, Ctrl-D to select the equals sign on the next lines, then move cursor around word by word and edit. Or indeed start by creating multiple cursors at the front of a line and start from there. Etc.

> tabs... are invisible

I highly recommend using an editor which renders them as distinct glyphs, or enabling that function in your editor of choice.

No thanks, I don't want to replace whitespace with additional visual noise.

Ended up making my VSCode show white spaces instead and setting the default clicking tab to make a single space, but I appreciate the advice to make it more visually explicit, it has definitely thrown me off before when the code i'm looking at is so deeply nested.

Do you have any other code editor visual customization tips you'd recommend for a better experience?

Great. Now get everyone else who touches your codebase to do the same.

I have never accidentally hit tab when I was meaning to hit the space key.

I constantly have problems with positional issues with spaces because every one uses a different number of spaces and its too easy to miss click three spaces in a block of 8 instead of 4 spaces.

I don't understand how every one else has issues hitting the tab key but no problem clicking on space 6 out of 10 spaces.

> I don't understand how every one else has issues hitting the tab key but no problem clicking on space 6 out of 10 spaces

I use spaces all the time and didn't even know this issue is a thing. Especially when using monospaced fonts and text editors which just treat tabs and spaces almost the same from the user's viewpoint. I mainly prefer spaces because the cursor movement is more consistent and predictable, especially when I align things in code which otherwise leads to a mix of tabs and spaces.

Nobody clicks the space bar 8 times, they use the tab key and have their editor insert the correct number of space characters instead.

Yeah I'm confused here. I think the "clicking" in previous posts refers to using the mouse to position the cursor within a group of spaces/tabs. I don't use a mouse in my text editor so it took me a while to grasp.

I just use the editor's CMD-[ and CMD-] or tab and shift-tab indentation commands. You can also apply it to entire blocks.

> Using monospaced characters everywhere means that you'll never encounter positional issues ever.

I have seen many people, including myself, fat-fingered (or when their cats ran across the keyboards) 3 or 5 spaces in 4-space indentation Python code, because it isn't always that easy to spot when eyeballing a dozen lines of code.

I have never made the same mistake when writing Go, where I use tabs for indentation. Because there's a huge visual difference between one tab and two tabs.

One can argue that IDEs and CIs should catch errors like this, but sometimes I write throwaway scripts on remote servers that don't even have syntax highlighting. It is just one fewer thing to worry about when I don't want to bother to configure a text editor on an ephemeral server.

> It's easy to adapt to the house rules, and the benefits outweigh the headaches.

This applies even to tabs.

... except for the problems listed above

Reply on news.ycombinator.com