7 ms·

People love to hate tabs, but in a world where we represent logic in megabytes of alpha-numeric characters, doesn't a semantic notation of indentation make just

People love to hate tabs, but in a world where we represent logic in megabytes of alpha-numeric characters, doesn't a semantic notation of indentation make just a little bit of sense? Tabs are for indentation, spaces for alignment. These are different concepts, but spacers[1] just think whitespace is whitespace are forever double tapping their spacebar like some sick mental tick that can't be cured. Your editor should not need to detect tab size. You should be able to size your tabs however you want. A tab is an indentation, weather you want it to be 2 chars or 20. It shouldn't matter. The fact that a neural network is being used to detect tab size, just shows how much ground tabbers have lost to the space infidels[2]. [1] http://www.jwz.org/doc/tabs-vs-spaces.html http://www.jwz.org/doc/tabs-vs-spaces.html [2] http://blog.codinghorror.com/death-to-the-space-infidels/ http://blog.codinghorror.com/death-to-the-space-infidels/

greydius 11y ago
We use the word "the" a lot in English. It would make sense to just replace it with a single character. But joking aside, I think the point is that the spacers (a lot of them, at least) don't want a semantic space that people can adjust; they want the code to look exactly the same for everyone. I'm reminded of Frank Lloyd Wright, who would design every aspect of a building, even the furniture.
- lifthrasiir 11y ago
  > We use the word "the" a lot in English. It would make sense to just replace it with a single character. Indeed the Shavian alphabet [1] has a single character abbreviation for "the" (should have been a th-e digraph). Of course, the same goes to the failure of Shavian and other reforms. [1] https://en.wikipedia.org/wiki/Shavian_alphabet https://en.wikipedia.org/wiki/Shavian_alphabet
- lanna 11y ago
  In Portuguese, "the" is "o" (masculine) or "a" (feminine). "and" is "e". Pretty simple, eh? Before you ask, no, "i" and "u" have no meaning :-)
- kazinator 11y ago
  The spacers are right. Even if you use tabs, there is a correct tab size that must be used, due to inner alignment: if (foo) { /* aligned blah(); comment */ My autotab.c relies on this as one of its heuristics to determine the proper hard tab size for a file. A tab size that produces good inner alignment gets a score boost. The wrong tab size will wreck inner alignment. http://www.kylheku.com/cgit/c-snippets/tree/autotab.c http://www.kylheku.com/cgit/c-snippets/tree/autotab.c
alextgordon 11y ago
You shouldn't use tabs for new projects, because spaces are more popular. It's like endianness: it doesn't matter which you use, as long as it's the same as everybody else. Right now, "everybody else" is using spaces. So get onboard.
- dradtke 11y ago
  New projects should standardize on whether they want tabs or spaces out of the gate, preferably enforced by something like editorconfig, and make that decision based on the preferences of the actual people involved at the time.
- deleted 11y ago
  [deleted]
- prodigal_erik 11y ago
  Big-endian and little-endian convey exactly the same information. Tabs and spaces don't; tabs impose fewer requirements on presentation and discourage people from wasting effort on fragile ASCII art that mostly just causes spurious merge conflicts.
Redoubts 11y ago
> forever double tapping their spacebar ??? I don't know anyone who does this.
- jessaustin 11y ago
  People who develop in notepad, presumably. b^)
kazinator 11y ago
> Tabs are for indentation, spaces for alignment. Tabs for indentation will wreck the alignment produced by spaces, unless the tab size is set to the size used by the file's author. Alignment is only preserved for those lines which have the same number of tabs for indentation. Alignment of inner material across lines that are indented to different levels is screwed up. The whole concept of every coder using his or her favorite tab size for the same file is completely, utterly moronic. If the coding convention calls for hard tabs, it must firmly establish their size and everyone must use that size. Ironically, tabs are for alignment historically, on typewriters, and also in word processors! In a word processor, you don't produce alignment with spaces unless you're a slobbering moron, because the font is proportionally sized. You set up tabs by sliding little wedgies on a ruler. Those things are inspired by hardware tabs on a typewriter. The word tab is related to tabular and tabulate: producing vertically aligned columns. So you have that backwards. Programmers who use hard tabs for indentation also use them for inner alignment, like this: if (foo) /* comment */ bar(); /* comment */ ^ this is a hard tab stop if foo is changed to xy_foo, comment will probably stay aligned with the one below. Of course, if too much material is added, then the comment will suddenly jump by 8 characters, and a tab has to be deleted, which restores the alignment. When files use this kind of alignment, they are slightly more resilient in the face of a tab size change. Some of the alignments stay the same; some others jump by a full tab size and have to be fixed. > forever double tapping their spacebar That's just due to using a crappy editor, or not knowing how to use a decent one. In Vim, Ctrl-T is used to indent by the shiftwidth amount (when this isn't automatic). This produces an indentation with tabs, spaces or a combination of both, based on whether hardtab or not is enabled, and the value of tabstop. Ctrl-D deindents. For instance, if you have tabstop=8, shiftwidth=4, noexpandtab, and you are currently indented two widths (one hard tab) and type Ctrl-D to deindent, the tab is replaced by four spaces.
- Stratoscope 11y ago
  > The whole concept of every coder using his or her favorite tab size for the same file is completely, utterly moronic. > If the coding convention calls for hard tabs, it must firmly establish their size and everyone must use that size. Letting coders and readers of code choose their own tab size isn't moronic, and you don't need to firmly establish the tab size. That's only an issue if you use column alignment after the initial indent. Column alignment is not a requirement in any of the programming languages most of us work in. It's just a stylistic choice, and it causes many problems including the one you describe. If you stop using column alignment, it doesn't matter what tab size someone uses when they view or edit the code. It doesn't even matter if they use a proportional font! Take your example: if (foo) /* comment */ bar(); /* comment */ ^ this is a hard tab stop and rewrite it without alignment: // Plenty of room for a longer comment here if( foo ) bar(); Or if you really need a comment for each line: // Plenty of room for a longer comment here if( foo ) { // And room for a long comment here too bar(); } Either way, you're no longer dependent on the tab size, and not dependent on monospaced fonts either. The code is consistently formatted in any font, even if you set your tabs to display as something odd like five spaces: // Plenty of room for a longer comment here if( foo ) { // And room for a long comment here too bar(); } Here's a more detailed discussion of the problems that column alignment causes and the benefits of giving it up: https://news.ycombinator.com/item?id=10206860 https://news.ycombinator.com/item?id=10206860
fantasticsid 11y ago
Tabs are for making TABles. Spaces are for reserving spaces. It's that simple. I would use Excel if I want to make a table. I also wouldn't put tables in my source code normally.

greydius 11y ago

We use the word "the" a lot in English. It would make sense to just replace it with a single character. But joking aside, I think the point is that the spacers (a lot of them, at least) don't want a semantic space that people can adjust; they want the code to look exactly the same for everyone. I'm reminded of Frank Lloyd Wright, who would design every aspect of a building, even the furniture.

lifthrasiir 11y ago
> We use the word "the" a lot in English. It would make sense to just replace it with a single character. Indeed the Shavian alphabet [1] has a single character abbreviation for "the" (should have been a th-e digraph). Of course, the same goes to the failure of Shavian and other reforms. [1] https://en.wikipedia.org/wiki/Shavian_alphabet https://en.wikipedia.org/wiki/Shavian_alphabet
lanna 11y ago
In Portuguese, "the" is "o" (masculine) or "a" (feminine). "and" is "e". Pretty simple, eh? Before you ask, no, "i" and "u" have no meaning :-)
kazinator 11y ago
The spacers are right. Even if you use tabs, there is a correct tab size that must be used, due to inner alignment: if (foo) { /* aligned blah(); comment */ My autotab.c relies on this as one of its heuristics to determine the proper hard tab size for a file. A tab size that produces good inner alignment gets a score boost. The wrong tab size will wreck inner alignment. http://www.kylheku.com/cgit/c-snippets/tree/autotab.c http://www.kylheku.com/cgit/c-snippets/tree/autotab.c

alextgordon 11y ago

You shouldn't use tabs for new projects, because spaces are more popular. It's like endianness: it doesn't matter which you use, as long as it's the same as everybody else. Right now, "everybody else" is using spaces. So get onboard.

dradtke 11y ago
New projects should standardize on whether they want tabs or spaces out of the gate, preferably enforced by something like editorconfig, and make that decision based on the preferences of the actual people involved at the time.
deleted 11y ago
[deleted]
prodigal_erik 11y ago
Big-endian and little-endian convey exactly the same information. Tabs and spaces don't; tabs impose fewer requirements on presentation and discourage people from wasting effort on fragile ASCII art that mostly just causes spurious merge conflicts.

Redoubts 11y ago

> forever double tapping their spacebar ??? I don't know anyone who does this.

jessaustin 11y ago
People who develop in notepad, presumably. b^)

kazinator 11y ago

> Tabs are for indentation, spaces for alignment. Tabs for indentation will wreck the alignment produced by spaces, unless the tab size is set to the size used by the file's author. Alignment is only preserved for those lines which have the same number of tabs for indentation. Alignment of inner material across lines that are indented to different levels is screwed up. The whole concept of every coder using his or her favorite tab size for the same file is completely, utterly moronic. If the coding convention calls for hard tabs, it must firmly establish their size and everyone must use that size. Ironically, tabs are for alignment historically, on typewriters, and also in word processors! In a word processor, you don't produce alignment with spaces unless you're a slobbering moron, because the font is proportionally sized. You set up tabs by sliding little wedgies on a ruler. Those things are inspired by hardware tabs on a typewriter. The word tab is related to tabular and tabulate: producing vertically aligned columns. So you have that backwards. Programmers who use hard tabs for indentation also use them for inner alignment, like this: if (foo) /* comment */ bar(); /* comment */ ^ this is a hard tab stop if foo is changed to xy_foo, comment will probably stay aligned with the one below. Of course, if too much material is added, then the comment will suddenly jump by 8 characters, and a tab has to be deleted, which restores the alignment. When files use this kind of alignment, they are slightly more resilient in the face of a tab size change. Some of the alignments stay the same; some others jump by a full tab size and have to be fixed. > forever double tapping their spacebar That's just due to using a crappy editor, or not knowing how to use a decent one. In Vim, Ctrl-T is used to indent by the shiftwidth amount (when this isn't automatic). This produces an indentation with tabs, spaces or a combination of both, based on whether hardtab or not is enabled, and the value of tabstop. Ctrl-D deindents. For instance, if you have tabstop=8, shiftwidth=4, noexpandtab, and you are currently indented two widths (one hard tab) and type Ctrl-D to deindent, the tab is replaced by four spaces.

Stratoscope 11y ago
> The whole concept of every coder using his or her favorite tab size for the same file is completely, utterly moronic. > If the coding convention calls for hard tabs, it must firmly establish their size and everyone must use that size. Letting coders and readers of code choose their own tab size isn't moronic, and you don't need to firmly establish the tab size. That's only an issue if you use column alignment after the initial indent. Column alignment is not a requirement in any of the programming languages most of us work in. It's just a stylistic choice, and it causes many problems including the one you describe. If you stop using column alignment, it doesn't matter what tab size someone uses when they view or edit the code. It doesn't even matter if they use a proportional font! Take your example: if (foo) /* comment */ bar(); /* comment */ ^ this is a hard tab stop and rewrite it without alignment: // Plenty of room for a longer comment here if( foo ) bar(); Or if you really need a comment for each line: // Plenty of room for a longer comment here if( foo ) { // And room for a long comment here too bar(); } Either way, you're no longer dependent on the tab size, and not dependent on monospaced fonts either. The code is consistently formatted in any font, even if you set your tabs to display as something odd like five spaces: // Plenty of room for a longer comment here if( foo ) { // And room for a long comment here too bar(); } Here's a more detailed discussion of the problems that column alignment causes and the benefits of giving it up: https://news.ycombinator.com/item?id=10206860 https://news.ycombinator.com/item?id=10206860

fantasticsid 11y ago

Tabs are for making TABles. Spaces are for reserving spaces. It's that simple. I would use Excel if I want to make a table. I also wouldn't put tables in my source code normally.