I know it’s a joke but I prefer the tab option. It’s easy to convert tabs to any particular spacing or code point width. It can also vary, if wanted, based on terminal or editor type.
People with worse eyesight can have a wider indentation while those who choose can opt for something more compact
Honestly I always preferred tabs for indentation and spaces for aligning. It doesn't break anyone's experience. And if somebody wants two spaces for a two-space-tab-width for indentation and other people prefer four. That will work just fine.
I hate seeing 2 space indents. Unreadable AF ( to me ). At least this way I can easily work in the same codebase without somebody being annoyed ( except for the crying about the tabs )
Why not tabs for both indentation and alignment? (Actually, I see indentation as just a specific use of alignment.) Word processors have been doing it for decades (and typewriters for over a century!). Surely we can convince our code processors to use user-definable, fixed position tabs instead of relative position "tab = x spaces".
Keeping the [TAB] character in the file then allows everyone the layout they like.
Or has working solo for 40 years fried my brain?
What I mean with tab = x spaces is only visually and not actually ( there will ( obviously) still be a tab character in my preference. Not sure if that was clear.
Because alignment are fixed characters compared to indentation. For indentation the only question is how many characters the next indentation needs to be.
For alignment it is not fixed. As an example of PHP code:
function test(&obj) {
$obj->doSomething()
....->doSomethingElse()
}
The dots would be spaces because in IDEs people generally use a font where every character is equally wide.
If I would tab again instead of spaces it could work out if my tab length display is ( for one or more ) adds up to the width of the variable $obj. If somebody else has a tab width of 2 rather than somebody who has 3. It would only align for one of the two people.
Does make sense? I typed it out after a gym session on my phone.
Additionally. The whole problem is resolved by using spaces for both alignment and indentation. But in the cursor would still jump one space at a time rather than the whole tab ( although there are keyboard shortcuts for jumping words which would jump all of em.
I don't know. Call me old fashioned. I like what I like :/
The fact that you had to explain this is the reason why tabs are inferior in practice. People just don't get it and then in collaborative projects you get a completely misaligned mess because not everyone has the same tab size.
Yeah, I understood the arguments against using tabs for alignment, but never really got the argument against using them for indentation.
I can't imagine it would be difficult for an IDE to scale the width of spaces found at the start of a line, to emulate this same customization while still preserving my sanity as a fervent space-indenter. I've never seen an IDE that does this, but it'd be an interesting compromise.
What if instead of having the IDE special case space characters at the start of a line, we had a special character that could represent a variable width space?
As a fan of tabs I see this as an absolute win
Tabs are objectively the better choice as it allows each dev individually to decide tab width in their editors. Spaces in contrast don't allow this same flexibility as they are used for much more than simply indentation, for example you likely put a space after each argument or operator IE func(arg1, arg2) or 1 + 2.
Also, a lot of editors won't unindent on backspace of spaces indentation, so I end up messing up the indentation with a 3/4 indent
That just sounds like a shitty editor, tbh. Pretty basic functionality.
Autoformatter should fix that, unless you use python. (but even then they might fix it to the closest proper indentation level)
Sometimes. I love auto formatting, I spam the shit out of it more than I spam save but it's definitely not perfect. It gets real confused with inconsistent indention like that. Especially with Python it'll fuckup
Too much waste of space imo, func(arg1,arg2) or 1+2 is faster to write and to read.
Stilltoomuchwasteofspace
Whyusemanywordwhenfewworddotrick?
Code can be viewed in more than just an editor. It might be in a terminal, rendered in a browser, etc. Sometimes you might even have to view it in an environment you don't control. I am very disinterested in configuring each and every tool to have sensible tabstops, if such a tool can even be configured.
Then don't? The whole reason nearly all the spaces guys do 4 spaces is cause that's the nearly universal tab width. You won't like this but the same exact argument can be made for spaces yet I'd bet you haven't even once configured the width of those.
I don't actually change tab width, it's the default 4 spaces equivalent for me but just because I don't take advantage of the ability doesn't mean I should prevent others from doing so.
The whole reason nearly all the spaces guys do 4 spaces is cause that's the nearly universal tab width.
That is provably wrong. The default tab width in vim is 8 spaces, and the default indentation in yaml is two spaces.
What's yaml have to do with anything? It's like python with syntactic whitespace which is unrelated to this discussion. The Tab vs Space debate is entirely around non syntactic whitespace which doesn't effect how the code is parsed. And yes Python technically does both tabs and spaces but it's all sorts of fucky.
Terminal editors while still used a ton aren't really what I was referring to. Newer terminal editors such as Helix have tab width configured per language most of which default to a width of 4 spaces but toml/yaml both default to 2 spaces. I was mainly referring to GUI editors as frankly that's just what most people use nowadays. JetBrains IDEs, Visual Studio, Eclipse, VS Code, Notepad++ were primarily what I was thinking of as I've used all of them and they all default to a tab width of 4 hence why I said nearly universal. Also I said nearly terminal editors being the only editors I've used that don't default to a width of 4 seems like a fair usage of the term.
This is simply false, many systems have them configured by default to 8, particularly most CLI tools. Git, for example, is 8, and btw, changing it is not readily done and requires you to hack around it by using a custom pager command. In fact, all core gnu utils (and even bash itself) default to 8, as well vim, emacs, nano, gedit, etc.
I use 2 spaces since I work in Haskell, which is a significant whitespace language where you want certain syntactic constructs to exist at a different level of indentation from your main code block. So yes, I have configured it. 2 spaces is also exceedingly common for HTML (browser Dev tools renders HTML with 2 spaces, even).
There is not a universal indentation width, though it is almost always universal within a particular language or perhaps project, in which case it's much better to have everything standardized. Code formatters enforced on a project are the norm, and those are way more impactful on how the code is read. But they are valuable because consistency is valuable. And yet, somehow you don't have huge scores of developers complaining about being forced to format their code in a way they don't like.
As I said, you don't necessarily control the environment in which you are viewing code. A common example is reading code over a shared screen. So you can easily end up reading code in a way you don't like anyway, so it may as well be some reasonable (if not preferable) standard that everyone is using.
Looking at code on somebody else's screen is entirely missing the point of using tabs over spaces. The entire point is that mine looks like how I want and theirs looks like how they want even though the file is identical. We can each have wildly different tab width and it'll look wildly different to each of us when we program. That's again the point.
Code formatters are great! I love them. Using tabs over spaces is objectively a better formatting option. One of my favorite features in code formatters is that they'll swap out spaces to tabs for you insane people who insist on mashing the space bar to indent.
Umm, you do realize no one manually enters all of the spaces, right? Basically all editors support an expandtab feature which inserts the amount of spaces you want whenever you hit the tab key.
Code formatters behave exactly the same regardless if you're using tabs or spaces, so not sure what you're talking about.
I did not miss the point. I fully understand that's why people want tabs. I just think it's a pretty stupid and petty reason to make for a worse experience when viewing code in places you don't control. I still don't know why using spaces is an issue when we enforce standards in literally every other facet of contributing to a codebase. We enforce coding styles. Indentation is part of the coding style.
Tabs exist specifically for spacing out stops. They're viewer-configurable, avoiding holy wars about 4 or 8 or that one idiot suggesting 3.
I do not give a shit if your seventeen-argument function has the overflow variables line up exactly with the paren. Just put them one step further in.
I just remembered the dumbest argument I've ever suffered about this - someone insisting the "length" of one tab changed, depending on what's before it. As in, is it eight spaces, or seven? Or six! It only goes up to eight spaces! No. It goes one stop. The same way a newline goes one line, and cannot by measured by how many times you'd slap the spacebar to get text to wrap around to the next line.
Err, why would there ever be something besides a tab before a tab? Are we doing ASCII art?
They mean if you insert a tab after some other text.
Word processors and desktop publishing apps tend to have tab stops (sometimes visible in a ruler at the top of the page) and pressing tab goes to the next tab stop. They're about an inch apart (assuming letter or A4 paper) by default, and you can usually also add your own tab stops. For example, you might have text like this:
Hi
Hello
Assuming the next tab stop is to the right of both words, pressing tab at the end of each one would actually bring you to the same indentation level:
Hi |
Hello |
Text editors and IDEs don't do that, and instead make all tabs the same size regardless of where they are.
Some people want the word processor implementation in text editors though. The comment you replied to is saying that's dumb, and I agree with them.
Any ides have support for this? I feel like I've been waiting forever.
Essentially no. I wish so badly that this had taken off.
Edit: as noted on the website, various plug-ins that attempt support are in fact not correct.
What do you mean? There's a ton of working plugins listed on the website for many editors.
Sorry, my phrasing was sloppy. Most popular IDEs and editors do not have a plug-in or setting that implements elastic tabstops correctly. In particular, there's no implementation for vim, emacs, VSCode, eclipse, or any JetBrains IDEs. (I had forgotten that there's one for Visual Studio and one for Notepad++.)
The sole purpose of the tab key is for instructing the editor to insert four spaces.
To insert a........ TAB. Not four or any n number of space but TAB
After years of ass-whopping by python interpreter for stray tab characters, I'm now mentally rejecting the existence of tab character in my computing devices.
Isnt that only because you "mixed" spaces with tabs? I have had no issues with python and tabs with no spaces for intendation
Cycling through buttons, atl+tab, Ctrl+tab, some other fourth thing.
*three spaces.
Actually, let's make that two.
2 space gang represent.
They fear us. We have to hide in the shadows.
But this is just one more example of our superiority - a perfect compromise between the file size and the nightmare that is two different invisible characters
Let's just avoid indentation at all (jk).
Always remember:
“He's me.” - Obi Wan Kenobi
Man how are we gonna write all of our Whitespace programs now?
But like... Correct me if I'm wrong but in my experience tab does not always equal 4 spaces.
E: thanks all. I didn't fully understand.
That's one of the benefits of using tabs. Some people might like 4 spaces for indentation, whereas others like 2 spaces. If you use tabs, you can configure your editor to use whatever tab size you want, and they're just stored as tab characters in the file.
Tabs for indentation, spaces for alignment (eg for ASCII art).
That's why it's also a big accessibility feature. With big font sizes, four spaces are distracting but you can configure tabs to show up as one character, which is way more reasonable with font sizes larger than usual
I had a colleague that is legally blind in my second real job. The dude is brilliant (and hilarious) but these things would significantly enable or screw up his productivity. I have always felt fortunate to have had direct butt in seat exposure to the importance of accessibility at such a young age.
You’re misunderstanding. In this case it means “one tab character” instead of “four space characters”.
Spaces are supiror because its easier to text boxes.
I know it’s a joke but I prefer the tab option. It’s easy to convert tabs to any particular spacing or code point width. It can also vary, if wanted, based on terminal or editor type.
People with worse eyesight can have a wider indentation while those who choose can opt for something more compact
Honestly I always preferred tabs for indentation and spaces for aligning. It doesn't break anyone's experience. And if somebody wants
two spaces fora two-space-tab-width for indentation and other people prefer four. That will work just fine.I hate seeing 2 space indents. Unreadable AF ( to me ). At least this way I can easily work in the same codebase without somebody being annoyed ( except for the crying about the tabs )
Why not tabs for both indentation and alignment? (Actually, I see indentation as just a specific use of alignment.) Word processors have been doing it for decades (and typewriters for over a century!). Surely we can convince our code processors to use user-definable, fixed position tabs instead of relative position "tab = x spaces".
Keeping the [TAB] character in the file then allows everyone the layout they like.
Or has working solo for 40 years fried my brain?
What I mean with tab = x spaces is only visually and not actually ( there will ( obviously) still be a tab character in my preference. Not sure if that was clear.
Because alignment are fixed characters compared to indentation. For indentation the only question is how many characters the next indentation needs to be.
For alignment it is not fixed. As an example of PHP code:
The dots would be spaces because in IDEs people generally use a font where every character is equally wide.
If I would tab again instead of spaces it could work out if my tab length display is ( for one or more ) adds up to the width of the variable
$obj. If somebody else has a tab width of 2 rather than somebody who has 3. It would only align for one of the two people.Does make sense? I typed it out after a gym session on my phone.
Additionally. The whole problem is resolved by using spaces for both alignment and indentation. But in the cursor would still jump one space at a time rather than the whole tab ( although there are keyboard shortcuts for jumping words which would jump all of em.
I don't know. Call me old fashioned. I like what I like :/
The fact that you had to explain this is the reason why tabs are inferior in practice. People just don't get it and then in collaborative projects you get a completely misaligned mess because not everyone has the same tab size.
Yeah, I understood the arguments against using tabs for alignment, but never really got the argument against using them for indentation.
I can't imagine it would be difficult for an IDE to scale the width of spaces found at the start of a line, to emulate this same customization while still preserving my sanity as a fervent space-indenter. I've never seen an IDE that does this, but it'd be an interesting compromise.
What if instead of having the IDE special case space characters at the start of a line, we had a special character that could represent a variable width space?
As a fan of tabs I see this as an absolute win
Tabs are objectively the better choice as it allows each dev individually to decide tab width in their editors. Spaces in contrast don't allow this same flexibility as they are used for much more than simply indentation, for example you likely put a space after each argument or operator IE
func(arg1, arg2)or1 + 2.Also, a lot of editors won't unindent on backspace of spaces indentation, so I end up messing up the indentation with a 3/4 indent
That just sounds like a shitty editor, tbh. Pretty basic functionality.
Autoformatter should fix that, unless you use python. (but even then they might fix it to the closest proper indentation level)
Sometimes. I love auto formatting, I spam the shit out of it more than I spam save but it's definitely not perfect. It gets real confused with inconsistent indention like that. Especially with Python it'll fuckup
Too much waste of space imo,
func(arg1,arg2)or1+2is faster to write and to read.Stilltoomuchwasteofspace
Whyusemanywordwhenfewworddotrick?
Code can be viewed in more than just an editor. It might be in a terminal, rendered in a browser, etc. Sometimes you might even have to view it in an environment you don't control. I am very disinterested in configuring each and every tool to have sensible tabstops, if such a tool can even be configured.
Then don't? The whole reason nearly all the spaces guys do 4 spaces is cause that's the nearly universal tab width. You won't like this but the same exact argument can be made for spaces yet I'd bet you haven't even once configured the width of those.
I don't actually change tab width, it's the default 4 spaces equivalent for me but just because I don't take advantage of the ability doesn't mean I should prevent others from doing so.
That is provably wrong. The default tab width in vim is 8 spaces, and the default indentation in yaml is two spaces.
What's yaml have to do with anything? It's like python with syntactic whitespace which is unrelated to this discussion. The Tab vs Space debate is entirely around non syntactic whitespace which doesn't effect how the code is parsed. And yes Python technically does both tabs and spaces but it's all sorts of fucky.
Terminal editors while still used a ton aren't really what I was referring to. Newer terminal editors such as Helix have tab width configured per language most of which default to a width of 4 spaces but toml/yaml both default to 2 spaces. I was mainly referring to GUI editors as frankly that's just what most people use nowadays. JetBrains IDEs, Visual Studio, Eclipse, VS Code, Notepad++ were primarily what I was thinking of as I've used all of them and they all default to a tab width of 4 hence why I said nearly universal. Also I said nearly terminal editors being the only editors I've used that don't default to a width of 4 seems like a fair usage of the term.
This is simply false, many systems have them configured by default to 8, particularly most CLI tools. Git, for example, is 8, and btw, changing it is not readily done and requires you to hack around it by using a custom pager command. In fact, all core gnu utils (and even bash itself) default to 8, as well vim, emacs, nano, gedit, etc.
I use 2 spaces since I work in Haskell, which is a significant whitespace language where you want certain syntactic constructs to exist at a different level of indentation from your main code block. So yes, I have configured it. 2 spaces is also exceedingly common for HTML (browser Dev tools renders HTML with 2 spaces, even).
There is not a universal indentation width, though it is almost always universal within a particular language or perhaps project, in which case it's much better to have everything standardized. Code formatters enforced on a project are the norm, and those are way more impactful on how the code is read. But they are valuable because consistency is valuable. And yet, somehow you don't have huge scores of developers complaining about being forced to format their code in a way they don't like.
As I said, you don't necessarily control the environment in which you are viewing code. A common example is reading code over a shared screen. So you can easily end up reading code in a way you don't like anyway, so it may as well be some reasonable (if not preferable) standard that everyone is using.
Looking at code on somebody else's screen is entirely missing the point of using tabs over spaces. The entire point is that mine looks like how I want and theirs looks like how they want even though the file is identical. We can each have wildly different tab width and it'll look wildly different to each of us when we program. That's again the point.
Code formatters are great! I love them. Using tabs over spaces is objectively a better formatting option. One of my favorite features in code formatters is that they'll swap out spaces to tabs for you insane people who insist on mashing the space bar to indent.
Umm, you do realize no one manually enters all of the spaces, right? Basically all editors support an
expandtabfeature which inserts the amount of spaces you want whenever you hit the tab key.Code formatters behave exactly the same regardless if you're using tabs or spaces, so not sure what you're talking about.
I did not miss the point. I fully understand that's why people want tabs. I just think it's a pretty stupid and petty reason to make for a worse experience when viewing code in places you don't control. I still don't know why using spaces is an issue when we enforce standards in literally every other facet of contributing to a codebase. We enforce coding styles. Indentation is part of the coding style.
Tabs exist specifically for spacing out stops. They're viewer-configurable, avoiding holy wars about 4 or 8 or that one idiot suggesting 3.
I do not give a shit if your seventeen-argument function has the overflow variables line up exactly with the paren. Just put them one step further in.
I just remembered the dumbest argument I've ever suffered about this - someone insisting the "length" of one tab changed, depending on what's before it. As in, is it eight spaces, or seven? Or six! It only goes up to eight spaces! No. It goes one stop. The same way a newline goes one line, and cannot by measured by how many times you'd slap the spacebar to get text to wrap around to the next line.
Err, why would there ever be something besides a tab before a tab? Are we doing ASCII art?
They mean if you insert a tab after some other text.
Word processors and desktop publishing apps tend to have tab stops (sometimes visible in a ruler at the top of the page) and pressing tab goes to the next tab stop. They're about an inch apart (assuming letter or A4 paper) by default, and you can usually also add your own tab stops. For example, you might have text like this:
Assuming the next tab stop is to the right of both words, pressing tab at the end of each one would actually bring you to the same indentation level:
Text editors and IDEs don't do that, and instead make all tabs the same size regardless of where they are.
Some people want the word processor implementation in text editors though. The comment you replied to is saying that's dumb, and I agree with them.
Hell yeah tabs
The correct answer is, was and always has been elastic tabstops
Any ides have support for this? I feel like I've been waiting forever.
Essentially no. I wish so badly that this had taken off.
Edit: as noted on the website, various plug-ins that attempt support are in fact not correct.
What do you mean? There's a ton of working plugins listed on the website for many editors.
Sorry, my phrasing was sloppy. Most popular IDEs and editors do not have a plug-in or setting that implements elastic tabstops correctly. In particular, there's no implementation for vim, emacs, VSCode, eclipse, or any JetBrains IDEs. (I had forgotten that there's one for Visual Studio and one for Notepad++.)
The sole purpose of the tab key is for instructing the editor to insert four spaces.
To insert a........ TAB. Not four or any n number of space but TAB
After years of ass-whopping by python interpreter for stray tab characters, I'm now mentally rejecting the existence of tab character in my computing devices.
Isnt that only because you "mixed" spaces with tabs? I have had no issues with python and tabs with no spaces for intendation
Cycling through buttons, atl+tab, Ctrl+tab, some other fourth thing.
*three spaces.
Actually, let's make that two.
2 space gang represent.
They fear us. We have to hide in the shadows.
But this is just one more example of our superiority - a perfect compromise between the file size and the nightmare that is two different invisible characters
Let's just avoid indentation at all (jk).
Always remember:
“He's me.” - Obi Wan Kenobi
Man how are we gonna write all of our Whitespace programs now?
But like... Correct me if I'm wrong but in my experience tab does not always equal 4 spaces.
E: thanks all. I didn't fully understand.
That's one of the benefits of using tabs. Some people might like 4 spaces for indentation, whereas others like 2 spaces. If you use tabs, you can configure your editor to use whatever tab size you want, and they're just stored as tab characters in the file.
Tabs for indentation, spaces for alignment (eg for ASCII art).
That's why it's also a big accessibility feature. With big font sizes, four spaces are distracting but you can configure tabs to show up as one character, which is way more reasonable with font sizes larger than usual
I had a colleague that is legally blind in my second real job. The dude is brilliant (and hilarious) but these things would significantly enable or screw up his productivity. I have always felt fortunate to have had direct butt in seat exposure to the importance of accessibility at such a young age.
You’re misunderstanding. In this case it means “one tab character” instead of “four space characters”.
Spaces are supiror because its easier to text boxes.
Edit: til tabs make code blocks in lemmy
Unexpected Keyboard