#90bikeshed: should code use tabs or spaces, and how many

I started #12 with this:

// Formatting options such as tab size or character are intentionally
// not exposed as configuration options. This makes all source files
// follow the same style guide.
const spaces_per_level = 3;

Three spaces is sort of the opinion that nobody really has. I don't really have a strong opinion on what is chosen, but I would like whatever is chosen to have an objective reason. I currently know of none.

Some points I want to make:

Tabs are not more accessible than spaces (or the other way around). I've heard this a bunch, but I think it's silly. This post from Andrew Kelley in the Zig issue tracker is a great response to it.
From Zig's FAQ on why spaces instead of tabs

Because no human and no contemporary code editor is capable of handling tabs correctly. Humans tend to mix tabs and spaces on accident, and editors don't have a way to "indent with tabs, align with spaces" without pressing the space bar many times, leading programmers to use tabs for alignment as well as indentation.

Tabs would be better than spaces for indentation because they take up fewer bytes. But in practice, what ends up happening is incorrectly mixed tabs and spaces. In order to simplify everything, tabs are not allowed. Spaces are necessary; we can't ban spaces. But tabs are not strictly needed, so the null hypothesis is to not have them.
Tab size can be configured in editor, which might be undesirable to our goals of uniformity and zero-config.

Some standard formatting practices in other languages:

language	indent rules
Rust	4 spaces (ref, configurable)
Zig	4 spaces (enforced)
Prettier (JavaScript)	2 spaces (default)
Biome (JavaScript)	tab (default)
Dprint (JavaScript)	2 spaces (default)

I think bullet point 3 might be all I have for objective reasons to use spaces over tabs. But the number of spaces is up for debate. It will remain at 3 until there is specific reason to set a different one.

Milestone: 0.3.0.

~clover changed the status to Todo · 2 years ago
~clover commented · 2 years ago
Author
Owner
it cannot be hard tabs because they print at 8 wide in terminals, and apparently on github too. this is unacceptable and will make code hard to read.

the number is between 2-4. we will choose one number by 0.3 and force that for the duration of the language
~190n commented · 2 years ago
Tab width is configurable on GitHub and in many CLI tools (bat defaults to 4, less -x WIDTH).

I don't really buy the arguments from Zig. Automatic formatters are perfectly capable of correctly mixing tabs and spaces. And while it might be nice if every editor could detect spaces used for indentation and render them at a different width (and I know there are some extensions that can already do that for certain editors), that's an weird thing to ask for when all those editors already let you change the tab width. Tab is already the way to specify a viewer-configurable amount of indentation, and every place you'd view code lets you change the width; why do we need to make them let you do the same thing with spaces too?

Tab size can be configured in editor, which might be undesirable to our goals of uniformity and zero-config.

I don't like this argument. Why can't I look at code the way I want? Are we requiring everyone use the same theme, font, and text size?
~jeff-hykin commented · 2 years ago
Tab size can be configured in editor, which might be undesirable to our goals of uniformity and zero-config.

I'm with 190n. I mean if visual-indent size "isn't uniform" then what about fonts and theme-colors?

_

Another risk for tabs is: they don't allow deep alignment.

Ex:

let a = ( 1, 1, 1, )

Probably not a problem for WL but, it is notably impossible to do that correctly with tabs.

_

Because no human and no contemporary code editor is capable of handling tabs correctly

I mean no, they are capable of handling it correctly. IMO the correct behavior is; if all the chars in front of the cursor are whitespace then tab button = tab character. Otherwise tab button = inject a bunch of spaces.

But the zig comment is important because I don't know of any editors that actually do handle it correctly without considerable configuration.

_

Only because of editor default, I think tabs are a problem. Which feels bad, but whatever.

const spaces_per_level = 3;

People are going to say 3 space indent is weird, but I think it might be the move. Make the 4-spaces camp (me) and the 2-spaces camp equally unhappy.
~clover commented · 2 years ago
Author
Owner

Automatic formatters are perfectly capable of correctly mixing tabs and spaces.

i think this is a good approach (tabs for indent, spaces to align items otherwise) and see how it fares. i don't know why i originally threw it out (it should not be hard).

i do worry about the default configuration of a tab rendering as 8 spaces in browsers/github/terminals to make it anoying to deal with, but i think i need to see these issues first hand.

if not, then i think 3 spaces will be the best of all worlds, but then again deciding a proper tab size (which regardless of the character used, the language manual will have to consider)

the more time i spend thinking about this the less sure i am, and this is one of the most insignificant problems of the language.