#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
In my previous job I succeeded in enforcing 4-space indentation to JS codebases, although mostly because for a long time I was the only mainly JavaScript developer around. However now that I'm gone I kinda expect the new guys to eventually swap it over as they really seemed to go for anything that is trendy.
Then there is the fact that tools like Prettier default to 2-space, and have edge case rules that end up to 2-space indentation even when you tell it to indent by 4-space. That is just silly.
Would prefer tabs because then you could just set the indentation to whatever you prefer over being forced to 2-space soup. If JS devs knew CSS (most of them really don't even if they claim to) you'd just tell tab-size: 4 or whatever you like. Actually, it might be Internet Explorer that killed tabs, because IE never supported tab-size. Chrome added support in version 21... in July 2012. Firefox added support in early 2011. So I guess you could argue tabs were killed by browser CSS by not having support for tab-size until around 2013 considering evergreen browsers was still an emerging idea at the time.
When I've been lucky enough to do green-fields work, I've lobbied the rest of the team for 3-space indents. And the funny thing is that I've never gotten any pushback on it. No one else ever seems to mind. Which is doubly-frustrating for me, because 2-space indents actually present a (minor) difficulty for me. And yet I'm typically looking at 2-space-indented code simply because someone decided years ago that it should be the standard for JS.
You make a really good point about the tab-size CSS feature. If you accept my contention that viewing code in browsers exacerbates the tab hatred, then it makes sense to point the finger at the lack of configurable tab sizes in HTML (in the past). I hadn't even thought of it to that level.
On an even-more-tangential note, it still baffles me that the default indentation for tabs in HTML is 8 spaces. I'm not sure where that came from. I can't think of any other tool I've ever opened where 8-space indents were the default way to display a TAB character.
// , “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)
This works with pretty much all GitHub links, and recently also works with gist.github.com links. It's annoying that the default isn't something more reasonable (maybe 4?), but you can change it quite easily.
#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
So can we blame Linus Torvalds? It would be nice to get some anger back from him.
But interesting in general that there actually were 8-space indents in the 90's.
I also wonder if the 8-space tabs could have come from spreadsheet editors of the old age. Weren't the cells 8 characters by default?
Ooh, I like that link. Specifically, I like the idea of using longer tab lengths to highlight potential code smells. Despite my long experience, it was only about, ohh, 4-5 years ago when I really started aggressively attacking my own nested code blocks. Originally, I didn't see much problem with them. But I've now come over to the camp that deeperNesting === codeThatShouldProbablyBeRefactored.
As for the spreadsheet observation - yeah... I think that may be one of the original culprits. I know I've heard that before.
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.
In my previous job I succeeded in enforcing 4-space indentation to JS codebases, although mostly because for a long time I was the only mainly JavaScript developer around. However now that I'm gone I kinda expect the new guys to eventually swap it over as they really seemed to go for anything that is trendy.
Then there is the fact that tools like Prettier default to 2-space, and have edge case rules that end up to 2-space indentation even when you tell it to indent by 4-space. That is just silly.
Would prefer tabs because then you could just set the indentation to whatever you prefer over being forced to 2-space soup. If JS devs knew CSS (most of them really don't even if they claim to) you'd just tell
tab-size: 4
or whatever you like. Actually, it might be Internet Explorer that killed tabs, because IE never supportedtab-size
. Chrome added support in version 21... in July 2012. Firefox added support in early 2011. So I guess you could argue tabs were killed by browser CSS by not having support fortab-size
until around 2013 considering evergreen browsers was still an emerging idea at the time.When I've been lucky enough to do green-fields work, I've lobbied the rest of the team for 3-space indents. And the funny thing is that I've never gotten any pushback on it. No one else ever seems to mind. Which is doubly-frustrating for me, because 2-space indents actually present a (minor) difficulty for me. And yet I'm typically looking at 2-space-indented code simply because someone decided years ago that it should be the standard for JS.
You make a really good point about the
tab-size
CSS feature. If you accept my contention that viewing code in browsers exacerbates the tab hatred, then it makes sense to point the finger at the lack of configurable tab sizes in HTML (in the past). I hadn't even thought of it to that level.On an even-more-tangential note, it still baffles me that the default indentation for tabs in HTML is 8 spaces. I'm not sure where that came from. I can't think of any other tool I've ever opened where 8-space indents were the default way to display a
TAB
character.I always blame POSIX in in-person conversation, because nobody will bother to look it up.
Fun fact, you can do this:
github.com/DarkWiiPlayer/restia/bl...
vs.
github.com/DarkWiiPlayer/restia/bl...
(Note the
?ts=3
at the end)This works with pretty much all GitHub links, and recently also works with gist.github.com links. It's annoying that the default isn't something more reasonable (maybe 4?), but you can change it quite easily.
That's cool! I hadn't seen that little query string variable option before.
One guy claimed that Sun Java source was written in 8 tabs and was not very readable if you tried to look at it in 4 tabs.
But this is also interesting about Linux kernel docs: simplystatistics.org/2018/07/27/wh...
So can we blame Linus Torvalds? It would be nice to get some anger back from him.
But interesting in general that there actually were 8-space indents in the 90's.
I also wonder if the 8-space tabs could have come from spreadsheet editors of the old age. Weren't the cells 8 characters by default?
Ooh, I like that link. Specifically, I like the idea of using longer tab lengths to highlight potential code smells. Despite my long experience, it was only about, ohh, 4-5 years ago when I really started aggressively attacking my own nested code blocks. Originally, I didn't see much problem with them. But I've now come over to the camp that
deeperNesting === codeThatShouldProbablyBeRefactored
.As for the spreadsheet observation - yeah... I think that may be one of the original culprits. I know I've heard that before.