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.
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.
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.