If you open it in an editor and have the same tab width configured as the author, you'll see no indentation and alignment problems. If you set a different tab width (the purported advantage of tabs), the code will be messed up (the actual disadvantage of tabs).
Not sure why you blame this on GitHub. Emacs with a tab width of 2 or vim with a tab width of 8 will also show this code with broken formatting.
This is easily solved with something like .editorconfig.
I personally use four spaces. What I was trying to point out is that this is not necessarily "bad code standards" from the author. As long as everyone in the project is onboard, and tooling support means the code is perfectly readable, I really don't care if you would use seven poop emojis for indentation.
Yep. It's not a github problem, it is a problem with the code mixing tabs and spaces for indentation.
It never ceases to amaze me just how many programmers don't understand tabs. I guess it's because they look like spaces Or because every programmer at some point got bitten by the issue but instead of learning how to use tabs correctly learnt that tabs are evil.
The tabs vs spaces war is all just a massive misunderstanding due to some people (the spaces people) not understanding tabs (and not understanding that nobody is advocating using tabs for alignment purposes).
> not understanding that nobody is advocating using tabs for alignment purposes
It's not about advocating, it's about actual use as in the example above. Tab fans get confused about what they are doing and put hard tabs where there shouldn't be any.
If tab users were actually perfectly consistent about using only tabs only for indentation but not alignment, things would be fine. In practice most of them don't understand the issues and even those that do understand them apparently fail to be consistent in practice. Which is not surprising, since tabs are just as invisible as spaces in most environments.
I've said it before, I'll say it again: I've worked on several projects that were halfway through a painful tabs-to-spaces transition period, and they all said "no tabs in new code, never again a project where we allow tabs". I've never had the opposite experience. In practice, as used by actual humans that need to work together, tabs don't work well.
Yeah, I guess that is also my experience and it correlates with what I do. I think that tabs for indentation and spaces for alignment is correct, but in practice I use spaces and have done for most of my career (apart from go).
Tabs polute an otherwise perfectly simple concept, fixed width fonts. If they had't existed out of the gate, no one would have ever considered asking for it, especially if the reason was "I want to be able to pick my own indentation level". They'd be laughed out of the industry. You want the whole world to worry about your prefered indentation level every single time they start a new line? Thats never going happen. Take the indentaion level your given and burden yourself with the task of writting a feature for your editor that lets you pick what you like instead. Oh, and have fun fighting with it every time you open a file you didn't write.
Not sure why you blame this on GitHub. Emacs with a tab width of 2 or vim with a tab width of 8 will also show this code with broken formatting.