This is why you use tabs for indentation and spaces for alignment. Too bad most editors don't have good support for that.

> Too bad most editors don't have good support for that.

And this is why you use spaces for everything.

Or you just configure your editor to output spaces when you hit the tab key. Any serious text editor or IDE these days should have that option.

Yes. That's so common I didn't even think it necessary to mention.

I can't imagine anyone would manually press the spacebar N times to get the desired indentation level.

Oh, people do...

Use tabs for indentation and spaces for alignment and you will never have any problems using whatever tab width you want (except for potentially exceeding 80 char line length if you care about that. IMO that's secondary compared to the pros.)

... and get the worst possible experience? No thanks.

It can't be the worst experience if things actually line up.

I was being flippant but... things actually line up if you force everything to tabs too (or “smart tabs” if you really really want alignment for some reason).

Except with tabs everyone gets whatever width they want. Tab width is configurable system wide (and even in GitHub’s terrible web view).

Spaces are objectively worse in every possible way and require workarounds and editor hacks to make them behave like tabs. Skip a step & just use tabs: much better.

It's only objective if you're controlling the objectives. Here's my counter-example.

Go here in a browser: https://github.com/id-Software/Quake-III-Arena/blob/master/c...

Note that the use of tabs has caused un-alignment. You've claimed that tab width is configurable in git's web view, but I can't figure out how to do it.

And further, if it requires me to configure in a certain way, then it's not really true that "everyone can configure tabs how they want".

Spaces. Set it and forget it. Works everywhere, every time. Objectively better.

>Objectively better.

You can't really say that definitively without ignoring the laundry list of negatives that come with spaces. Spaces are not configurable at all. That, in itself, is reason enough that Tabs are "objectively better".

That’s due to the spaces tho, not the tabs. It’s the lines that used spaces that look awful.

You literally provided me with more proof spaces are bad. Good example.

Nope, it's the tabs. The only lines that are mis-aligned are mis-aligned because of tabs, not spaces. And it is a good example.

I see the exact opposite but.. k.

Interesting. Perhaps you've been using spaces all along, but somehow they appear to be tabs to you. What a twist that would be.

Or just don't bother with alignment and just use tabs for indentation. For example, instead of aligning function parameters after the opening parenthesis, move them to the next line and use a hanging indent:

    someType someFunctionName(
            param1, param2, ...)
    {
        statement1;
        statement2;
        ...
    }

I find that following a style like this will work equally well with tabs or spaces and that I have to spend less time formatting code I write (either manually or changing a setting in the editor I'm using).

This is a very good point, and I agree.

No matter how you do it[0], alignment is bad for maintainability. It happens that someType or someFunctionName changes, and if you use alignment, you'll have to re-align all those parameters. This is annoying to do even with editor help, and it generates noisy diffs which make patch review needlessly more difficult. Aligning the names of member variables is even worse.

Just Say No to alignment, perhaps? ;)

[0] Well, except if you use "elastic tabs", which don't have widespread support in the first place.

I recently found the answer for this. Sublime [0] with the Elastic Tabs[1] plugin[2].

[0] https://www.sublimetext.com/

[1] http://nickgravgaard.com/elastic-tabstops/

[2] https://github.com/SublimeText/ElasticTabstops

Also too bad both tabs and spaces are usually displaced as the same whitespace, which is a problem for humans.

This, too, can be fixed in most editors.

And the counter-argument remains that you can customize tabs to whatever length you want. Set "tab-size: 4;" in CSS.

Only works if people use tabs for indentation and spaces for alignment which I've never seen anybody maintain successfully on a big project. The code the parent linked is not indentation, it's alignment so it should be formatted using spaces regardless otherwise it breaks that way. If you have to impose tab width to have proper readability then what's the point? Try hacking the linux kernel with tabs != 8 spaces and see how long you last before all the broken alignment drives you crazy.

Furthermore if your coding style imposes some kind of width restriction you also have to commit to a certain tab width anyway.

Beyond that if you really value configurability it's a bit odd to limit yourself to "I want to configure tab width". How about bracket positions, spacing between operators, variable names etc... ? All these seems are arguably more important for readability and code understanding than indentation. Ideally programming languages would be stored as abstract syntax trees that you can display however you like but we're still using dumb all ASCII text files.

In theory tabs are mildly superior to spaces, pragmatically it's spaces all day every day as far as I'm concerned.

>Only works if people use tabs for indentation and spaces for alignment which I've never seen anybody maintain successfully on a big project.

It shouldn't be left to the devs.

All languages should have something like Go's gofmt -- or even better, mandatory whitespacing/tabs rules. If you don't respect them (which the auto format tool could help you automatically do), the program shouldn't compile.

> All languages should have something like Go's gofmt -- or even better, mandatory whitespacing/tabs rules. If you don't respect them (which the auto format tool could help you automatically do), the program shouldn't compile.

It exists `clang-format`

Formatters / indent do exist.

But they're not widely accepted by most languages devs (like gofmt is by Go programmers), nor is their use enforced by the compiler (even in Go).

That's the problem, though. People do that, and then to indent 12 spaces, your guy who uses 4-space tabs will put three tabs, your girl who uses 8-space tabs will put a tab and four spaces, and your ace who uses only spaces will put twelve spaces. And after a year of sharing code doing this, your formatting will be farked and you'll spend half your time fixing other peoples' "broken" indentation.

I have no issue whatsoever with using tabs in an editor, as long as it saves them as spaces on disk.

You do not "indent 12 spaces", you have levels of indentation. If you indent code only using tabs it doesn't matter whether you set your tab width to 4, 8 or 20, it will always display properly. Feel free to change your tab width hourly, still no problem.

The only valid argument is that mixing spaces and tabs for indentation messes things up, but that argument works both ways so doesn't support either side in this never ending argument.

It is trivial both to ban tabs and to bulk convert tabs to spaces in a codebase or presubmit hook. The other direction seems impossible.

That means that if you want to avoid a mixed codebase it is far easier to get to and stay at spaces only than tabs-for-indent, spaces-for-alignment.

Still messes with alignment if you want to do things like keep your comments aligned at the right of the page.

The solution is to have the repository refuse checkins with bad indentation. Anyone who can program can follow indentation rules, many people just can’t be bothered. But they can if there is no alternative.

Tabs for indentation, spaces for alignment.

You wouldn't need to customize anything, it would look good at all tab widths and people who prefer 2 space sized indents would be able to use that in their editors.

Actually, it could be even better, we could use tabs for aligning to tables too if editors supported elastic tabstops [0]. Unfortunately, the only ones that do don't support other essential features like saving when they lose focus.

Please note that i disagree with how the example aligns function params. The space/tab there looks bad and params should be aligned with spaces using a formatting tool (which every sane language should have).

Or, y'know, scratch that, why don't we commit the AST (enhanced to include comments and other hints like blank lines) to git and let everyone use their formatting.

</rant>

[0]: http://nickgravgaard.com/elastic-tabstops/

I'm pretty sure its perfectly aligned if you have the correct tab size that was used for the whole project. Which is the stupidest thing about using tabs over spaces.

It looks fine to me at even 8, so I'm not sure what you mean.

example:

https://github.com/id-Software/Quake-III-Arena/blob/master/c...

Okay, I can see the issue there. Though it's worth keeping in mind that tabs are for indentation and not alignment. Even people that use tabs would agree that is a poor use.

Ah yes tab, the only ascii character where the rendering is user configurable.

Not at all. ASCII 0x07 ("BEL") can do anything as long as it notifies the user. Traditionally it makes a beep (volume, duration, and frequency unspecified, settable on X Windows with 'xset b') but implementations vary - OSX Terminal plays the system warning sound, while my Zipit Z2 frenetically blinks an LED.

Of course you can also configure all the alphanumeric characters by changing your terminal font. I'm only half joking - it's not supposed to be important what the letters look like, only what they mean. ASCII art is not guaranteed to look good, whether or not it uses tabs.

Not to mention monospace vs proportional fonts.

Cool example on BEL.

If it's so remarkable that you were reminded why you prefer spaces over tabs, presumably since the thing you're doing doesn't happen very often, maybe you shouldn't prefer spaces over tabs.

I edit code in an editor way, way more often than look at it on GitHub. Every day when I edit code indented with spaces and my various editors don't correctly handle every edge-case for backspacing, de-denting, etc. I am reminded why I prefer tabs over spaces. It's such a common event for me that I probably wouldn't remark on it without some prompting.

Except in a few cases that code is pretty well formatted I would say.

Anyway this is game engine code and very old. I doubt you would find perfect formatting if it were spaces either.

Or just have your tabs converted to equivalent spaces.

But then anyone else who doesn't also use that same number of spaces is SOL. With tabs, each user can set the display to whatever they want.