7 ms·

Ok, help me understand this. I’m on #TeamTab which puts me at odds with most coding standards. I usually work solo, so I don’t care, but every time I do let som

Ok, help me understand this. I’m on #TeamTab which puts me at odds with most coding standards. I usually work solo, so I don’t care, but every time I do let someone else edit a file, the commit shows every line has changed because their editor converts my indents. Are you saying there’s a tool that will let me work with (superior) tabs but have standards compliant commits? I’ve tried doing this in my .gitconfig with limited success. It didn’t work consistently.

sneak 8y ago
Tabs are an editor feature, and their use in your editor is somewhat unrelated to the way your editor serializes them onto disk. There are configurations for your editor that will allow this, independent of the EditorConfig project.
- RussianCow 8y ago
  This isn't true, because lining things up visually works differently with tabs than with spaces. (Although, personally, this is why I never visually align code like that, but that's the standard style in many organizations/languages.)
  - tobr 8y ago
    I will never understand why people get so religious about tabs vs spaces, but this is a hill I’m willing to die on: please don’t line things up visually in your source code, beyond standard indentation.
    - int_19h 8y ago
      There are some popular coding standards that essentially require it, unfortunately. My opinion on this is that it's a bad idea in the age where we (finally) have near universal acceptance of source control, because they bloat commits with irrelevant changes in surrounding lines to preserve alignment when identifiers change. Black got it exactly right - optimize for readability and change locality.
    - thecatspaw 8y ago
      why are you against it?
      - tobr 8y ago
        It’s brittle and fiddly, and it’s basically the only way to make it impossible to use proportional fonts, which are much more important for readability. If you feel like it’s useful, you should probably be using an editor with real elastic tabstops instead.
        deleted 8y ago
        [deleted]
        andrewprock 8y ago
        "It’s brittle and fiddly" You picked the wrong vocation my friend. It's "brittle and fiddly" all the way down.
        masukomi 8y ago
        the fact that most editors use mono-space fonts by default and hardly anyone is clamoring for the ability to use proprotional fonts seems to argue against them being particularly important to readability, at least as far as the community seems to be concerned. re "you should probably be using an editor with real elastic tabstops" ... i don't get what you're trying to say. What does real or fake elastic tabstops have to do with the choice to align code beyond just indentation?
        tobr 8y ago
        Manual alignment is often used as a poor man’s elastic tabstops. I think there’s a chicken-and-egg situation with monospaced type and programming. Programming was a thing before digital proportional typefaces were a thing, so some people came to rely on the fixed spacing to treat their source code as a 2d grid rather than a 1d buffer. This in turn made it more difficult to switch over to proportional typefaces despite their advantages, and at some point code == monospaced was just taken for granted. Another issue that comes from mistaking your code for a 2d mosaic is the dogma of dictating a maximum number of characters per line, instead of the more reasonable approach of using whatever expresses the structure of the program most clearly, and relying on line wrapping to make sure it’s all visible. FWIW I use proportional fonts, and 95% of the time it’s completely unproblematic. Fortunately I rarely work with code that uses manual alignment. It’s usually the occasional ASCII diagram that forces me to temporarily switch over to fixed pitch.
    - deleted 8y ago
      [deleted]
    - masukomi 8y ago
      > but this is a hill I’m willing to die on: please don’t line things up visually in your source code, beyond standard indentation. what's the argument against this? There are many arguments for how it can improve readability and speed up understanding of what you're looking at when you're not familiar with it.
- andrewprock 8y ago
  It may be an editor feature, but it's a UX anti-feature. If you are in a system small enough that you only ever have to look at code in a code editor, then this anti-feature won't be a real problem. If you work in a sufficiently complex environment that displays code across a variety of platforms, tabs will only make working with the code more difficult.
  - IshKebab 8y ago
    Not really. Most interfaces let you select the tab size or use some sensible default (e.g. 4). If you are using tabs properly it doesn't matter what display size they have. One odd exception is GitHub which inexplicably uses size-8 tabs by default which is way too big. I can only assume that somebody there is a space zealot and wants to screw up the UX for enlightened tab users.
    - andrewprock 8y ago
      Yes really. When I have to work on N platforms that are constantly shifting, I don't want to spend the overhead and mental effort to reconfigure the ones that can be reconfigured, and eat nameless dread on the ones that can't. When you view code across dozens of platforms, across dozens of machines, your perspective on "high maintenance config" everywhere changes a bit. If you can't be effective with default configs, you lose efficiency to config maintenance. Really, the last thing I want to deal with while I'm triaging some critical issue is dependency management for N code viewers.
    - dbrgn 8y ago
      Take a look at a picture of a mechanical typewriter: http://blog.gngcreative.com/wp-content/uploads/2015/02/mi0fg2Q.jpg http://blog.gngcreative.com/wp-content/uploads/2015/02/mi0fg... Those metal things you can see there, those are tabstops. They are called tabstops because when you press the tab key, the carriage mechanically stops at the tabstop. Tabstops were placed every 8 characters. A tabstop is simply a way to "type" 8 spaces with one keypress. Github is not the only page that uses 8 spaces for a tab, and it's definitely not inexplicable. The Unix/Linux terminal uses 8 spaces by default if you insert a tab. Vim uses 8 spaces by default if you insert a tab. Python considers a tab to be equivalent to 8 spaces. I'm sure there are a lot of other systems that default to this value. If you want to control how an indentation looks, use spaces. If you want tabs because the size is configurable and can be adjusted to one's preferences, you can't at the same time complain about "unreasonable configurations" that others use :)
dharmab 8y ago
See `go fmt` for Go and Black for Python for examples to try out.
- jen20 8y ago
  gofmt uses tabs too ;-)
eibrahim 8y ago
This should help. Stick and en editorconfig file in the root of your project and tell it to use tabs and if all developers are using a supported editor then their (superior) spaces would be converted to the (inferior) tabs lol
- leeoniya 8y ago
  on the other hand, i appreciate being able to comment out lines by typing `//` and not having my indentation f'd up. i also like to be able to un-indent stuff using backspace rather than shift-tab. also, using tabs at 4-spaces allows me to more easily detect misalignment since deleting one 4-space tab is obvious, while deleting a single space is not. while i know EOL line comments are not everyone's cup of tea, good luck getting good alignment (or changing alignment) on those with spaces. i say tabs are superior. the real solution is probably variable width tabstops: http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
  - setr 8y ago
    My experience with spaces is usually editors treating 4 spaces as a tab when backspacing. The rare need for a real single unit backspace has to be made up for with 3 additional spaces.
    - IshKebab 8y ago
      The trouble is most editors do this half-assed, for example you can select half of a "tab" if you use spaces, which makes no sense and lets you screw up the indentation easier. The only editor that really does properly support "just set this option and then it's like you are using tabs" is Atom. But I don't really want to use Atom.
  - yoodenvranx 8y ago
    > also, using tabs at 4-spaces allows me to more easily detect misalignment since If you use an autoformatter there is no need to manually check for misalignement! Just type in some code, press a key and everything is aligned, problem solved!
chrisweekly 8y ago
The real-world choice is not (tabs) || (spaces), it's (tabs && spaces) || (spaces). Which is why spaces is the objectively superior choice.
- int_19h 8y ago
  It depends on the exact formatting used. Many popular schemes only require tabs at the beginning of the line, and are not dependent on tab size.
- u801e 8y ago
  Using hanging indents for line continuations solves this issue by making the choice of using tabs or spaces a non-issue.
- mruts 8y ago
  Tabs allow each developer to choose his level of indentation. I think personal choice and flexibility to always be the objectively superior choice.
- RussianCow 8y ago
  That's not true if your code style doesn't allow visually lining things up. Then tabs will only ever act as standard indentation, and so tabs vs spaces doesn't actually matter aside from enforcing line length.
- seabird 8y ago
  In any project I've worked on that has used tabs for indentation, I've found no need to combine tabs and spaces. I've never been anywhere that enforces neurotic alignment standards, and if such guidelines aren't part of your workflow, I don't know why anyone would consciously inflict spaces upon themselves or their team. Some editors handle them like shit, and formatting fuckups always find their way in unless you're using an autoformatter. The only arguments I hear for spaces are alignment (I don't have time to give a shit about such minor aesthetic preferences) and forcing other people to see code a certain way (I really don't understand why I would want to force my editing preferences on others). I don't think either one of them justifies the annoyance of spaces.
andrewfong 8y ago
Do git commit hooks work for you? You and your collaborators can do whatever. The hook ensures things are converted to either tabs or spaces prior to commit. You can also set up a CI job to auto-reject any PRs that aren't tab/space compliant. This is all pretty pretty straightforward to configure on a per-repo basis too, so you can hop around multiple projects with different standards and not have to think too much about this.
yoodenvranx 8y ago
The thing with ideal auto-formatters is that there is no discussion about tabs vs spaces anymore! In a perfect world each language has exactly one (non-configurable) formatter and this solves all the formatting discussions. For JS I use prettier and altough I am not 100% happy with some of the formatting choices I _love_ it because I can focus on code and not have flamewars about tabs vs spaces with my co-workers. prettier ends all style discussions. And code reviews are much nicer because people concentrate on checking the code, not the formatting.
- baddox 8y ago
  I think the perfect world would have any number of formatters, but with ubiquitous tooling that allows each person to see code in their preferred format.
  - rix1 8y ago
    This sounds horrible for collaboration and pair programming tho.
alangpierce 8y ago
For an open source project, I'd recommend using an autoformatter, documenting it in the contributing guide, and enforcing it in CI so that anyone submitting a PR can clearly see if they submit something that breaks the formatting rules. I am much happier contributing to projects like these rather than trying to figure out all of the nuances of the author's preferred formatting style. Working with autoformatters for the last year or two has made me care much less about things like tabs vs spaces, I just care that the tooling is set up so that I don't need to think about it. As a concrete example (for JS projects), you could configure Prettier to use tabs for indentation: https://prettier.io/docs/en/options.html#tabs https://prettier.io/docs/en/options.html#tabs Then you could use eslint-plugin-prettier, which fails lint if the code isn't Prettier-formatted and makes ESLint autofix also run Prettier: https://github.com/prettier/eslint-plugin-prettier https://github.com/prettier/eslint-plugin-prettier Then set up lint to run in CI alongside tests.
Swizec 8y ago
> Are you saying there’s a tool that will let me work with (superior) tabs but have standards compliant commits? Yes. It's an autoformatter and it will make you never care again about tabs and spaces and other unimportant issues us devs love to bicker about. Focus on the higher level stuff instead :)

sneak 8y ago

Tabs are an editor feature, and their use in your editor is somewhat unrelated to the way your editor serializes them onto disk. There are configurations for your editor that will allow this, independent of the EditorConfig project.

RussianCow 8y ago
This isn't true, because lining things up visually works differently with tabs than with spaces. (Although, personally, this is why I never visually align code like that, but that's the standard style in many organizations/languages.)
- tobr 8y ago
  I will never understand why people get so religious about tabs vs spaces, but this is a hill I’m willing to die on: please don’t line things up visually in your source code, beyond standard indentation.
  - int_19h 8y ago
    There are some popular coding standards that essentially require it, unfortunately. My opinion on this is that it's a bad idea in the age where we (finally) have near universal acceptance of source control, because they bloat commits with irrelevant changes in surrounding lines to preserve alignment when identifiers change. Black got it exactly right - optimize for readability and change locality.
  - thecatspaw 8y ago
    why are you against it?
    - tobr 8y ago
      It’s brittle and fiddly, and it’s basically the only way to make it impossible to use proportional fonts, which are much more important for readability. If you feel like it’s useful, you should probably be using an editor with real elastic tabstops instead.
      - deleted 8y ago
        [deleted]
      - andrewprock 8y ago
        "It’s brittle and fiddly" You picked the wrong vocation my friend. It's "brittle and fiddly" all the way down.
      - masukomi 8y ago
        the fact that most editors use mono-space fonts by default and hardly anyone is clamoring for the ability to use proprotional fonts seems to argue against them being particularly important to readability, at least as far as the community seems to be concerned. re "you should probably be using an editor with real elastic tabstops" ... i don't get what you're trying to say. What does real or fake elastic tabstops have to do with the choice to align code beyond just indentation?
        tobr 8y ago
        Manual alignment is often used as a poor man’s elastic tabstops. I think there’s a chicken-and-egg situation with monospaced type and programming. Programming was a thing before digital proportional typefaces were a thing, so some people came to rely on the fixed spacing to treat their source code as a 2d grid rather than a 1d buffer. This in turn made it more difficult to switch over to proportional typefaces despite their advantages, and at some point code == monospaced was just taken for granted. Another issue that comes from mistaking your code for a 2d mosaic is the dogma of dictating a maximum number of characters per line, instead of the more reasonable approach of using whatever expresses the structure of the program most clearly, and relying on line wrapping to make sure it’s all visible. FWIW I use proportional fonts, and 95% of the time it’s completely unproblematic. Fortunately I rarely work with code that uses manual alignment. It’s usually the occasional ASCII diagram that forces me to temporarily switch over to fixed pitch.
  - deleted 8y ago
    [deleted]
  - masukomi 8y ago
    > but this is a hill I’m willing to die on: please don’t line things up visually in your source code, beyond standard indentation. what's the argument against this? There are many arguments for how it can improve readability and speed up understanding of what you're looking at when you're not familiar with it.
andrewprock 8y ago
It may be an editor feature, but it's a UX anti-feature. If you are in a system small enough that you only ever have to look at code in a code editor, then this anti-feature won't be a real problem. If you work in a sufficiently complex environment that displays code across a variety of platforms, tabs will only make working with the code more difficult.
- IshKebab 8y ago
  Not really. Most interfaces let you select the tab size or use some sensible default (e.g. 4). If you are using tabs properly it doesn't matter what display size they have. One odd exception is GitHub which inexplicably uses size-8 tabs by default which is way too big. I can only assume that somebody there is a space zealot and wants to screw up the UX for enlightened tab users.
  - andrewprock 8y ago
    Yes really. When I have to work on N platforms that are constantly shifting, I don't want to spend the overhead and mental effort to reconfigure the ones that can be reconfigured, and eat nameless dread on the ones that can't. When you view code across dozens of platforms, across dozens of machines, your perspective on "high maintenance config" everywhere changes a bit. If you can't be effective with default configs, you lose efficiency to config maintenance. Really, the last thing I want to deal with while I'm triaging some critical issue is dependency management for N code viewers.
  - dbrgn 8y ago
    Take a look at a picture of a mechanical typewriter: http://blog.gngcreative.com/wp-content/uploads/2015/02/mi0fg2Q.jpg http://blog.gngcreative.com/wp-content/uploads/2015/02/mi0fg... Those metal things you can see there, those are tabstops. They are called tabstops because when you press the tab key, the carriage mechanically stops at the tabstop. Tabstops were placed every 8 characters. A tabstop is simply a way to "type" 8 spaces with one keypress. Github is not the only page that uses 8 spaces for a tab, and it's definitely not inexplicable. The Unix/Linux terminal uses 8 spaces by default if you insert a tab. Vim uses 8 spaces by default if you insert a tab. Python considers a tab to be equivalent to 8 spaces. I'm sure there are a lot of other systems that default to this value. If you want to control how an indentation looks, use spaces. If you want tabs because the size is configurable and can be adjusted to one's preferences, you can't at the same time complain about "unreasonable configurations" that others use :)

dharmab 8y ago

See `go fmt` for Go and Black for Python for examples to try out.

jen20 8y ago
gofmt uses tabs too ;-)

eibrahim 8y ago

This should help. Stick and en editorconfig file in the root of your project and tell it to use tabs and if all developers are using a supported editor then their (superior) spaces would be converted to the (inferior) tabs lol

leeoniya 8y ago
on the other hand, i appreciate being able to comment out lines by typing `//` and not having my indentation f'd up. i also like to be able to un-indent stuff using backspace rather than shift-tab. also, using tabs at 4-spaces allows me to more easily detect misalignment since deleting one 4-space tab is obvious, while deleting a single space is not. while i know EOL line comments are not everyone's cup of tea, good luck getting good alignment (or changing alignment) on those with spaces. i say tabs are superior. the real solution is probably variable width tabstops: http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
- setr 8y ago
  My experience with spaces is usually editors treating 4 spaces as a tab when backspacing. The rare need for a real single unit backspace has to be made up for with 3 additional spaces.
  - IshKebab 8y ago
    The trouble is most editors do this half-assed, for example you can select half of a "tab" if you use spaces, which makes no sense and lets you screw up the indentation easier. The only editor that really does properly support "just set this option and then it's like you are using tabs" is Atom. But I don't really want to use Atom.
- yoodenvranx 8y ago
  > also, using tabs at 4-spaces allows me to more easily detect misalignment since If you use an autoformatter there is no need to manually check for misalignement! Just type in some code, press a key and everything is aligned, problem solved!

chrisweekly 8y ago

The real-world choice is not (tabs) || (spaces), it's (tabs && spaces) || (spaces). Which is why spaces is the objectively superior choice.

int_19h 8y ago
It depends on the exact formatting used. Many popular schemes only require tabs at the beginning of the line, and are not dependent on tab size.
u801e 8y ago
Using hanging indents for line continuations solves this issue by making the choice of using tabs or spaces a non-issue.
mruts 8y ago
Tabs allow each developer to choose his level of indentation. I think personal choice and flexibility to always be the objectively superior choice.
RussianCow 8y ago
That's not true if your code style doesn't allow visually lining things up. Then tabs will only ever act as standard indentation, and so tabs vs spaces doesn't actually matter aside from enforcing line length.
seabird 8y ago
In any project I've worked on that has used tabs for indentation, I've found no need to combine tabs and spaces. I've never been anywhere that enforces neurotic alignment standards, and if such guidelines aren't part of your workflow, I don't know why anyone would consciously inflict spaces upon themselves or their team. Some editors handle them like shit, and formatting fuckups always find their way in unless you're using an autoformatter. The only arguments I hear for spaces are alignment (I don't have time to give a shit about such minor aesthetic preferences) and forcing other people to see code a certain way (I really don't understand why I would want to force my editing preferences on others). I don't think either one of them justifies the annoyance of spaces.

andrewfong 8y ago

Do git commit hooks work for you? You and your collaborators can do whatever. The hook ensures things are converted to either tabs or spaces prior to commit. You can also set up a CI job to auto-reject any PRs that aren't tab/space compliant. This is all pretty pretty straightforward to configure on a per-repo basis too, so you can hop around multiple projects with different standards and not have to think too much about this.

yoodenvranx 8y ago

The thing with ideal auto-formatters is that there is no discussion about tabs vs spaces anymore! In a perfect world each language has exactly one (non-configurable) formatter and this solves all the formatting discussions. For JS I use prettier and altough I am not 100% happy with some of the formatting choices I _love_ it because I can focus on code and not have flamewars about tabs vs spaces with my co-workers. prettier ends all style discussions. And code reviews are much nicer because people concentrate on checking the code, not the formatting.

baddox 8y ago
I think the perfect world would have any number of formatters, but with ubiquitous tooling that allows each person to see code in their preferred format.
- rix1 8y ago
  This sounds horrible for collaboration and pair programming tho.

alangpierce 8y ago

For an open source project, I'd recommend using an autoformatter, documenting it in the contributing guide, and enforcing it in CI so that anyone submitting a PR can clearly see if they submit something that breaks the formatting rules. I am much happier contributing to projects like these rather than trying to figure out all of the nuances of the author's preferred formatting style. Working with autoformatters for the last year or two has made me care much less about things like tabs vs spaces, I just care that the tooling is set up so that I don't need to think about it. As a concrete example (for JS projects), you could configure Prettier to use tabs for indentation: https://prettier.io/docs/en/options.html#tabs https://prettier.io/docs/en/options.html#tabs Then you could use eslint-plugin-prettier, which fails lint if the code isn't Prettier-formatted and makes ESLint autofix also run Prettier: https://github.com/prettier/eslint-plugin-prettier https://github.com/prettier/eslint-plugin-prettier Then set up lint to run in CI alongside tests.

Swizec 8y ago

> Are you saying there’s a tool that will let me work with (superior) tabs but have standards compliant commits? Yes. It's an autoformatter and it will make you never care again about tabs and spaces and other unimportant issues us devs love to bicker about. Focus on the higher level stuff instead :)