Hacker News Reader

Comment by jve | Hacker News Reader

I'v been coding now for like 15 years and I'm not old enought to understand the debate between spaces vs tabs :)

I guess my IDE choices never surface the issue for me... visually they just look the same. I cannot say which codebase uses spaces which uses tabs. I never even think about it. I just smash tab character and don't care that there have been spaces. Or enter or { and IDE does the indentation. I just choose not to press space 2-4-8-16 times in a row.

Now I hope I won't get bulldozed over by HN crowd...

View on HN

Spaces vs. tabs causes a lot of issues for Python programmers who share their code with other programmers. The other place where spaces vs. tabs is an issue is with makefiles, probably one of the most annoying features of POSIX.

I also remember old school bourne shell wanting tabs in some places (case statements?), but bash doesn't have that issue.

These days, I try avoid them outside of makefiles.

Considering the way `/bin/sh` had a bunch of different implementations before POSIX standardization minimized that in the mid-1990s, I wouldn’t be surprised if one of those distinguished spaces from tabs.

That said, the original UNIX V7 implementation of /bin/sh didn’t distinguish different kinds of whitespace:

https://www.in-ulm.de/~mascheck/bourne/v7/

You're right. I don't see any evidence of what I claimed. It doesn't look like it was ever whitespace sensitive. This would have been in the 90's, probably Linux. I feel like the compatibility issue involved case statements, maybe it was the parenthesis thing.

> I also remember old school bourne shell wanting tabs in some places (case statements?), but bash doesn't have that issue.

From bash(1):

> If the redirection operator is <<-, then the shell strips all leading tab characters from input lines and the line containing delimiter.

That's also how it works with zsh.

This is why my here-doc delimiters are always un-indented despite surrounding indentation.

Wish bash had something like ruby's `<<~`, which accepts either space or tab indentation of the delimiter and additionally removes the indentation of the block (likely based on the least indented line).

One of the main arguments for tabs over spaces was always that people wanted to configure how much space a level of indentation makes up on screen.

With tabs pretty much every editor except something like notepad.exe could do it since ancient times, with spaces the editor needs to do a bit more processing, so you were a bit more restricted in editor choice, if you really were bothered so much by the indents chosen in the project.

So it is actually quite similar to the ligature discussion. It would be good if the code looked the same for everybody but now instead of saying "But 8-space indents waste so much space on the screen :(" some people now go "But I don't like seeing things like != or -> instead of modern Unicode symbols :("

Well, the tabs vs spaces had been mostly resolved and spaces won. But obviously it was never about what physical keys to press, nobody on the spaces side would spam the space bar to indent stuff (except maybe in the unfortunate situations of having to use an editor with no choice of setting the tabulator to emit spaces, or a textfield in a non-editor UI where the tabulator cycles the focus instead).

I'm still in the "tabs for indentation, spaces for alignment" camp. If you adhere to it, it makes your code look nice on any tab size.

For a solo project, sure, you do you. But for any meaningful collaboration, deliberately mixing tabs and spaces - and relying on a manual, semantic convention to use them the "right" way - will inevitably lead to a maintenance / consistency nightmare.

To add to your comment, it's kinda common to find projects that have spaces and tabs improperly mixed in the indentation. Making a quick search among the projects I have cloned, I'm seeing indentations like

  tab * 4 + space * 7 + tab * 2
  tab * 2 + space * 1 + tab * 1
  tab * 1 + space * 4 + tab * 2
  space * 16 + tab * 3 + space * 4
  tab * 4 + space * 2 + tab * 2 + space * 2
  tab * 3 + space * 3 + tab * 1 + space * 6

The code ends up looking janked unless you use the particular tab-width of the space/tab-indenter[1], which isn't always 8. It completely defeats the whole purpose of the tab indentation.

[1] On those first 2, given the odd (not even) number of spaces, it's likely that use of spaces was for alignment, but then a tab-indenter added tabs to that...

Typing formulas in Excel

It's too bad spaces won, tabs is just correct I think, since one can configure the tabstop to use any indent size they would like. I'm quite tired of reading 2-space indent. Seems everything has moved this way now except python. I'm even seeing C with it, which is especially jarring. I think the languages that use braces for indentation particularly need 4. Python needs it least, and I can read Ruby because its blocks are delimited by words and it's bad style to write long methods

Agreed, four is optimal and has luckily been the standard in projects I’ve worked in. Encourages you to avoid deep nesting as well.

I'm in the same boat, I always just press tab and let my IDE or text editor fill in with N spaces.

Granted, I'm also someone who heavily encourages the use of Black as the Python formatter in projects I'm on, specifically because it has no configurable options - can't have a holy war about formats if nothing can be changed.

I feel like tabs could have won if there was a stretchable tab character instead of it looking like a bunch of spaces. Being invisible meant that it was treated as a bunch of spaces. I could see it being visible as a very light gray block with just a tiny right margin. This way it would be easy to see how many indents there are.

> "understand the debate between spaces vs tabs"

The reason spaces won is that it's not (spaces) vs (tabs), it's (spaces) vs (tabs AND spaces).

Oh, for Pete’s sake. The bodies from this holy war are barely cool…

Reply on news.ycombinator.com