Tabs vs. spaces and other holy wars
wheresvic.gitlab.io
wheresvic.gitlab.io
I don’t mind whitespace-significant languages like Python, but wouldn’t tabs be a better choice? Seems like you can easily get lost after a few levels of indentation, and much more to the point, it seems like tabs are superior because a) your IDE can display them with any width, making it easier to follow long passages with deep indentation, and b) they could free up the editor from requiring a mono space font.
Any thoughts?
Personally, I don't get nor like the "adjust to taste" tab argument. I routinely look at the same code in multiple editors. Intellij, vim, code reviews, code search tools, git diff output. In the browser and in a terminal.
Don't break my vertical allignment. I don't need it often but when I do I really need it. Functions with long params. Data points in opengl arrays.
One consistent cannonical form. That's where it's at. That's what I want.
Using tabs for indentation doesn't do that. Using tabs for alignment does that, and virtually nobody wants that, including people who use tabs for indentation. Indentation and alignment are two separate issues. "Use tabs" is shorthand for "Use tabs for indentation", not "Use tabs for indentation and alignment".
Edit: it's worth mentioning that this kind of tooling is extremely important, as reducing the issues that drive religious wars is a priceless sort of feature.
I honestly think people prefer spaces because it's hard to get the above right. With spaces, if it looks right, it is right.
(Wow, I can't believe I just argued in favor of spaces.)
I'm a tab person myself. With tabs, those 2-space-loving perverts have no power over me!
So, my suggestion is that we indent with dots '.' .
this to me is the crucial disadvantage because it baits people with low tab-width into writing deeply nested code, which is usually seen as a bad pattern, and also blows up on the screen on someone using a wider tab-width.
I'm in favour of strong uniform rules. Make it 4 spaces, line width 80 and then everybody lives in the same formatting world.
> gofmt's choices are no one's favorite, but gofmt is everyone's favorite.
Here's Black for python: https://github.com/ambv/black
I'm not sure if my future co-workers would kill me or not for using it on projects.
1) Your IDE can parse code and reformat it in literally any way you want. This includes indentation width (regardless of whether the code is actually stored using tabs or spaces), but also things like line width, semicolons, string quoting style, etc. (e.g. Prettier for JavaScript), or even using completely different language syntaxes that have the same semantics (e.g. Ocaml and ReasonML).
2) Stylistic code formatting choices, while completely ignored by the computer, are important for humans. Some style choices can have significant effects on engineering quality. The obvious example is variable names, but perhaps a subtler example is that a wide indentation width can discourage deep nesting.
Both points (and more!) can be resolved if the on-disk format is not considered directly the on-screen format. Instead if the on-disk format is considered a serialization of the AST and editors would display it with "just-in-time" formatting based on user-preferences, then that would resolve the tabs vs spaces discussion once and for all.
Incidentally I'm a fan of the concept of structured editing etc.
Tabs are configurable, but configuration is required. You must configure every project for every editor to get reasonable display, which is annoying when possible and even more annoying when impossible.
Yes. Model your language on Python except each level of indent must be exactly one space.
Really?? Let's check...
if am == serious:
print "Really."
elif but == srs:
print "Haha. But really"
else:
print "This line actually a syntax error because wrong indent level."
EDIT: no fair downvoting, he said "any thoughts" and I gave some thoughts, with example.
That said, when working with shared code I believe what's more important is "micro-consistency" : the exact style doesn't really matter, as long as it's not so inconsistent that it confuses someone inspecting a function or file. One or ten spaces, or tabs, all applied consistently are far better than things like misleading indentation or mixed tabs and spaces in the same block of code.
http://www.richardrodger.com/2012/11/03/why-i-have-given-up-...
I thought it's worth considering as the syntax solution for a new language! It's fully orthogonal and removes all style decisions. The compiler never has to guess. That actually means the IDE could be fully sure of it in every case and could let you adjust the tabs, as in this example I put together (using excel and a C program):
----
I chose my suggestion based on orthogonality. Originally I started suggesting 2-space tabs for OP's new languages (as a syntax feature), since they're a pretty common style convention used by many in the C world, so not totally absurd.
But that is not fully orthogonal and hard to automate: if the compiler encounters 3 spaces, what is that supposed to be? Automatically a syntax error?
How many indents is 6 spaces again? -- when you use 2-space tabs the answer is 3
//Guess below line's indent level (2-space indents)
x
//This is indented how many?
x
a
b
c
x
//Guess below line's indent level? (1-space indents)
x
//Answer:
x
a
b
c
x
As mentioned your IDE can treat leading spaces as indents. (Visually indent them.) It's a 1:1 correspondence.
Anyway just my humble suggestion for tomcam's new language, who solicited ideas with "Any ideas?". I gave actual code snippets in my original comment. :)
Personally, I don't get nor like the "just press the space bar 12 times when you want to indent to 3 levels“ argument. I routinely look at different code in the same editor. Someone’s Python code, another open source library’s Javascript code, some abandoned Wordpress theme.
Don't break my horizontal cadence. If I’m used to single-level indentations being 4 characters wide it really throws me off when I’m looking at indentations a single character wide. I have to refactor the entire code just for the step-indentations to be “normal” for me. A tab-indentation on my editor is as wide as I’m comfortable with.
I don’t care what form someone uses. I’m probably selecting all and converting spaces to tabs when I’m working with it. And maybe I’ll program my editor to automatically convert tabs to spaces when I’m uploading to GIT to make everyone happy. That's where it's at.
This sounds like a strawman. Most people who use spaces configure their editor so pressing tab inserts spaces. You don’t have to press space 12 times to indent to 3 levels.
I like my tab bar to actually create real tabs because I actually have my editor show space & tab characters and tabs tell me the intent of the programmer (to indent) better than spaces do.
If you want your language to have a wide range of users, let me tell that I wouldn't chose to use a language that required me to use tabs. I don't care what awesome features it has. It's a dealbreaker.
By the way, your reason "a" is the age-old argument in favour of tab indentation. You're not going to convince anyone that prefers spaces like that. We've all heard it.
However, your reason "b" is just horrid and invalid. I've never heard of a programmer that would prefer to code in variable width font. OMG.
I'm not going to reply further than this. You have to be trolling.
Must you? Is there really no existing language sufficient for your needs?
Otherwise, you should be opinionated on this (and language design in general). Use tabs if you like them, nobody with a half decent editor will notice after two minutes of configuration anyway.
It becomes messed up if you need to edit python files. First check which indendation is used (chances are, that the file was created there, not with an IDE), then use either the tab key (maybe some editor magic makes spaces if spaces are detected for indendation) or space, which makes it more annoying.
Technically true, but so horribly misleading that I must assume it to be intentional.
You could just as well say that “VI was written in 1976 as a visual version of the older ‘ed’ and ‘ex’ editors, while GNU Emacs was first released in 1985.”
The truth is that both editors have their roots in 1976, got substantial re-writes in the ’80s and ’90s, respectively, and have been actively developed ever since.
The more important (to me) differing factors are things like:
1. Do they follow new developments in computer interfaces?
Emacs got its first graphical version in 1994 (1991 if you count XEmacs, 1985 if you count Zmacs), and keeps improving its graphical fidelity to this day by supporting multiple graphical environments on different platforms (Unix X11, Windows, macOS). While Vim technically has GTK support which adds a menu bar and tool bar, nobody uses it in this way since there is no point; in the main window, it is still is a terminal-style application, same as it was in 1976, with the only addition since then being colors. Compare that to what modern Emacs can look like: (https://www.gnu.org/software/emacs/tour/).
2. Do they get third-party support with packages, extensions, etc?
Emacs has always been very strong here, and modern Emacs has its own packaging system with an app store-style system built-in. From what little I hear about Vimscript, almost nobody uses it, it is not meant for serious programming, and the developers are unsure if it is worth bothering about.
Most bikeshed discussions, especially wrt code style, are excuses for guys to trot out some toxic masculinity in the workplace. They aren't telling you to alphabetise your imports to improve the codebase but to start an argument they think they can win. It leads to a hostile environment.
The reason spaces "are winning" is that tabs are the "live and let live" solution (read the code however you like) and spaces are the totalitarian solution -- "My code must look the same on your screen." Totalitarianism is naturally proselytising.
Thankfully the end is in sight. "Auto-formatters" are the "total control" endgame. They are probably a net drag on productivity, but they come with one incredible upside: nobody need ever talk about code style again, making the workplace safer for people who don't want to spend their time arguing about things that don't matter.
It's even a little less boring after seeing this. :)
"Use tabs for indentation, spaces for alignment: the superior approach. Code is indented and aligned properly, and indentation is flexible. Use spaces for both indentation and alignment: still fine, but not flexible enough. Use tabs for both indentation and alignment: completely unacceptable, leads to headaches."
Since this also happens every time, if you're currently writing a harebrained reply about "mixing tabs and spaces!!!!", you don't understand what's being discussed and should permanently recuse yourself from the conversation.
I personally use tabs-for-indentation-spaces-for-alignment in my personal code, but I think I'd lose my mind if I tried to mandate it for a public or team project without a standard code formatter like gofmt.
The "both"-camp is divided in two groups: the "don't care"-group and the "strict rules"-group (the former probably being much larger).
There was a Stack Overflow developer survey in 2017 which concluded that space users make more than tab/both users. Would be interesting to see the results when accounting for above difference in the both group.
The key thing for gofmt is that it's universal and community backed.