`zig fmt` with 2 spaces indentation

Help
1

I am quite amazed by Zig and decided to start using it, yet I am having some trouble with the code formatter.

I am aware that the document says Zig prefers 4 spaces for indentation. But I really want 2 spaces instead. It seems that the vscode extension will automatically format the code whenever I save (which I find it great btw), and during such reformatting, even if my code uses 2 spaces, every indention will be reverted to 4 spaces.

Is there any way to convince zig fmt (which I guess is what get invoked for auto formatting) to use 2 spaces instead of 4?

(Maybe it’s just me, but this is kinda driving me crazy…)

2

There is no way to do what you want. This is a conscious, explicit decision from the zig team; I doubt they will consider any suggestions to change this or allow for more / different configurations.

2 Likes
3

I see. If it is the case, I guess I will have to adjust my habit and try to live with their explicit decision.

(also just found 2 spaces for `zig fmt` instead of 4 · Issue #11107 · ziglang/zig · GitHub after searching Google with a slight different search term.)

4

My personal preference is to use 8 spaces for indentation (Rationale).
And zig fmt could have options to make everyone happy.
But actually adding any option to zig fmt would make everyone unhappy.
I really cannot read zig code using 2 spaces for indentation. I am so used to read zig code formatted using zig fmt that I cannot read anything that is not properly formatted using zig fmt.
The existance of zig fmt is about sharing code where everyone can read without mentally adapting to a different formatting style.

3 Likes
5

same here for me it’s 8 or nothing, but at the end of the day consistency is more important.

1 Like
6

The great thing about having a system wide formatter is that it keeps the kibitzing on the forum, and out of PRs.

Mine is that when I have a long run of definitions, I follow a policy of one comment per, at the end of the line. I strongly prefer to align the comments so they all start on the same column, but the formatter doesn’t like this.

There’s an open issue on changing that, which I hope lands someday.

3 Likes
7

O, yeah. I’ve been using this formatting style for all my C programs since I had seen this guide for the first time. And if someone’s C sources have something different I just run indent -linux over them. But if some language/community prefer lesser indentation I simply setup an editor so that pressing Tab inserts N spaces instead of a … well, tabulation, which was always 8 character long. For me personally 2 character cells as an indentation is too little.

1 Like
8

tabs help people who use assistive techs like screen readers understand code better. i think that should matter. people with dyslexia often have more problems reading ciode when there isnt enough spacing (eg, i do my ifs:

if( cond ) {
    // ...
}
else if {
    // ...
} 
else {
    // ...
}

but zig wants to shove all the else on the closing brace line and doesn’t like the extra spacing around the condition, and it can reading difficult.

if(cond) {
    // ...
} else if {
    // ...
}  else {
    // ...
}

And I’ve done APL so am used to very dense code, but for some reason APL density is much easier than C-like density.

1 Like
9

Without going into the whole tabs vs spaces war, I think this issue of visual width of indentation is precisely an issue that tabs are better suited to solve. You could have the visual width of a tab adjusted to your taste locally and not affect anyone else’s view of the code.

So for example in a line of the source code we have exactly 2 tabs for everyone, but in my adjusted editor that’s 8 columns and in yours it could be 16.

2 Likes
10

I prefer elastic tabstops.
For indentation it is the same as tabs. The difference is that each tab creates a proper tabstop that aligns with all adjacent lines.

2 Likes
11

I don’t use tabs most of the time (I’ just too used to 3 spaces lol), but I’ve become more aware those using screen readers since I know a couple now, so I’ve tried to start getting used to it more and more out of concern for their usability.

1 Like
12

Tabs do make this slightly easier to implement, but indentation by a consistent number of spaces is no different from indentation by one tab: both can be translated by the editor to as many columns of indentation as you would like. This can only be done if the leading spaces per indent are consistent, which zig fmt provides.

Ease of implementation is basically irrelevant, since all editors I’m aware of are able to widen or narrow indentation, whether tabs are used, or whether a spaces-per-indent is defined for the format. It doesn’t matter at all. There’s nothing stopping any of you from changing your editor to display Zig indentation as 8 columns, or 2.

Similarly, given that spaces for indent are the more common modern style, I’m rather sure that screen readers designed for code can account for either style of indentation. If not, the developers are failing their users, and should fix that.

The reason I prefer spaces is because two invisible marks, one of them of variable width, has always been a rather awkward thing. The tab key is either a navigation and indentation button, or it is that but it inconsistently uses \t to provide that indentation, and I prefer the former.

But this barely matters in the last couple of decades, because editors can, and are, configured to handle this whole mess consistently.

There’s also the flip side of configurability: while editors can be configured to display either tabs or spaces however one would like, renderers, such as the one GitHub uses for fenced code blocks, frequently cannot be. Which is fine if you wanted your tabs to be eight spaces, but I personally find that excessive. With spaces, renderers display indentation precisely as the user intended it.

2 Likes
13

The two people I know say this is a problem. It is that spaces have a lot of repetition over just a single tab (this if you have to listen to every space, you would hate it too), but the problerm gets much much worse for braille devices that extremely limits display sizes and there the spaces waste a metric ton of “screen real estate”.

my tab key is literally remapped through qmk to alt on hold and backslash on tap (caps lock is control/esc), but I’m trying to be more aware if this. I broke my dominant wrist very very very badly a year ago and had to learn to use voice reg software for 6 months almost. Yes, you don’t realize the problems until you have to deal with taht shit.

2 Likes
14

mcedit wins
gs

1 Like