I want to like tabs. They're the semantically correct character to use. But it's like you said: with spaces, I know (for sure) that the way I see my code is the same way you or anyone else will see it because there's only one way to render a space; with tabs, i don't know if you will have a good experience or not, because it depends on all your tools being set up to handle tabs sensibly (IDE, command line, git, github, etc.)
And worst case (pre-lintinters) someone invariably mixes spaces in with tabs (in my experience) . It looks fine to them because they have the same number of spaces as their tab-width, but to anyone else it's downright horrible.
And a side note on non-code tab usage. I should be able to tab separate values and whatever renders that should figure out how wide the space needs to be to vertically align items with the same number of tabs deep (regardless of length of data in between previous tabs). A tab le if you will. But has that ever worked? Tab being a rarer character makes much more sense to use than commas, commas are everywhere, and yet...
I'm gonna pick on you a bit, just because you spelled out this particular sentiment (that I loathe in programming). I don't mean it as anything personal. But here's your quote:
I know (for sure) that the way I see my code is the same way you or anyone else will see it because there's only one way to render a space; with tabs, i don't know if you will have a good experience or not, because it depends on all your tools being set up to handle tabs sensibly
This is what really drives me bonkers sometimes about those who advocate spaces. They're not content to see things with, say, a 2-space indent in their IDE. They must ensure that everyone else is looking at the code with a 2-space indent. We now have these amazingly sophisticated IDEs that can do so much to format code however a particular dev wants to see it. But when you use spaces, you basically undercut all of that functionality.
It's quite possible that you prefer 2-space indents, and Mary prefers 1-space indents, and Joe prefers 9-space indents. And with tabs, everyone can view the code in the way that's most comfortable for them. But I've run into soooo many coders who feel it's imperative that I read code in the way that is most comfortable for them. IMHO, it's one of the most nonsensical forms of control that I've witnessed in dev. I'm sorry, but it's just sorta silly to imply that, if you see the code in your IDE with 2-space indentation, that there's anything wrong if I view that same code with 3-space indentation.
The key here is that you shouldn't be responsible for whether or not I "have a good experience or not". I'm a big boy. I can configure my IDE. If the tabs in the code are too wide or narrow for my taste, I can fix it. And it's not like you have to do a bunch of work to get an IDE to "handle tabs sensibly". It's 2020. As far as I've seen, every IDE handles tabs "sensibly" out-of-the-box. You may want to adjust them to your liking. But it's not as though opening a code file with tabs will blow up an IDE unless it's been heavily pre-configured.
But when you peg everything to a 2-space indent, you're basically saying, "Are those indents too narrow for you? Does it make it harder for you to read the code? Well, guess what?? I don't friggin care. Because I wrote the code with 2-space indents on my monitor. And therefore, everyone else should have to look at it in the exact same way!"
And worst case (pre-lintinters) someone invariably mixes spaces in with tabs (in my experience) . It looks fine to them because they have the same number of spaces as their tab-width, but to anyone else it's downright horrible.
I totally agree with this. Although I would prefer tabs if it were my choice (usually, it's not), I do understand that you need to pick tabs-or-spaces. Because if you start mixing them up in the same project, files start to become a mess when others open them.
I want to agree with you; and I don't want to "control" how you view the code. I'll clarify that I really am focused on the "worst case" of mixed tabs and spaces in my opinion on "know[ing] that the way I see my code is the same way you or anyone else will see it". Which some styles of coding would essentially require mixing tabs and spaces; see this multilined example of a validation in ruby on rails (borrowed from real examples I've seen in production code):
(We can have a separate discussion on if this is a good style or not, but) How would I write that with tabs? should I have 2 tabs and 2 spaces? 4 tabs and 2 spaces? 10 spaces? Now I have mixed indention that will be subtly broken for everyone who isn't me.
We now have these amazingly sophisticated IDEs that can do so much to format code however a particular dev wants to see it
Just as a counterpoint; not all code is written and read in IDEs. They also appear in command lines; in git clients; in GitHub (or GitLab or BitBucket etc.); in CodePen's; in StackOverflow; in DEV posts and comments :) ...
To be honest, it shouldn't be that difficult for these "sophisticated" IDEs to solve this problem by treating groups of 2 or 4 (or whatever) spaces as something to be rendered with a different width (same width as tab would be). This solves the problem of always being forced to see unaccessible indentation with the problem of getting all the various places code appears to render tabs "correctly".
So, semantically I want tabs; but for historical reasons I see why spaces were chosen.
It seems logical to me (a statement with the arguments being a nested thing (thus the indentation)). This would not introduce the problem you described (mixing tabs and spaces), though it might not be liked by some people because there's one line that could be gone.
Here's another way to think about the "good experience" that others may-or-may-not have when reading your code:
Every dev that I've seen coding over the last couple of decades uses some form of code coloring. Sometimes it's subtle (like the default coloring in Eclipse, with a white background and a lot of black text - and only certain things colored). Sometimes it's more glaring (like Sublime's default "Twilight" theme). But the points I'm trying to hit here are that:
We almost all use code coloring.
Code coloring can be wildly inconsistent between developers - even those working on the same team, on the same project.
Code coloring is an extremely personal choice - the colors that you see as borderline unreadable may be my ideal setup.
Code coloring can even be a factor in accessibility - as in, the coloring scheme that you use may actually make it difficult or impossible for me to read the code.
Thankfully, none of these points are much of a "concern" to anyone. That's because we can all set our own IDE to use the color scheme that's best for us. If someone complains that the color scheme in their IDE makes it hard to read the code, and they aren't having a "good experience", the logical answer is, "Well, then spend a little time to change your color scheme and find one that works for you."
But imagine if you couldn't set your own color scheme. Imagine if the team had decided for you that you would use a particular color scheme - regardless of what you think about it. And imagine that the color choice was somehow codified directly in the project itself. So every time you open one of those code files, you have no choice but to read the code file in a color scheme that's been dictated by the programmer/team/style guide. Would you appreciate that level of forced conformity??
That's what spaces do. They decide for you how you will read the code - even though we could use tabs, and everyone could decide for themselves how they prefer to read it.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
A good analogy I think! In some ways it breaks down I think; color-coding is derived from the parsed meaning of the code where indention (aside from python and edge-cases) has no meaning to the interpretation of the code. Indention is only there for those reading it and has no effect on program execution... hmmm so actually, should we just stop indenting our code at all and have our IDE's decide how much indention to render (they already basically do this with helpful pre-indenting lines in many cases)?
(that would also solve the "whitespace-only" diff problems in git 🤔)
Our IDEs absolutely do decide "how much indentation to render". But that's not really the question. The question is: How wide is each indentation??
People can laugh at my geriatric-ness if they like, but the simple fact is that there are many times when my eye tends to get "lost" when I try to follow multiple, indented layers of logic that are only represented by 2 spaces. For my personal taste, if I can simply add one more space to the width, all of that confusion goes away. And if we used tabs, we could all determine an indentation width that works for each of us.
But with spaces, that ability is taken away from me. I must view it with 2-space widths - because someone else decided that's the way that I "should" read the code - even if that way is harder for me to follow.
I know (for sure) that the way I see my code is the same way you or anyone else will see it
Exactly: Now consider that, no matter how much you like yow you see your code, someone else might feel differently about it. Accessibility is one factor, screen space is another, and someone might just like an indentation of 7 because it's prime.
The thing is: you don't need to worry. One tab means one level of indentation. It doesn't have to look the same for everyone, and I can't think of a scenario where some code might look worse because of a different tab width.
One tab means one level of indentation. It doesn't have to look the same for everyone, and I can't think of a scenario where some code might look worse because of a different tab width.
I agree; I'm very much focused on my "worst case" scenario of mixed tabs and spaces.
Semantically I'm on team tabs; but practically I see why spaces have been chosen.
I hear that "worst case" example of mixed tabs and spaces a lot, but it doesn't really make sense to me:
If using tabs would cause trouble because people would push code with spaces, how come it's not a problem when using spaces that people would push code with tabs?
Also, this can easily be tested, so people would see that the tests fail and correct it.
I felt like trying it out and just added a test to one of my projects that checks whether all the code files are indented with spaces:
With all due respect, I think that your "worst case" scenario is a bit of a contrived edge case. I'm not claiming that there aren't certain styles that use tabs and spaces. But I am claiming that, if you've purposely chosen a style that mixes both, you are pretty far out of the mainstream and probably implementing that "mixed" standard to make some kinda point.
@defman
illustrated how that example could easily be handled by using only tabs. And of course, it could easily be handled by using only spaces. If you personally insist on using both, well, that's fine. But I can't really use that as an explanation of why tabs are bad and spaces are good.
But there's no need (other than personal preferences) to use both tabs and spaces. After writing Java code for years, there was never a single moment when I (or anyone around me) said, "Dang! This is just so difficult because I can only use tabs for my indentation, and not spaces." And of course, I've never heard anyone using spaces who complained that they couldn't achieve the proper formatting.
To be absolutely clear, I prefer tabs. But if the team insists on using spaces, then the clearly-superior approach is to... wait for it... use spaces. As a shared standard.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Super great look at your experience!
I want to like tabs. They're the semantically correct character to use. But it's like you said: with spaces, I know (for sure) that the way I see my code is the same way you or anyone else will see it because there's only one way to render a space; with tabs, i don't know if you will have a good experience or not, because it depends on all your tools being set up to handle tabs sensibly (IDE, command line, git, github, etc.)
And worst case (pre-lintinters) someone invariably mixes spaces in with tabs (in my experience) . It looks fine to them because they have the same number of spaces as their tab-width, but to anyone else it's downright horrible.
And a side note on non-code tab usage. I should be able to tab separate values and whatever renders that should figure out how wide the space needs to be to vertically align items with the same number of tabs deep (regardless of length of data in between previous tabs). A tab le if you will. But has that ever worked? Tab being a rarer character makes much more sense to use than commas, commas are everywhere, and yet...
I'm gonna pick on you a bit, just because you spelled out this particular sentiment (that I loathe in programming). I don't mean it as anything personal. But here's your quote:
This is what really drives me bonkers sometimes about those who advocate spaces. They're not content to see things with, say, a 2-space indent in their IDE. They must ensure that everyone else is looking at the code with a 2-space indent. We now have these amazingly sophisticated IDEs that can do so much to format code however a particular dev wants to see it. But when you use spaces, you basically undercut all of that functionality.
It's quite possible that you prefer 2-space indents, and Mary prefers 1-space indents, and Joe prefers 9-space indents. And with tabs, everyone can view the code in the way that's most comfortable for them. But I've run into soooo many coders who feel it's imperative that I read code in the way that is most comfortable for them. IMHO, it's one of the most nonsensical forms of control that I've witnessed in dev. I'm sorry, but it's just sorta silly to imply that, if you see the code in your IDE with 2-space indentation, that there's anything wrong if I view that same code with 3-space indentation.
The key here is that you shouldn't be responsible for whether or not I "have a good experience or not". I'm a big boy. I can configure my IDE. If the tabs in the code are too wide or narrow for my taste, I can fix it. And it's not like you have to do a bunch of work to get an IDE to "handle tabs sensibly". It's 2020. As far as I've seen, every IDE handles tabs "sensibly" out-of-the-box. You may want to adjust them to your liking. But it's not as though opening a code file with tabs will blow up an IDE unless it's been heavily pre-configured.
But when you peg everything to a 2-space indent, you're basically saying, "Are those indents too narrow for you? Does it make it harder for you to read the code? Well, guess what?? I don't friggin care. Because I wrote the code with 2-space indents on my monitor. And therefore, everyone else should have to look at it in the exact same way!"
I totally agree with this. Although I would prefer tabs if it were my choice (usually, it's not), I do understand that you need to pick tabs-or-spaces. Because if you start mixing them up in the same project, files start to become a mess when others open them.
Thanks for picking on me! :P
I want to agree with you; and I don't want to "control" how you view the code. I'll clarify that I really am focused on the "worst case" of mixed tabs and spaces in my opinion on "know[ing] that the way I see my code is the same way you or anyone else will see it". Which some styles of coding would essentially require mixing tabs and spaces; see this multilined example of a validation in ruby on rails (borrowed from real examples I've seen in production code):
(We can have a separate discussion on if this is a good style or not, but) How would I write that with tabs? should I have 2 tabs and 2 spaces? 4 tabs and 2 spaces? 10 spaces? Now I have mixed indention that will be subtly broken for everyone who isn't me.
Just as a counterpoint; not all code is written and read in IDEs. They also appear in command lines; in git clients; in GitHub (or GitLab or BitBucket etc.); in CodePen's; in StackOverflow; in DEV posts and comments :) ...
To be honest, it shouldn't be that difficult for these "sophisticated" IDEs to solve this problem by treating groups of 2 or 4 (or whatever) spaces as something to be rendered with a different width (same width as
tabwould be). This solves the problem of always being forced to see unaccessible indentation with the problem of getting all the various places code appears to render tabs "correctly".So, semantically I want tabs; but for historical reasons I see why spaces were chosen.
If everyone used tabs, your code example would probably look something like this:
It seems logical to me (a statement with the arguments being a nested thing (thus the indentation)). This would not introduce the problem you described (mixing tabs and spaces), though it might not be liked by some people because there's one line that could be gone.
Here's another way to think about the "good experience" that others may-or-may-not have when reading your code:
Every dev that I've seen coding over the last couple of decades uses some form of code coloring. Sometimes it's subtle (like the default coloring in Eclipse, with a white background and a lot of black text - and only certain things colored). Sometimes it's more glaring (like Sublime's default "Twilight" theme). But the points I'm trying to hit here are that:
Thankfully, none of these points are much of a "concern" to anyone. That's because we can all set our own IDE to use the color scheme that's best for us. If someone complains that the color scheme in their IDE makes it hard to read the code, and they aren't having a "good experience", the logical answer is, "Well, then spend a little time to change your color scheme and find one that works for you."
But imagine if you couldn't set your own color scheme. Imagine if the team had decided for you that you would use a particular color scheme - regardless of what you think about it. And imagine that the color choice was somehow codified directly in the project itself. So every time you open one of those code files, you have no choice but to read the code file in a color scheme that's been dictated by the programmer/team/style guide. Would you appreciate that level of forced conformity??
That's what spaces do. They decide for you how you will read the code - even though we could use tabs, and everyone could decide for themselves how they prefer to read it.
Please don't apply that argument to syntax.
There's already enough people complaining that Anglicization of programming languages is some kind of Marxist oppression.
A good analogy I think! In some ways it breaks down I think; color-coding is derived from the parsed meaning of the code where indention (aside from python and edge-cases) has no meaning to the interpretation of the code. Indention is only there for those reading it and has no effect on program execution... hmmm so actually, should we just stop indenting our code at all and have our IDE's decide how much indention to render (they already basically do this with helpful pre-indenting lines in many cases)?
(that would also solve the "whitespace-only" diff problems in git 🤔)
Our IDEs absolutely do decide "how much indentation to render". But that's not really the question. The question is: How wide is each indentation??
People can laugh at my geriatric-ness if they like, but the simple fact is that there are many times when my eye tends to get "lost" when I try to follow multiple, indented layers of logic that are only represented by 2 spaces. For my personal taste, if I can simply add one more space to the width, all of that confusion goes away. And if we used tabs, we could all determine an indentation width that works for each of us.
But with spaces, that ability is taken away from me. I must view it with 2-space widths - because someone else decided that's the way that I "should" read the code - even if that way is harder for me to follow.
Exactly: Now consider that, no matter how much you like yow you see your code, someone else might feel differently about it. Accessibility is one factor, screen space is another, and someone might just like an indentation of 7 because it's prime.
The thing is: you don't need to worry. One tab means one level of indentation. It doesn't have to look the same for everyone, and I can't think of a scenario where some code might look worse because of a different tab width.
I agree; I'm very much focused on my "worst case" scenario of mixed tabs and spaces.
Semantically I'm on team tabs; but practically I see why spaces have been chosen.
I hear that "worst case" example of mixed tabs and spaces a lot, but it doesn't really make sense to me:
If using tabs would cause trouble because people would push code with spaces, how come it's not a problem when using spaces that people would push code with tabs?
Also, this can easily be tested, so people would see that the tests fail and correct it.
I felt like trying it out and just added a test to one of my projects that checks whether all the code files are indented with spaces:
github.com/DarkWiiPlayer/restia/bl...
It was easier than expected :D
With all due respect, I think that your "worst case" scenario is a bit of a contrived edge case. I'm not claiming that there aren't certain styles that use tabs and spaces. But I am claiming that, if you've purposely chosen a style that mixes both, you are pretty far out of the mainstream and probably implementing that "mixed" standard to make some kinda point.
@defman illustrated how that example could easily be handled by using only tabs. And of course, it could easily be handled by using only spaces. If you personally insist on using both, well, that's fine. But I can't really use that as an explanation of why tabs are bad and spaces are good.
But there's no need (other than personal preferences) to use both tabs and spaces. After writing Java code for years, there was never a single moment when I (or anyone around me) said, "Dang! This is just so difficult because I can only use tabs for my indentation, and not spaces." And of course, I've never heard anyone using spaces who complained that they couldn't achieve the proper formatting.
To be absolutely clear, I prefer tabs. But if the team insists on using spaces, then the clearly-superior approach is to... wait for it... use spaces. As a shared standard.