Yeah, I think the way gofmt does it is basically perfect - leading whitespace is tabs and respects user width preference, alignment across lines is achieved with spaces
These are the sort of controversial articles on Hacker News I come here for.
I'm practice, it seems my life is easier to live with others if I use spaces. But the tab is conceptually simple. It means indent, or something almost like "next-column". Spaces mean separation from words or tokens. So you are creating a new token as a compound of existing tokens when the original token already exists.
I too am a secret tab-lover, forced into the darkened corners of the internet by the vocal space-worshipping majority. Stay strong; they can take the tabs from your work but they can never take them from your heart!
its really time to move past this. two good outs are using an actual schema for storing code instead of flat text, or to have programs that reformat. the former is a stretch, but I find the latter really convenient even I'm working alone - I don't have to fuss about, I can just do stuff and hit the 'make it look nice' button.
> What matters is that tabs let developers control how much space each indent has, while also allows you to set it to your preferred size. Everyone wins!
Couldn't you make a custom font with a ligature between two spaces that then takes up more horizontal space?
That way, you could still control how big each indent is, yet still use spaces.
Automatic, uniform formatting, a la gofmt or rustfmt is actually the best. Once you have more than a single person working on a project, consistency matters most.
With PNGs you always get both the exact same indentation width, but also the same fonts and font colors!
Tab proponents will talk junk about "preserving intention rather than incidental spacing". Space proponents will correctly point out that only spaces preserves alignment. Then don't even notice when the same code viewed on two different computers renders with two different FONTS!
Space lovers pretend alignment is super important, but are ignoring the biggest contributor to rendering differences!
Once you accept that preserving visual representation, aka rasterization, and not intention (tabbing) is important you unlock a world of options. With pngs you color code sections. You can mix fonts to mark meaning.
Best of all: once your editor is png aware the entire experience is transparent! Tabs are a cludge for outdated editors, real editors include powerful optimizations to OCR spaces/pngs into usable text files.
The broader community, unfortunately, often overlook the needs of those who don't fit neatly into the same box as the decision making members of the "broader community" do. Did you read the article?
I’m just saying I choose to not care that much about these discussions. Pick a standard or some customizations that work for the team, and deal with it. But having discussions or debates on it that last more than 5 min is a waste of time.
For people like the author, their team should just accommodate him. If they can’t then unfortunately he would have to write code however he’s comfortable and run a custom linter.
And I disagree that either spaces or tabs are better. I don’t care, that’s my view.
Tools should handle this so we can stop talking about it.
It’s an indictment of our “profession”’s ability to build even half-decent tools for ourselves that we’re still talking about this. No wonder most of what we produce for others is a usability nightmare. We can’t even make nice things for our own use.
(Yes, I know, this is basically solved in a handful of ecosystems… and yet, this is on the front page in 2023)
"Per-developer visual indent width" feels like the strongest argument for using tabs on a project, as virtually all editors let you choose the visual tab width.
That said, the visual indent width seems like something that ought to be solved with editor software regardless of the tab type. Editors already transparently solve many problems with indentation (e.g. automatically detect the indentation type, indent x spaces when you press tab, continue indent on newline, unindent when you type a closing brace, etc).
Good editor support for indent width preferences would help folks comfortably work on any project regardless of its indentation type.
And as a side note, it would be nice to reserve big ol' wide tabs for tabular data. Using them as logical indentation feels a bit like a shoehorn.
They solve this problem for more than a decade now, that’s why I never cared about it at all. I press whichever I want and my IDE does something that will match my intent. Someone else’s IDE will do the same even if it is spaceTABspace.
We are not parsing sequential ASCII, we are doing visual programming, although on the very low end of the spectrum.
Who cares? It's for this reason I don't use either. Everything is just left-aligned. I haven't touched Fortran in ages, and don't think anybody complaining about either tabs or spaces has either. Just write code and don't think about it. Use a formatter to pretty up your code, if you please.
I was writing a comment about why I think spaces are better, specially with auto-formatting but now...
I feel like tabs could be better if you let the auto-formatter do its job by setting the tab width to 4 spaces. That should be good enough so that people with a tab width of 2 or 8 don't see the code lines neither very short nor very long. I also feel like most people who use spaces are good with a tab width of 4?
I also would not take into account tab widths not in [2, 8].
> if you let the auto-formatter do its job by setting the tab width to 4 spaces.
I think the autoformatter should use typewriter tabs (so that you could have your first tab in column 4, the second in column 30 and a decimal tab in column 40, and, in another code block, tabs at columns 4 and 12, for example) and dynamically adjust the width of each column.
It should show the code in the way the viewer can best understand it, picking fonts, colors, indentation and empty lines to their preference.
Except for a few esoteric programming languages where spaces are highly significant, that could mean showing hugely different things to different people.
Open issue with that is that code reviews could get more difficult (things like “two lines up” might not make sense if you prefer function arguments on separate lines, and I prefer them on a single line)
I was reading about the theological diatribes that early christians fought and died for. To a modern reader some of them seem so moot and inconsequential...
Then I remembered that I hold strong opinions about the tabs vs spaces debate.
31 comments
[ 4.8 ms ] story [ 75.8 ms ] threadI'm practice, it seems my life is easier to live with others if I use spaces. But the tab is conceptually simple. It means indent, or something almost like "next-column". Spaces mean separation from words or tokens. So you are creating a new token as a compound of existing tokens when the original token already exists.
Seriously, they make so much more sense!
As a tab lover, my jimmies get rustled most when I see those references to developers who use spaces earning more.
Couldn't you make a custom font with a ligature between two spaces that then takes up more horizontal space?
That way, you could still control how big each indent is, yet still use spaces.
With PNGs you always get both the exact same indentation width, but also the same fonts and font colors!
Tab proponents will talk junk about "preserving intention rather than incidental spacing". Space proponents will correctly point out that only spaces preserves alignment. Then don't even notice when the same code viewed on two different computers renders with two different FONTS!
Space lovers pretend alignment is super important, but are ignoring the biggest contributor to rendering differences!
Once you accept that preserving visual representation, aka rasterization, and not intention (tabbing) is important you unlock a world of options. With pngs you color code sections. You can mix fonts to mark meaning.
Best of all: once your editor is png aware the entire experience is transparent! Tabs are a cludge for outdated editors, real editors include powerful optimizations to OCR spaces/pngs into usable text files.
Why waste my time bikeshedding over bs like tabs or spaces or this or that? I’m just trying to build awesome stuff, not bikeshedding.
Ship software. Solve problems. Print money.
I’m just saying I choose to not care that much about these discussions. Pick a standard or some customizations that work for the team, and deal with it. But having discussions or debates on it that last more than 5 min is a waste of time.
For people like the author, their team should just accommodate him. If they can’t then unfortunately he would have to write code however he’s comfortable and run a custom linter.
And I disagree that either spaces or tabs are better. I don’t care, that’s my view.
It’s an indictment of our “profession”’s ability to build even half-decent tools for ourselves that we’re still talking about this. No wonder most of what we produce for others is a usability nightmare. We can’t even make nice things for our own use.
(Yes, I know, this is basically solved in a handful of ecosystems… and yet, this is on the front page in 2023)
However I have since recanted my heresy, because a space is a space is a space is a space and there is only so much that can go wrong with that.
That said, the visual indent width seems like something that ought to be solved with editor software regardless of the tab type. Editors already transparently solve many problems with indentation (e.g. automatically detect the indentation type, indent x spaces when you press tab, continue indent on newline, unindent when you type a closing brace, etc).
Good editor support for indent width preferences would help folks comfortably work on any project regardless of its indentation type.
And as a side note, it would be nice to reserve big ol' wide tabs for tabular data. Using them as logical indentation feels a bit like a shoehorn.
We are not parsing sequential ASCII, we are doing visual programming, although on the very low end of the spectrum.
I feel like tabs could be better if you let the auto-formatter do its job by setting the tab width to 4 spaces. That should be good enough so that people with a tab width of 2 or 8 don't see the code lines neither very short nor very long. I also feel like most people who use spaces are good with a tab width of 4?
I also would not take into account tab widths not in [2, 8].
I think the autoformatter should use typewriter tabs (so that you could have your first tab in column 4, the second in column 30 and a decimal tab in column 40, and, in another code block, tabs at columns 4 and 12, for example) and dynamically adjust the width of each column.
It should show the code in the way the viewer can best understand it, picking fonts, colors, indentation and empty lines to their preference.
Except for a few esoteric programming languages where spaces are highly significant, that could mean showing hugely different things to different people.
Open issue with that is that code reviews could get more difficult (things like “two lines up” might not make sense if you prefer function arguments on separate lines, and I prefer them on a single line)