I do agree that you usually consider many thing before choosing a language, but when it comes to formatting, I truly believe that we shouldn’t let people choose how to format their code, because otherwise you end up with a very inconsistent ecosystem. Regardless of our own preference about formatting, The obvious perk in Zig is that you can read any code like it was yours, whereas in C/C++ every fking repo has a different syle, indentation, etc etc, and it makes it harder to reuse code for absolutely no tangible benefit. Zig is obviously not perfect, nor is it the best at everything, but not letting people format their code as they please, is a win in my book, and for any collaborative process that also reduce the pain and the friction, and the noise in pr reviews etc. It’s just a pure win
to add to the list:
- Objective-C
- Objective-C++ (ever heard of a language with two separate object systems which aren’t compatible? well, it’s only really intention is for glueing C++ and Objective-C together)
- Hare (although tbf, their answer to dealing with multithreading is literally don’t; among other problems)
- V
- Jai
- Fortran (yes, an oldie, but still important in scientific computing)
- D (kinda, it has an optional GC)
- EDIT: C3
I agree that unified formatting is beneficial.
However, I disagree with the choice of using the space character (intended for separation) for indentation.
This is not a matter of personal preference; it is objectively flawed.
The use of spaces for indentation was once justified because some code editors didn’t handle tabs properly. It was a workaround, not a standard.
As code editors have long since resolved this issue, continuing to indent with spaces (ironically done by pressing the Tab ↹ key) is no longer justifiable. Clinging to this obsolete workaround, and worse, enforcing it on others, is wrong, all the more so since it is both inefficient and ergonomically inferior.
You are stating that your personal opinion is objective.
But you contradict yourself. As you said, feel free to use the TAB key to indent, so while developing, you don’t loose time, in particular when you get used to save your file while editing to let the auto formatter do its job.
The only point that is objectively true is that using spaces is a little inefficient, by using 4 bytes for one indentation level. But this is absolutely neglectable.
Two minor points that I missed in the discussion so far, and which speak against tab control characters (and I think they are in the same “importance” category):
A tab control character causes trouble in places outside of the IDE, eg when source is copied without caution into a PDF (believe me) or an input field of a GUI for whatever reason.
When using tab controls, some people tend to choose a different width for it in their IDE/editor, eg 1, 2, 3, or 8 spaces width. And this sometimes leads to spaghetti code, because if you only use 1 or 2 spaces, the logical complexity of your code isn’t as obvious as with 4 or 8 spaces.
A final advice: Just don’t waste your time with this topic when you’re new to a language. There is so much more to learn and enjoy.
Exactly!
Where is the contradiction?
That’s not the only objective point. Can you disprove the others?
That’s why I said that indentation with spaces was meant as a workaround, primarily for cases even outside actual programming.
Speculative problems that might arise when copying code into PDFs or GUI fields are irrelevant to how source code should be written and maintained, where the priority is correctness and readability, not accommodating accidental mishandlings in unrelated contexts.
That’s one of the benefits.
I honestly don’t know what this means, but I don’t need someone to guess and enforce what makes me feel comfortable reading my own code when I can tailor it however I wish.
You might as well dictate which font and size I should use by that logic.
I believe my point is clear. I’m done here.
I suspect zig never seriously considered the specific indentation scheme it uses, as it’s a rather trivial matter. Zig’s sole concern is a single, unified format, not multiple representations. As for what that format is, I suspect it simply arbitrarily chose the most popular one. The reason for that choice, or which is better, is of little concern to zig.
If we really have to debate this, coders would prefer spaces because it ensures that the code they design is presented in a predictable way for all readers. A more individualistic reader might prefer tabs for indentation, providing a customized reading experience. These two requirements are inherently contradictory: if the reader wants a customized experience, then the coder can’t predict the reader’s experience.
In a serious debate, I might lean towards tabs because they inherently provide indentation semantics. However, this isn’t a strong argument; spaces at the beginning of all lines of code are considered indentation.
But again, I prefer not to take this too seriously; it’s not a topic worth discussing; consistency is more important. If I’m working in the Linux kernel, I’ll use eight spaces for indentation; if a specific project uses tabs, I’ll use tabs, too; for casual code, I follow the conventions of the language community or the default behavior of my editor. I don’t like to be too personal about this. So I think zig is the same way; it simply chooses the most widely used convention and doesn’t care to care about the debate over which is better.
I personnally prefer tabs, but like you said even if it’s not perfect, the bikesheding is even more pointless. It is what it is.
Closing this topic. The core issue was resolved long ago. The secondary issue has been addressed in the answers, and this is just devolving into tabs vs spaces debate.