7 ms·

> when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. This is an argument I hear ofte

by rlpb 9y ago

> when another developer looks at the code, their IDE will render the tabs as whatever its set up for, 2 spaces, 4 spaces, etc. This is an argument I hear often from tab proponents. What it misses out is the downside: my IDE has a certain arrangement on my screen, and I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me. This is far from flexible. There's also the (more minor) issue that you then can't line things up on a line below at an arbitrary place if the indentation of the two lines is to be different. This is admittedly less of an issue, but it does arise on the occasion one wants to structure text, for example in a table in a comment block. I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere. But I'm not writing this to get into a holy war; only to point out that the "it adds flexibility" in your argument is a fallacy.

jordanlev 9y ago
> if you are using different size tabs from me. But the point of tabs is that you tell your editor how many spaces wide you want them to be, so unless I'm misunderstanding you, this is not an issue. As for lining things up, tabs are used for the indentation level of the current line, but if you need to further nudge things within that line then you'd of course use spaces (after the initial tab indent).
- rlpb 9y ago
  You misunderstand me. I can set my tab size different from yours, but doing that will change the horizontal window width required to view your code. This is the problem I'm describing.
  - jordanlev 9y ago
    How is that problematic though? I'm not aware of any language or situation where the width of the window has any impact on anything.
- watwut 9y ago
  Someone who uses 8 spaces for tab will do less nesting them someone who users 2. Thay is how I read the above comment.
- adrianmonk 9y ago
  Assume you want to eliminate horizontal scrolling. This is a valuable enough goal that a lot of coding style guides have a width guideline. That keeps everybody from having to make their editor windows as wide as the last person who worked on the code. If this arrangement is working, nobody has to scroll horizontally, and there is no arms race of ever-wider editor windows. Now introduce tabs into this situation. In theory I can set tabs to be whatever size I like. But in practice, I can't make them wider than the last person who worked on the code, because then I'm back to horizontal scrolling. Moreover, if I make them narrower, then they have to narrow their tabs to keep pace. So you get an arms race of tab- narrowing instead of window widening. I just want to code. I don't want to scroll horizontally, or constantly mess with my window width and/or tab settings to avoid that. It's extra work that doesn't accomplish anything.
  - jordanlev 9y ago
    I am genuinely baffled (but I don't think I'm right and you're wrong... I trust HN people to be smart and capable). Can you please explain to me how using tabs vs spaces would encourage people to indent their code differently? I mean, if I have an "if" statement, then I indent my code -- but why would people indent their code for reasons other than what the flow of the code suggests? And if these hypothetical "indenting just because I can and not because I should" people exist, how would their inconsiderate behavior be any different whether they are using tabs or spaces?
    - adrianmonk 9y ago
      I'm not talking about using a different style. I'm saying that different tab widths lead to different requirements for how many columns wide my window must be.
bitwize 9y ago
> I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere. Ah, the old argumentum ad ubiquitam, which has saddled us with the x86 ISA, Unix kernels, and other brokenness we can never shake.
- rlpb 9y ago
  You're begging the question. There's nothing wrong with the principle of having a standard format, or the currently accepted standard format.
dTal 9y ago
> I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me. So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs. >I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running. Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...
- rlpb 9y ago
  > Also, what do you mean "works"? The world doesn't explode if > you view a file with a different tab size than it was created > with. Again, kind of the point... It does, as I demonstrate in my quote of you above. Try reading source code like that. The only sensible way of reading source code is by viewing it with at the same overall window width in which the author wrote it. Viewing at a different tab size destroys this. > Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running. Except that I need to figure out the most appropriate tab size to use on a per-file-author basis if "variable tabs" were used, so this doesn't work because I get the problem as described above.
- pyre 9y ago
  > So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs. I think that the point was that if your IDE displays tabs as 8 spaces, and you read code written by someone that sets their IDE to display tabs as 2 spaces, then the line lengths will display longer in your IDE. It "just works" when the writer has configured longer tabs than the reader, but not necessarily in the opposite direction. > Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point... One example: enforced line-length limits. If you are wrapping at 80 characters with tabs set to 2-spaces, you will display a longer than 80 characters when viewing with tabs set to 8-spaces.
pyre 9y ago
> Further, the only sensible screen width is 80 characters, since that also works everywhere. I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters? I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the earth if you let them. But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done." I realize that the 80-character limit is "everywhere"[1], but other than "it's everywhere" is there a more solid reason? [1] When editing text emails in Vim the default textwidth value is 72, so that there is still some flex for quoting explicitly wrapped text (i.e. prepending "> " to the lines) and staying within the 80-character limit. The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. etc...
- Karunamon 9y ago
  Further, given that you're dealing with a language that uses significant indentation, you end up having to use stupid tricks that make your code less readable to stay under the bar. Indented two levels (an 'if' block in a function in a class) and a couple of interpolated variables in an error message isn't unreasonable to have on a single line.
- sedachv 9y ago
  80 character line wrapping is IMO more important on larger and wider-aspect ratio screens. Even the smallest 16:9 aspect ratio screen can be split into two columns, one being an 80 character column for code and the other left wide for a web browser or document viewer (this is now my setup when working on 16:9 aspect ratio laptops). I see a lot of people work on large displays and with multi-monitor setups. Those who do not have their screens split into an 80-character or similar terminal and text editor width columns spend a lot of time switching between screens or applications. Couple this with the fact that you have to move your eyes around a lot on larger displays (and even head, in the case of multi-monitor set ups) and their setups actually make them navigate slower than they would on a smaller display.
- fasquoika 9y ago

by rlpb 9y ago

jordanlev 9y ago

> if you are using different size tabs from me. But the point of tabs is that you tell your editor how many spaces wide you want them to be, so unless I'm misunderstanding you, this is not an issue. As for lining things up, tabs are used for the indentation level of the current line, but if you need to further nudge things within that line then you'd of course use spaces (after the initial tab indent).

rlpb 9y ago
You misunderstand me. I can set my tab size different from yours, but doing that will change the horizontal window width required to view your code. This is the problem I'm describing.
- jordanlev 9y ago
  How is that problematic though? I'm not aware of any language or situation where the width of the window has any impact on anything.
watwut 9y ago
Someone who uses 8 spaces for tab will do less nesting them someone who users 2. Thay is how I read the above comment.
adrianmonk 9y ago
Assume you want to eliminate horizontal scrolling. This is a valuable enough goal that a lot of coding style guides have a width guideline. That keeps everybody from having to make their editor windows as wide as the last person who worked on the code. If this arrangement is working, nobody has to scroll horizontally, and there is no arms race of ever-wider editor windows. Now introduce tabs into this situation. In theory I can set tabs to be whatever size I like. But in practice, I can't make them wider than the last person who worked on the code, because then I'm back to horizontal scrolling. Moreover, if I make them narrower, then they have to narrow their tabs to keep pace. So you get an arms race of tab- narrowing instead of window widening. I just want to code. I don't want to scroll horizontally, or constantly mess with my window width and/or tab settings to avoid that. It's extra work that doesn't accomplish anything.
- jordanlev 9y ago
  I am genuinely baffled (but I don't think I'm right and you're wrong... I trust HN people to be smart and capable). Can you please explain to me how using tabs vs spaces would encourage people to indent their code differently? I mean, if I have an "if" statement, then I indent my code -- but why would people indent their code for reasons other than what the flow of the code suggests? And if these hypothetical "indenting just because I can and not because I should" people exist, how would their inconsiderate behavior be any different whether they are using tabs or spaces?
  - adrianmonk 9y ago
    I'm not talking about using a different style. I'm saying that different tab widths lead to different requirements for how many columns wide my window must be.

bitwize 9y ago

> I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Further, the only sensible screen width is 80 characters, since that also works everywhere. Ah, the old argumentum ad ubiquitam, which has saddled us with the x86 ISA, Unix kernels, and other brokenness we can never shake.

rlpb 9y ago
You're begging the question. There's nothing wrong with the principle of having a standard format, or the currently accepted standard format.

dTal 9y ago

> I'll either have to invoke horizontal scrolling or I'll have a bunch of wasted space if you are using different size tabs from me. So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs. >I've come to the conclusion that the only sensible tab width is 8, since that works everywhere including in tools where it isn't practical to set (eg. less). Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running. Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point...

rlpb 9y ago
> Also, what do you mean "works"? The world doesn't explode if > you view a file with a different tab size than it was created > with. Again, kind of the point... It does, as I demonstrate in my quote of you above. Try reading source code like that. The only sensible way of reading source code is by viewing it with at the same overall window width in which the author wrote it. Viewing at a different tab size destroys this. > Pass -x[size] to less or put it in the LESS environment variable to make it default. You can also type it in while less is running. Except that I need to figure out the most appropriate tab size to use on a per-file-author basis if "variable tabs" were used, so this doesn't work because I get the problem as described above.
pyre 9y ago
> So change your tab size? That's true if you have a different sized monitor, no matter what the tab size. That's... kind of the point of using tabs. I think that the point was that if your IDE displays tabs as 8 spaces, and you read code written by someone that sets their IDE to display tabs as 2 spaces, then the line lengths will display longer in your IDE. It "just works" when the writer has configured longer tabs than the reader, but not necessarily in the opposite direction. > Also, what do you mean "works"? The world doesn't explode if you view a file with a different tab size than it was created with. Again, kind of the point... One example: enforced line-length limits. If you are wrapping at 80 characters with tabs set to 2-spaces, you will display a longer than 80 characters when viewing with tabs set to 8-spaces.

pyre 9y ago

> Further, the only sensible screen width is 80 characters, since that also works everywhere. I'm curious. Where does 80 characters not work now? How many people / industries are still using green-screen terminals with a fixed-width of 80 characters? I'm generally in favour of enforcing line-wrapping requirements, because I've worked with people that would have a tendency to write code that trails off the end of the earth if you let them. But I haven't seen a good argument for 80-character line limit other than "that's the way it's always been done." I realize that the 80-character limit is "everywhere"[1], but other than "it's everywhere" is there a more solid reason? [1] When editing text emails in Vim the default textwidth value is 72, so that there is still some flex for quoting explicitly wrapped text (i.e. prepending "> " to the lines) and staying within the 80-character limit. The "official/accepted" git commit message format limits the commit message title to 50 characters, and the message body to ~80 characters. etc...

Karunamon 9y ago
Further, given that you're dealing with a language that uses significant indentation, you end up having to use stupid tricks that make your code less readable to stay under the bar. Indented two levels (an 'if' block in a function in a class) and a couple of interpolated variables in an error message isn't unreasonable to have on a single line.
sedachv 9y ago
80 character line wrapping is IMO more important on larger and wider-aspect ratio screens. Even the smallest 16:9 aspect ratio screen can be split into two columns, one being an 80 character column for code and the other left wide for a web browser or document viewer (this is now my setup when working on 16:9 aspect ratio laptops). I see a lot of people work on large displays and with multi-monitor setups. Those who do not have their screens split into an 80-character or similar terminal and text editor width columns spend a lot of time switching between screens or applications. Couple this with the fact that you have to move your eyes around a lot on larger displays (and even head, in the case of multi-monitor set ups) and their setups actually make them navigate slower than they would on a smaller display.
fasquoika 9y ago