But if you must you can start with a new line and the right indent.
And maybe you can enforce no alignment, but that's a hard fight to win.
And as far as tabs for indentation and spaces for alignment, I've found no practical way to enforce this via tooling/linting. And a rule without enforcement becomes inconsistent, which is how we get files full of mixtures of spaces and tabs, which is how people get frustrated with tabs, and we decide to throw it all out.
And inevitably, that's part of how spaces "won"
Addind a comment with the right amount of tabs as a table header and align all fields with spaces after the tabs would do the trick.
To take this example from a sibling post:
if (foo) {
» frobnicate(bar,
» ...........baz);
}
if (foo) {
» frobnicate(bar,
» » » ...baz);
}
Checking for that requires something more like a linter with a detailed understanding of the syntax parse tree.
Anyhow, if code reviewers always use tools that highlight the tabs during the reviews, there's a good chance to catch these things.
Maybe you could also have the tab width set randomly at every review, to make these horrors stand out
For example, I considered writing a small Awk program to check C code in response to another poster’s complaint about lack of tooling, but then quickly came to the conclusion that, with C’s insistence that (say) /??/<newline>* is a valid comment starter, getting this exactly correct probably does need an actual lexer that would go character by character. That sounded like it wouldn’t fit in an HN comment, so I stopped there.
(That said, that’s as far as you’d need to go in the majority of cases. A dishonorable mention is warranted for languages that use the same character as an operator and a paired delimiter simultaneously, that is C++, Java, C#, TypeScript, and Rust with their abuse of the less-than and greater-than symbols, because that would in fact require a parser. In C++ especially, you’ll need full semantic analysis with template expansion, name resolution, and consteval evaluation. Because C++.)
Yet you probably don’t actually need to be that accurate, do you? The majority of syntax highlighters aren’t, and they are still useful. You can usually afford to say that code that perverse deserves to lose, and in return I expect you should be able to gain a fair amount of language independence, which could be worth the tradeoff.
So instead of checking if things are aligned with what they should be, you would just check they are aligned with something, like a left word boundary preceded by a delimiter, and so on. I can already see unpleasant corner cases after thinking about it for a few minutes, but it doesn’t look hellish yet, it looks something like you could experiment with over a weekend to see if it was viable.
No wonder why spaces "won"
if (foo) {
» frobnicate(bar,
» ...........baz);
}
Of course that will always be a compromise, either people who use narrow tab widths or those who use wide ones will have a (slightly) suboptimal experience.
See, I can do it too. This is why there is an ongoing discussion. Because there is no clear cut answer, just opinions.
At least this article brings some data to the discussion.
but that's the whole damn point ... I like substantively indented code, you prefer minimally indented, we should both be happy (and we can be, by using tabs).
This is often why dev teams have more specific style guides that include things would be considered bike-shedding, like how many spaces an indent is.
On punch cards, teletypes, or VGA CRTs? Absolutely. On SVGA CRTs? Probably. On anything modern? No.
Why not bikeshed the bikeshedding?
Accessibility is not a joke.
> How wide should the indentation be? 2 spaces? 4? 8? Something else?
> By making the indent be a tab, you get to decide the answer to that question and everyone will see code indented as wide (or not) as they prefer.
> In short, this is what the tab character is for.
0: https://groups.google.com/g/golang-nuts/c/iHGLTFalb54/m/zqMo...
Indentation != spacing.
And thats all the argument i need. I dont understand why people argue with consistent text layout for all-spaces. You can use tabs to indent and spaces to align after that, in most cases.
Unless you're trying to argue that your code is a tsv file then tabs is the wrong thing to use.
Nobody cares that phone calls happen over fiber now instead of telephone lines. So, same should apply to teletype. Nobody is going to care you're reading this over fiber instead of a telephone line.
Now, people do care if they're trying to read a csv document and somebody didn't quote their commas within strings and now the values are in the wrong columns which could've been avoided by using tabs to store tabular data.
So you're ok if your text editor interprets the LFs of a Unix text file as mere line feeds, without ever going back to the beginning of the lines?
In practice this is difficult; since the characters are invisible by default, people will inevitably mix up the two. Looks like the industry standard is to give up and use spaces everywhere, unless strict and mandatory tooling exists.
But the new problem is linters and formatters don't understand alignment, so they always want those extra spaces removed, making a mess.
I’m not sure what are you referring to, could you give an example?
Generally, you shouldn't have all that many indents in your function. Using this would be a good visual clue to a beginner that maybe they need to break out their function into multiple functions.
Also, any use of hard tabs breaks diffs, which should make tabs a non-starter.
I'm now vaguely interested in hate making a programming language that relies on tabs and field/record separators. Just to really embrace the crazy.
On the other hand editors often now handle spaces as if they are tabs, even for cursor movement. So well. Both won?
I remember a time when people religiously claimed that both tabs need to be the way to indent but also that they have to be 8 spaces visually. I guess at least that war was lost since now even CSS allows you to change the number of visual spaces a hard tab has.
But it’s not what I mean. When navigating using the arrows it just breaks the flow because suddenly you “don’t move anymore.” Hard to explain, but it is real.
I've also never heard anyone argue that someone else should configure some different tab width, is there a specific language ecosystem you were in that had these insane takes?
> Tabs are 8 characters, and thus indentations are also 8 characters.
Yes, tabs are used for alignment as well.
To quote the OpenBSD style guide:
> Indentation is an 8 character tab.
The GTK source code uses tabs when the number of spaces for indentation >=8. This goes against their coding-style document, but if you don't have tabs set to 8 you'll find the indentation broken.
git is the same: although it prescribes tabs if you don't set the width to 8 you'll find broken alignment everywhere.
It's (tabs && spaces) vs (spaces).
In the real world, there will always be spaces, whether used for indentation or not. Using tabs for indentation inevitably leads to a mix of both - which is, objectively, worse for maintenance and consistency.
[TAB][TAB][TAB]ShortTypename[SPACE][SPACE]variable_name
[TAB][TAB][TAB]LongLongLongTypename[SPACE]variable_name2
ps. the [SPACE] counts above are illustrative, not accurate.
Tabs are for indentation, to align the beginning of the line, later on if you want to align text somehow, use spaces. You probably shouldn't align lines with different indentation (I align rarely so I can't remember ever to do that).
Having two different invisible characters to represent empty space is objectively worse. Just use space, and the tab key to insert multiple spaces. Simple. Use .editorconfig and a formatter to enforce the commonly accepted standard. Done.
Sadly you still have to make exceptions for Makefile, Go, etc. that expect a mixture of hard tabs and spaces. Otherwise hard tabs are not allowed in the codebases I manage, and are replaced by the formatter.
As an example, and I hope this is not a new information for most, in many text terminals it does not mean "advance forward to a multiple-of-8 position", it means "advance forward to next tab stop", and you can arbitrarily set those (e.g. HTS/TSC on vt220)
If tabs or spaces are mandated at editor level, how are you editing Makefile or TSV files?
I really do not understand anyone, who is against having support for any possible indentation, controlled by the user as is necessary for each use case.
I was in the "TABs are superior" camp but only for the initial indention of code blocks.
But somewhere along the way, editors added features that let you see invisibles, and let you set up smart tabs so that you could hit tab, but it would interpolate 4 spaces (or whatever you set) into the document, and let you shift+tab back the indention or TAB the indention, but put in spaces.
More importantly, the mass of people who all coalesced on using the same editor in the web development sphere, Sublime then Atom then MS Visual Studio Code, has made it easier to just say "set your editor to do this".
I have changed my mind to using SPACES now because the editor lets me fake using TABS.
There are still situations where it’s annoying, mostly when navigating the code using the arrow, moving from one location to another using the arrows, I won’t add a key modifier right in the middle of moving the cursor, it just doesn't make sense.
This is most useful when applied ecosystem wide - no one in the Go ecosystem argues about tabs vs spaces, they just run `go fmt` (or more likely their editor is set to do that automatically) and move the #$@% on with life :)
Fortunately for me, newer languages tend to include a formatter in the core install/editor tooling - Go, Rust, Gleam, Dart, probably more I'm forgetting... I think Go pioneered this approach and I'm glad others have taken it as well.
As found the hard way when one day we updated the version of the Go formatter, and much of our nice comments needed to be redone. Thanks Go formatter team (yes, that's being sarcastic).
I think there is a reasonable argument about the distinct semantic value of tabs but they introduce a concept that the general public think is superfluous when two spaces do the trick.
Words can become obsolete if there are other more commonly understood ways of expressing the same thing. This seems similar.
Are you a superior 4-spacer or is that too much for your weak IDE on that 4:3 screen?
Seriously though, tabs let you pick what's visually easier for you to read and I've worked with coworkers that struggle when indentation isn't clear.
It's hard to view your opinion as unbiased when you think this is how people indent with spaces.
Projects should just pick whatever standard is most popular for their given language, and then people can tweak their editors for personal preferences.
If you encounter a lot of code on the web then you might consider writing a browser plugin.
It doesn't work for indent-sensitive languages like Python, but it works for most of the other major languages.
I think with majority of TypeScript projects using Prettier, 2 is more likely to be the default[0]
The linked page literally says to ignore it [1]
> STOP READING IMMEDIATELY THIS PAGE PROBABLY DOES NOT PERTAIN TO YOU > These are Coding Guidelines for Contributors to TypeScript. This is NOT a prescriptive guideline for the TypeScript community.
4 is a historical thing used as a default for all languages in VSCode [2]
[0] https://prettier.io/docs/options#tab-width
[1] https://github.com/microsoft/TypeScript/wiki/Coding-guidelin...
[2] https://github.com/Microsoft/vscode/issues/41200
Edit: found the TS style guide at https://github.com/basarat/typescript-book/blob/master/docs/... , it should be the correct link
P.S. did send a mail to author hopefully they fix it
Among our team we do not enforce a specific width, but respecting the choice of the original author of a project is required.
Kind of annoying how LLMs will sometimes randomly decide to change tab width.
Yes, text is a good interface medium for exchanging program descriptions between humans and machines.. but it's not a very good medium for storing and exchanging program descriptions from machine to machine, or even human to human.. Humans have opinions, sense of aesthetics, habits, and so on.. some more than others, but still, most people care about at least some part of the.. non-important-to-the-actual-program-compiling stuff, such as casing, indentation, placement of brackes, variable naming and so on.. all stuff that's there for the humans, the compiler don't care what you name your variables.. It's insane that there's no abstraction here..
Just think about how much code we've written to wrangle characters in text files.. formatters, beautifiers, linters, preprocessors, templating systems, lexers, compilers.. It's natural, the amount of development invested in this, and the, honestly, pretty good tooling we have to manipulate those individual characters in files, makes it seem like the only way..
But it shouldn't be.. We should be able to describe programs by typing text, but the text shouldn't be there both for us and for the machine, it should be there only for us, the machine should present text to us, that describes the program, but we should be in control of how that is presented to us, far, far beyond choosing a color scheme in our glorified typewriter emulators. I should be able to tell my programming editor how _I_ want things presented, and that presentation should be a setting in _MY_ editor, not something that has any effect on the program descriptions I'm working with.. Like, the browsers default stylesheet in an alternative world where HTML only described what, and didn't allow the webmaster to overwrite the style. Power to the user.
If I wanted variables to be blue and blinking, and I want the function keyword to be a fire emoji, that's on me, that's just presentation..
We shouldn't have directories with plaintext files as our program storage, we should have dedicated program description files, and we should have dedicated tooling to work with them..
We will never have that.
You would have variable names not saved? They don't matter for the future maintenance of the program?
You can have most of what you ask right now, the further step most relevant here would be to not indent anything in the saved code; with most languages you're free to do it, and it's feasible to have an editor display it with the indentation you prefer; however it could only make sense if there's no way to have your team agree on an indentation style, there's too many fldownsides with hardly any advantage otherwise.
You're always free to have your editor ignore the spaces and display the code the way you prefer, anyhow.
But it's probably not always possible to deduce how things should be aligned.
For example, a variable holding a.. users actions per second. Say I've set up my editor for camelcase, I'd type in userActionsPerSecond, the editor would save the metadata as user,actions,per,second. Another programmer prefers underlines, their editor presents it user_actions_per_second, and a third user prefers it space seperated, but with a box drawn around it to indicate it's one thing and it's presented [user actions per second] or whatever. I'd maybe add a comment as metadata to the variable too, the comment could easily be shown above the variable, just as it is today, but they can never get detached by someone adding another item between the comment and the variable. Some people would prefer no comments at all, others want them always visible, others want them visible on mouse over.. lots of options.
I know I _can_ have almost all I'm asking for, but the hoops we jump through to get them due to storing program descriptions (source code) as plain text directly, with no really good way to add additional information to it (see the many horrors we have with annotations in different languages, for instance javadoc where comments are abused to embed a different kind of language carrying metadata which is only incidentally coupled to what it tries to decorate).
Instead of doing tricks to separate content and presentation, it should be the default approach.
Our entire infrastructure, grown organically over the past what, 40+ years, arrange itself around individual bytes arranged in text files, arranged in folders.. And I get that thinking this must be the best and final form is easy, because, honestly, software development tooling and infrastructure is some of the best and most solid software ever written, no doubt because it's written by the people using it.
It's not like I've talked with god and come with a list of solutions to problems nobody is having, only that, while I'm not really dissatisfied, I've stumbled into this way of thinking about building programs, it's partly due to some brain damage I must have gotten from learning and thinking about lisp, and while lisp does lots of things wrong, it gave my brain this twist that the models we hold of how to do things can be very different from what we're used to.
I think it's worth at least once in a while, to put some ideas on the backburner and entertain ourselves by imagining other approaches other approaches than arranging individual characters in files, which is the lowest form of computer interaction you can imagine outside of writing bits and bytes directly into memory cells. And it's a bit ironic that as we do this very high-level, high abstraction work that is composing a program, using the most primitive interaction with the machine that's still available through user-programs: manipulation of the arrangement of bytes in files.
If you look at modern development, there's still a fairly noticeable part of it that's centered about ascii-art, either directly by hand, or by instructing the editor to do it, and there's a lot of procedure that's there not to describe programs, but to help derive the programs out of the source texts.
btw, it still ignores it at times.
Of course, long back, these are also the first things I did so the team can reduce fights and let them choose their own tab-to-space preferences. The other thing was to set up `.gitattributes`[2] early on, specially for those on Windows, to commit the correct attribution when pushing to git.
Just use tabs!
If your style rule is 4 spaces, you have 3 invalid indentation levels for every valid one. Even if you only use two spaces half your possible indentation levels are invalid.
The number of times in my life I've been editing a space-indented file in vim on some sshed server and had to count spaces is way too high.
mjburgess•15h ago
"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, code-density preferences, and so on.
boomskats•15h ago
(golang converted me to tabs too)
wslh•15h ago
> Is it truly over? ;-)
smrq•15h ago
That's how TFA reads to me. Never give up, never surrender.
o11c•14h ago
The fact that people choose to reject this does not change the reality.
maccard•14h ago
Joker_vD•14h ago
[0] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/e...
zamadatix•14h ago
g-b-r•11h ago
eviks•4h ago
whoomp12342•14h ago
g-b-r•11h ago
quietbritishjim•14h ago
(Allow me to reply to this age-old argument with the age-old counter argument...)
But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on indentation level. This invalidates the only advantage of tabs (assuming file size is no longer a concern).
A common retort is that each reader's auto format (or soft wrapping) can sort out the wrapping. But if each coder is going to reformat the code anyway then they get the benefit of choosing their own indentation level regardless of tabs vs spaces.
JohnFen•14h ago
I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.
But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to match your preferences prior to editing.
eurleif•13h ago
And then have merge conflicts between people who set different hard wrap points? Did you mean to say soft wrap point?
1718627440•13h ago
quietbritishjim•13h ago
arcbyte•14h ago
This argument fails by default if its not understandable.
quietbritishjim•13h ago
Then someone else loads it with tab width set to 6:
Now the max column width of a line depends on the syntactic indentation level of it! Any width you choose for your editor will either overflow for some deeply nested lines or waste loads of space on less-nested lines.Of course it's not a real concern because your editor can probably automatically fix this. But if it's clever enough to do that, then the supposed extra flexibility of tabs is actually possible with spaces anyway.
ecocentrik•14h ago
DanHulton•14h ago
While I run into fewer that do this nowadays, it still reminds me that with tabs, What I Write May Not Be What You See, which can lead to readability issues, which I feel is a solid enough point against tabs that I've switched.
I write code so it is easy to read, and spaces are better for that than tabs, so now I use tabs. ¯\_(ツ)_/¯
ar_lan•14h ago
This is a very confusing final sentence. :)
moomin•14h ago
frizlab•14h ago
ben_w•13h ago
I don't know why it was 8, but it was.
PlunderBunny•13h ago
1718627440•13h ago
Jensson•4h ago
Note that nesting is a much bigger issue in a language like C where you have to clean up after yourself, in most languages having a lot of nesting in a function isn't an issue.
g-b-r•11h ago
It's probably the main reason why they're so controversial.
rimunroe•13h ago
pmontra•13h ago
Jensson•5h ago
Not sure why people are so obsessed with having power of 2 spaces, can anyone explain that? Why argue over 2 vs 4 when you can have 3 for everything? I think 4 is better than 2 since 2 is too hard to track, but 3 obviously is better than 4.
SAI_Peregrinus•13h ago
eikenberry•13h ago
SAI_Peregrinus•9h ago
eikenberry•8h ago
em-bee•12h ago
SAI_Peregrinus•9h ago
efilife•5h ago
eviks•4h ago
barbazoo•13h ago
pabs3•7h ago
birn559•5h ago
(*) Tabs only and no hard wraps, only soft wraps.