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