Semantically: tabs are simply correct.
They encode actual meaning.
Rather than merely presentation.
They also win on accessibility, because someoen with visual difficulties can adjust their editor to display them as larger or smaller.
The counter to this is people using spaces for alignment,
Like if one wants to list arguements below the openning backet of a function call, and line up the closing bracket.
The counter counter is:
stop that.
Adopt a style guide that doesn't do alignment and sticks to a simple rule like "Always indent once while within a multiline expression"
Alignment is for art.
We don't have time for your subjective view of what makes code pretty.
Computers don't care about the alignment or the code looking pretty on screen, but code looking pretty on screen helps the human writers and readers alike.
I am sure you don't use syntax highlighting either, and that you only use short one-letter variable names.
A consistant alignment-free indenting only style is perfectly readably.
More reably than a lot of inconsitently applied and subjective alignment styles I often see.
Though I have also seen consistently applied non-subjective alignment based styles, that are also perfectly reably.
But no more reasable than a consistently applied indenting only style.
Alignment styles are in general more complex to describe and thus more inconsistently applied.
And sure some subjective alignment based styles are pretty are maybe even marginally more readable.
But does it scale?
Can the intern who is only here for summer weeks be expected to learn what makes it look nice in the teams opinion while also learning everything else?
How about that one coworker who just doesn't agree and refuses to conform to these subjective rules that can't even be written down.
Sure, you can have art if you want for your solo project.
But programming is a team sport.
Are you suggesting that it's hard to teach an intern how to consistently align code with spaces but not with tabs?
Or that people using tabs-only are in general more consistent in the other parts of code styling?
I _don't_ have any data to support either, but I strongly suspect it's completely unrelated to one another.
But I still disagree with your take on whether a team activity to achieve something of practical value can be or can contain art (and I am not thinking only about the presentation/appearance of code).
Agreed, and I used to be a "tabber". I'm not sure you can indent lisp using tabs though. For instance, indentation of "let" and "let*" differ by a single space I believe.
This is the real answer.
I personally like tabs.
But I will absolutely not stand for anyone using tabs on our code-base.
Because we use spaces, and we have better things to do that debate or, or reformat the whole code base.
(even though we actually do use a style without alignment and so it would be not at all a visual problem)
Personally, I use tabs for indentation, spaces for alignment.
But more practically, I think the right thing to do is use an opinionated formatter (like Go's gofmt or similar) and enforce that across the teams that you work with. Life's too short to bicker about tabs vs spaces, when there are more important things to discuss like short variables vs long variables ;)
In practice, I don't care, and I lol-ed at the religion comment below.
And I know tabs are seeing a comeback lately, but they are basically the only ASCII character that does not have a predefined width.
And the reason I dislike that is because they don't have clear semantics even in the pure text-only world: eg. writing out a table in ASCII is not possible with these "tabulating" characters, because if the column data is wider than (tab-width – 1), well, there goes your alignment. And when something is so badly defined not to serve the purpose it's named after, I can't like it. :)
If it was called the "indent" character which was ignored anywhere but at the start of the line, it would at least be sane and consistent.
Incidentally, Emacs can do the right thing in most modes by turning tab key into the (re)indent command.
Both. Tabs up to the current level of indentation. Then spaces after that for alignment. Spaces never come before a tab, only after and only for alignment purposes.
Everyone likes to take a dump on mixing tabs/spaces. But it solves all problems with both. Everyone can view the indentation width they prefer; 2, 3, 4, 8, whatever. And alignment is always correct no matter what width you prefer. An auto format tool can remove the need to manually deal with anything.
Indent width is a visual effect that should not be mandated. You wouldn't mandate a color scheme for your code base, so why would you mandate indentation width?
> Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.
The counter to this is people using spaces for alignment, Like if one wants to list arguements below the openning backet of a function call, and line up the closing bracket.
The counter counter is: stop that. Adopt a style guide that doesn't do alignment and sticks to a simple rule like "Always indent once while within a multiline expression" Alignment is for art. We don't have time for your subjective view of what makes code pretty.