Tabs are better
The Tabs vs. Spaces war is over, and spaces have emerged victorious
231–238 of 238 posts
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#232The point of the "tab" option is that there is no consensus on the number of spaces to use -- so by using tab, one uses a single character, and allows the developer to determine screen spacing to their comfort. "Tab" being a live option is a symptom of the war-never-over in absolute spacing degree -- since different people have different eye-sight, eye-strain, etc. constraints, different linguistic familiarities, cod…
The war is ending though. It will be over when we finally format code at read-time so that we respect the viewer's preferences, instead of at save-time to reflect the authors'.
We already do format code at read-time if you use a decent editor/IDE. You can add smudge/clean filters to Git also.
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#233Earlier quoted context omitted.
But an editor can just as well let the user choose what width to display spaces at the start of a line. Nothing forces them to be the same width as spaces in the middle of a line.
Nope, an editor can do that, but it can’t do it just as well because not all spaces at the beginning are indentation, so then you need to have more complicated rules to differentiate between those cases
Too bad editors can't do something as complex as recognize language syntax. Imagine if we had that feature, then we could do things like syntax coloring.
Sarcasm aside, if your editor can't recognize indentation or adjust indentation according to arbitrary preferences, you really need to update your toolset.
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#234Earlier quoted context omitted.
Nope, an editor can do that, but it can’t do it just as well because not all spaces at the beginning are indentation, so then you need to have more complicated rules to differentiate between those cases
Too bad editors can't do something as complex as recognize language syntax. Imagine if we had that feature, then we could do things like syntax coloring. Sarcasm aside, if your editor can't recognize indentation or adjust indentation according to arbitrary preferences, you really need to update your toolset.
Too bad indeed that your fantasy toolset doesn't exist in reality
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#235Earlier quoted context omitted.
And what say you about reaching a consensus on the number of tabs to use?!?!?!
If someone uses more than one tab per level of indentation he should be forbidden access to editors for life
And now you understand my method of driving nit picky code reviewers crazy! bwahahahahahhaha
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#236Earlier quoted context omitted.
No, you can't do that with spaces because spaces have a fixed width, which can't always be aligned to a variable width column. Only in the primitive environment of fixed width fonts does this work, but even there the tabstops can also be placed at an arbitrary column position, check Word out
anyone writing code with variable width font deserves the hell they put themselves in.
Sticking to historical limitations can be kind of silly. I used to have a computer with 40-column text display, and I don't feel any need to limit myself to that anymore.
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#237Earlier quoted context omitted.
anyone writing code with variable width font deserves the hell they put themselves in.
Sticking to historical limitations can be kind of silly. I used to have a computer with 40-column text display, and I don't feel any need to limit myself to that anymore.
i agree with you in principle, but i am not sure that this is simply a technical limitation. it feels to me more than just a preference. i can't explain it, but looking at the apple systems font example in this article: https://storck.io/posts/proportional-programming-code-fonts/ i find it much harder to parse (visually scanning the structure) than the monospace one below. perhaps it is simply what i am used to. but i feel like i am having a more violent reaction than i should have if mere preference and habit were the issue.
perhaps the issue is the specific choice of fonts. the author in that article exclaims that if you allow proportional fonts then any font can be a programming font, while the author of the following post claims otherwise and set out to make their own proportional font that is suitable: https://timgord.com/2024-01/lisnoti-a-proportional-font-that... . there are other such projects like https://input.djr.com/info/ and https://go.dev/blog/go-fonts
one issue is that of distinguishing similar characters, which the above projects try to address while some people claim it's not an issue at all: https://alexkutas.com/posts/non-monospace-font
there is also the issue of alignment mentioned in the first article, that could possibly be addressed by limiting character widths to multiples of the smallest width.
but there is still the issue of interacting with other programmers, mentioned in this article: https://nelsonslog.wordpress.com/2021/09/12/proportional-fon... we would all have to agree on the same font if there is any kind of alignment needed apart from indentation. right now we can say that you can choose any monospace font, and things will look as intended, but with a proportional font things will look different depending on the font choice. whether that is an issue or not needs further study i think.
more discussion of pros and cons can be found here: https://stackoverflow.com/questions/218623/why-use-monospace...
Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious
#238Earlier quoted context omitted.
Sticking to historical limitations can be kind of silly. I used to have a computer with 40-column text display, and I don't feel any need to limit myself to that anymore.
i agree with you in principle, but i am not sure that this is simply a technical limitation. it feels to me more than just a preference. i can't explain it, but looking at the apple systems font example in this article: https://storck.io/posts/proportional-programming-code-fonts/ i find it much harder to parse (visually scanning the structure) than the monospace one below. perhaps it is simply what i am used to. but…
I definitely do not enjoy the font choice in your first link. The Go font has been pretty good for me. My editor is configured to use "Go" (not "Go Mono"), I don't even notice when I switch from editing prose to editing code.
"Distinguishing similar characters" is just as much of a concern for me when I'm editing technical documentation as when I'm editing source code. Once again, the Go font has served me well. Previously I used some other humanist style font from from the Ubuntu people that had that classic IBM slash-through zero. Some fonts have overly-aggressive ligatures and such, but those fonts should not be used in any technical context, source code is not special.
Alignment is a non-issue because wanting alignment is bad. There, solved that ;-) Arbitrary diff noise over multiple lines because you added one line at the end is a problem, not a goal!
I interact with other programmers just fine. Your linked article seems to be re-engaging in the tabs-vs-spaces flamewar in an era of gofmt rustfmt et al. It's a total non-issue.
Give it two weeks.