News for hackers. Stuff that matters.
Re:Tabs, spaces and your salary – how is it really? by btilly on Tuesday June 20, 2017 @11:52AM (#14595564)
Tabs users frequently claim that.

But when I start running diff, less, and so on, I'm left with the conclusion that every tool has to be configured in a separate way for every user, in every environment. And this makes their code a PITA to deal with.

I'm generally not the one to complain. And I'll still use tabs if that is the standard for the code base that I'm working with. But tabs are strictly worse, and your flippant answer won't particularly please people that you need to collaborate with.

Re:Tabs, spaces and your salary – how is it really? by spinlock on Tuesday June 20, 2017 @12:41PM (#14596101)
This is how I feel about it too. Tab users seem to be saying that, with their configuration of vs-code, tabs work fine. I like a format that works fine with cat, sed, grep, and all of the other unix utilities in my githooks.

plus, I can run vim on a terminal on my phone. vs-code isn't there yet.

Re:Tabs, spaces and your salary – how is it really? by jimmaswell on Tuesday June 20, 2017 @12:48PM (#14596179)
Exactly what problems are you having with grep/git and tabs? Grep has \s to match any whitespace character and git has settings to ignore whitespace.
Re:Tabs, spaces and your salary – how is it really? by btilly on Tuesday June 20, 2017 @01:39PM (#14596679)
The default display for every tool is 8 spaces for a tabstop. If you don't want that, then each tool has to be configured separately, with a different method for each. Many require a command line option (which one differs by tool) that has to be typed in each time.

Yes, you may not notice or care. But if you're told about why other people don't like it, and dismiss them with flippant answers, you're going to make those other people unhappy.

Remember that the key to successful collaboration is to be strict in what you emit, and generous in what you receive. No matter how unreasonable you think the other is, in this case you're failing as well.

Re:Tabs, spaces and your salary – how is it really? by Sean1708 on Wednesday June 21, 2017 @07:51AM (#14602856)
I don't see the difference between that and having to preprocess every command you run to change the number of spaces used per indentation level (a much harder task).
Re:Tabs, spaces and your salary – how is it really? by btilly on Wednesday June 21, 2017 @10:41AM (#14604173)
Why would you need to change the number of spaces to read it? You probably have a different preference and what you get, but your preference is unlikely to be material to legibility.

Most people have settled with somewhere between 2-4 spaces, and a max of 80-120 character lines. I have an opinion on what I prefer in that range, but I'll live with a variety of stuff. And most others can as well.

Re:Tabs, spaces and your salary – how is it really? by Sean1708 on Wednesday June 21, 2017 @12:34PM (#14605302)
> Why would you need to change the number of spaces to read it?

Yes, why? You were the one that said:

> If you don't want that, then each tool has to be configured separately, with a different method for each.

Re:Tabs, spaces and your salary – how is it really? by btilly on Wednesday June 21, 2017 @01:37PM (#14606049)
There are two reasons for that.

First of all how deeply you go when you align text isn't particularly important. But actually aligning it is super important for it to be readable. It is therefore hard to read a mix of tabs and spaces with the tabstop set wrong.

Secondly while how deep isn't as important, research has found that comprehension drops outside of the range from 2-4 spaces. Therefore the 8 space default that every tool uses for tabs is suboptimal even if you consistently only have tabs everywhere.

The fact that many tools across many environments with many users all have to get it right, and the standard default is bad, makes tabs worse for collaboration.

Re:Tabs, spaces and your salary – how is it really? by runarberg on Tuesday June 20, 2017 @04:04PM (#14598073)
Especially diff. The single thing that annoys me with tabs is the fill behavior. The tab stop is not affected by the leading ‘+’ or ‘-’ in the start of the line which can lead to some weird looking code like :

     function foo() {
    -   if (baz) {
    +   if (bar) {
            baz();
        }
     }
If a tool is not set up to deal with this problem (for example `git config core.pager less -S -x1,5` for a 4 space tab stop, `less -S -x4` makes the first second line above indent with 3 not 4 spaces).

This is also a problem if a line is merged to the line above and an unaware developer leaves a tab character—previously used as indentation—thinking it is a space character. To the developer with the tab-stop set to four there is a one in a four chance they look identical.

Re:Tabs, spaces and your salary – how is it really? by jimmaswell on Tuesday June 20, 2017 @12:46PM (#14596156)
The indentation style was like that before I got there in each case. One just uses the Visual Studio default settings, the other is default Visual Studio settings but with tabs. I've never run into an issue with diffs or anything like that.