5 ms·

I've never really understood why you would use several characters (=spaces) for something that is semantically one indent. Can someone enlighten me? What are th

I've never really understood why you would use several characters (=spaces) for something that is semantically one indent. Can someone enlighten me? What are the advantages of spaces over tabs?

67726e 10y ago
People always talk about consistent display of spaces whereas tabs might be shown as 4 spaces or even 8. Of course that means you can usually customize how tabs are rendered unless you code in Notepad or something crazy.
- doc_holliday 10y ago
  Lots of people need to access files on a server via Emacs or Vim. Having to deal with tabs there can be very frustrating.
  - oolongCat 10y ago
    On vim (I am sure as hell you can do this on Emacs) you can always define your tabs to be spaces and you can specify exactly how much. So this is really not a big problem.
  - 67726e 10y ago
    I'm not an Emacs guy but it's trivial to set the tab size on vim. I would be shocked if that were not also the case for emacs.
philipov 10y ago
def doSomething( parameter1 , parameter2 , parameter3 ): pass How would you make all the punctuation line up using tabs?
- chrismorgan 10y ago
  Rather (assuming you’re dealing with Python), def do_something(parameter_1, parameter_2, parameter_3): pass
- scrollaway 10y ago
  def do_something( param1, param2, param3, param4 ): ... It's not that hard. Alignment is generally harmful - it's a maintenance burden which adds whitespace noise on diffs, which means more noise in code reviews. Not to mention how atrociously ugly it is when long variables/method names lead to 5+ lines with 60+ characters of indent for a single variable name per line.
  - pyre 10y ago
    Most diff programs have an "ignore whitespace" option. "whitespace noise on diffs" is pretty much a solved problem. You can even add '?w=1' to a Github URL to turn on the feature.
    - scrollaway 10y ago
      1. That's a band-aid. The characters have still been changed - the diff still "exists". 2. Those options are not perfect, they don't always work as expected 3. Those options are not turned on by default (because that would be INSANE) 4. Git's not the only VCS, much as I wish it were 5. Github's not the only Git web UI; that option is not available everywhere. It's not a "solved problem". It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time.
      - pyre 10y ago
        > It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time. This is mostly solved via coding standards. If there are no coding standards people will "refactor" the coding style when they touch various pieces of code. If people were following a consistent style, then the alignment wouldn't be changing all of the time. Although I strongly agree with the trailing whitespace sentiment. The most egregious offender that I've found is Eclipse putting trailing spaces on blank lines to bring them to the indent level of the non-blank lines. Ugh.
        10y ago
- oneeyedpigeon 10y ago
  You don't, you use tabs for indentation and spaces for alignment.
  - jasonkostempski 10y ago
    Parent, you are the devil incarnate. Grandparent, you have bigger issues to resolve.
- dragonwriter 10y ago
  The longer I've been programming, the more I think that alignment is ideally a presentational feature that a syntax-aware editor should do, not something that should be reflected in the source. But then tabs vs. spaces isn't an issue.
pyre 10y ago
Not all editors are smart about tabs and spaces, and when the two start to mix things get really funky if everyone doesn't have the same "1 tab = x spaces" value set on their editor. For example: function_call(really_really_really_really_really_argument1, really_really_really_really_really_argument2) Say that this is supposed to be at one indent level. The beginning of both of those lines should contain only one tab, and the spacing that positions the second argument from the indent should be only spaces: <tab>function_call(really_really_really_really_really_argument1, <tab>SSSSSSSSSSSSSSreally_really_really_really_really_argument2) If the text looked like above (each 'S' is a space), then one's editor could easily change whether or not a <tab> was displayed as 8 spaces or as 4 spaces, and the display wouldn't be affected. Many editors, however, consider all spacing at the start of the line to be indentation. If you were using one of those editors with tabs set to (e.g.) 4 spaces, the code might look something like this: <tab>function_call(really_really_really_really_really_argument1, <tab><tab><tab><tab>SSreally_really_really_really_really_argument2) Now the code only looks the way it was meant to look if you have you <tab> = X spaces value set to 4. If you set it to something else, the code looks like a mess.
- adontz 10y ago
  Your point is valid, that's why I write function( really_really_really_really_really_long_argument1, really_really_really_really_really_long_argument2, really_really_really_really_really_long_argument3);
  - pyre 10y ago
    Right, not now you're dictating coding style to work around the warts associated with using tabs. If you use spaces there are no such issues because spaces don't change widths between editors.
    - adontz 10y ago
      To be honest, no, because my formatting will not be broken after refactoring changing function name length.
CJefferson 10y ago
The big advantage, as other people discuss, that that different editors display tabs as 2,4 or 8 spaces, and I've never worked on a codebase which used tabs, and where viewing the code in different tab sizes didn't break the layout somehow. If you use spaces, you can format code, knowing it will look right on other people's machines. Perhaps a sufficiently organised bunch of programmers could edit a large code base such that it viewed fine with 2,4 or 8 character tabs, but is it worth the pain?
GoToRO 10y ago
With spaces you can position the cursor anywhere you want, with tabs you can not position the cursor in the middle of a tab.
- mherrmann 10y ago
  Why would you want to do that? In fact, isn't it much more convenient to be able to jump over one tab with a single keystroke, rather than 2, 4 or 8?
  - GoToRO 10y ago
    If you use the mouse then you want the cursor to appear exactly where you clicked. It's just a UX problem, similar with clicking past the last line of a file, even if it's nothing there, the editor should append new lines until the place that you clicked becomes part of the file.
michaelt 10y ago
Things that are supposed to be lined up stay lined up even if they aren't at the start of a line - even if you: * Use different tools - IDE, command line, version control tool, code review tool, e-mail client. * Have code that follows with different conventions - because you participate in several projects, or because you've imported third party code that follows a different convention, or because the code is written in different languages. * Have co-workers with different opinions about what tab width should be set to. Personally I don't think there's that much value in vertically aligning things, except in lookup tables. Usually it's a sign you've adopted line-length rules that don't reflect modern monitor sizes, or that your methods have too many parameters. But some people seem to think it's valuable.
mbrock 10y ago
Semantically, the TAB character means something like "insert a pseudo-random number of spaces here" with that number often defaulting to some ridiculous value like 8. I keep my programs less than 80 character wide for accessibility purposes but if I use tabs then the width is unpredictable. Also, spaces are universal and trivial whereas the TAB button in many editors has strange behavior.

I've never really understood why you would use several characters (=spaces) for something that is semantically one indent. Can someone enlighten me? What are the advantages of spaces over tabs?

67726e 10y ago

People always talk about consistent display of spaces whereas tabs might be shown as 4 spaces or even 8. Of course that means you can usually customize how tabs are rendered unless you code in Notepad or something crazy.

doc_holliday 10y ago
Lots of people need to access files on a server via Emacs or Vim. Having to deal with tabs there can be very frustrating.
- oolongCat 10y ago
  On vim (I am sure as hell you can do this on Emacs) you can always define your tabs to be spaces and you can specify exactly how much. So this is really not a big problem.
- 67726e 10y ago
  I'm not an Emacs guy but it's trivial to set the tab size on vim. I would be shocked if that were not also the case for emacs.

philipov 10y ago

def doSomething( parameter1 , parameter2 , parameter3 ): pass How would you make all the punctuation line up using tabs?

chrismorgan 10y ago
Rather (assuming you’re dealing with Python), def do_something(parameter_1, parameter_2, parameter_3): pass
scrollaway 10y ago
def do_something( param1, param2, param3, param4 ): ... It's not that hard. Alignment is generally harmful - it's a maintenance burden which adds whitespace noise on diffs, which means more noise in code reviews. Not to mention how atrociously ugly it is when long variables/method names lead to 5+ lines with 60+ characters of indent for a single variable name per line.
- pyre 10y ago
  Most diff programs have an "ignore whitespace" option. "whitespace noise on diffs" is pretty much a solved problem. You can even add '?w=1' to a Github URL to turn on the feature.
  - scrollaway 10y ago
    1. That's a band-aid. The characters have still been changed - the diff still "exists". 2. Those options are not perfect, they don't always work as expected 3. Those options are not turned on by default (because that would be INSANE) 4. Git's not the only VCS, much as I wish it were 5. Github's not the only Git web UI; that option is not available everywhere. It's not a "solved problem". It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time.
    - pyre 10y ago
      > It's an artificial problem, that gets solved when you start consistently stripping trailing whitespaces on save and not realigning everything all the time. This is mostly solved via coding standards. If there are no coding standards people will "refactor" the coding style when they touch various pieces of code. If people were following a consistent style, then the alignment wouldn't be changing all of the time. Although I strongly agree with the trailing whitespace sentiment. The most egregious offender that I've found is Eclipse putting trailing spaces on blank lines to bring them to the indent level of the non-blank lines. Ugh.
      - 10y ago
oneeyedpigeon 10y ago
You don't, you use tabs for indentation and spaces for alignment.
- jasonkostempski 10y ago
  Parent, you are the devil incarnate. Grandparent, you have bigger issues to resolve.
dragonwriter 10y ago
The longer I've been programming, the more I think that alignment is ideally a presentational feature that a syntax-aware editor should do, not something that should be reflected in the source. But then tabs vs. spaces isn't an issue.

pyre 10y ago

Not all editors are smart about tabs and spaces, and when the two start to mix things get really funky if everyone doesn't have the same "1 tab = x spaces" value set on their editor. For example: function_call(really_really_really_really_really_argument1, really_really_really_really_really_argument2) Say that this is supposed to be at one indent level. The beginning of both of those lines should contain only one tab, and the spacing that positions the second argument from the indent should be only spaces: <tab>function_call(really_really_really_really_really_argument1, <tab>SSSSSSSSSSSSSSreally_really_really_really_really_argument2) If the text looked like above (each 'S' is a space), then one's editor could easily change whether or not a <tab> was displayed as 8 spaces or as 4 spaces, and the display wouldn't be affected. Many editors, however, consider all spacing at the start of the line to be indentation. If you were using one of those editors with tabs set to (e.g.) 4 spaces, the code might look something like this: <tab>function_call(really_really_really_really_really_argument1, <tab><tab><tab><tab>SSreally_really_really_really_really_argument2) Now the code only looks the way it was meant to look if you have you <tab> = X spaces value set to 4. If you set it to something else, the code looks like a mess.

adontz 10y ago
Your point is valid, that's why I write function( really_really_really_really_really_long_argument1, really_really_really_really_really_long_argument2, really_really_really_really_really_long_argument3);
- pyre 10y ago
  Right, not now you're dictating coding style to work around the warts associated with using tabs. If you use spaces there are no such issues because spaces don't change widths between editors.
  - adontz 10y ago
    To be honest, no, because my formatting will not be broken after refactoring changing function name length.

CJefferson 10y ago

The big advantage, as other people discuss, that that different editors display tabs as 2,4 or 8 spaces, and I've never worked on a codebase which used tabs, and where viewing the code in different tab sizes didn't break the layout somehow. If you use spaces, you can format code, knowing it will look right on other people's machines. Perhaps a sufficiently organised bunch of programmers could edit a large code base such that it viewed fine with 2,4 or 8 character tabs, but is it worth the pain?

GoToRO 10y ago

With spaces you can position the cursor anywhere you want, with tabs you can not position the cursor in the middle of a tab.

mherrmann 10y ago
Why would you want to do that? In fact, isn't it much more convenient to be able to jump over one tab with a single keystroke, rather than 2, 4 or 8?
- GoToRO 10y ago
  If you use the mouse then you want the cursor to appear exactly where you clicked. It's just a UX problem, similar with clicking past the last line of a file, even if it's nothing there, the editor should append new lines until the place that you clicked becomes part of the file.

michaelt 10y ago

Things that are supposed to be lined up stay lined up even if they aren't at the start of a line - even if you: * Use different tools - IDE, command line, version control tool, code review tool, e-mail client. * Have code that follows with different conventions - because you participate in several projects, or because you've imported third party code that follows a different convention, or because the code is written in different languages. * Have co-workers with different opinions about what tab width should be set to. Personally I don't think there's that much value in vertically aligning things, except in lookup tables. Usually it's a sign you've adopted line-length rules that don't reflect modern monitor sizes, or that your methods have too many parameters. But some people seem to think it's valuable.

mbrock 10y ago

Semantically, the TAB character means something like "insert a pseudo-random number of spaces here" with that number often defaulting to some ridiculous value like 8. I keep my programs less than 80 character wide for accessibility purposes but if I use tabs then the width is unpredictable. Also, spaces are universal and trivial whereas the TAB button in many editors has strange behavior.