Ask HN: Why do the majority of JS developers prefer spaces over tabs?
9 comments
Because spaces are rendered the same everywhere. Suppose I write this code, indenting using spaces.
im_a_long_method(argument_no_1,
set_indentation_true(...),
no_string_cutoff,
whatever)
im_a_long_method(argument_no_1,
set_indentation_true(...),
no_string_cutoff,
whatever)
> Because spaces are rendered the same everywhere. Suppose I write this code, indenting using spaces.
Then it'll look wrong in a proportional font; indenting and aligning with non-indented text are different things. Either spaces or tabs indent consistently when used consistently in a source file. Alignment cannot be acheived consistently (with spaces or tabs) unless you also assume a monospaced font, or (with tabs) have elastic tabstops.
Then it'll look wrong in a proportional font; indenting and aligning with non-indented text are different things. Either spaces or tabs indent consistently when used consistently in a source file. Alignment cannot be acheived consistently (with spaces or tabs) unless you also assume a monospaced font, or (with tabs) have elastic tabstops.
I really don't get the point of tabs for visual layout in any kind of document be it plain text, source code, or a word processor document. They never seemed to work right for me.
I remember using the tab key to enter tabs back in school to make something like an informal, 2-or3-column table (or whatever I was actually doing). This would have been in Word. Things would line up pretty until I wanted to change some text. If I made it longer I would need to add another tab because the tab had shrunk to nothing. If I made it shorter the tab would jump into the previous section and no longer line up with the other lines.
As far as I can see, the same will happen with this source example if it were using tabs and a proportional font.
I remember using the tab key to enter tabs back in school to make something like an informal, 2-or3-column table (or whatever I was actually doing). This would have been in Word. Things would line up pretty until I wanted to change some text. If I made it longer I would need to add another tab because the tab had shrunk to nothing. If I made it shorter the tab would jump into the previous section and no longer line up with the other lines.
As far as I can see, the same will happen with this source example if it were using tabs and a proportional font.
Elastic tabstops are so named because the width adjusts based on the content, avoiding that problem. http://nickgravgaard.com/elastictabstops/
> Then it'll look wrong in a proportional font
Programmers don't use proportional fonts. Source code maintenance is hard enough without asking for trouble.
Programmers don't use proportional fonts. Source code maintenance is hard enough without asking for trouble.
...and maybe that's why most popular coding fonts are monospaced?
> ...and maybe that's why most popular coding fonts are monospaced?
Yes, the desire to use alignment without something like elastic tabstops being widespread is the limitation which prevents wide adoption of otherwise-superior proportional fonts in coding.
Yes, the desire to use alignment without something like elastic tabstops being widespread is the limitation which prevents wide adoption of otherwise-superior proportional fonts in coding.
This is a great argument, thanks.
In days gone by (pre git) a lot of devs used to share files via FTP; and the FTP clients back then were garbage; if you were sending files from a unix-like computer to a windows one and back and forth, your tabs might get converted to spaces by the client. Developers would end up with slightly different copies of the same file.
Many people decided to standardize various things (like the use of spaces for indentation) to compensate for this.
These days not a huge deal.
Many people decided to standardize various things (like the use of spaces for indentation) to compensate for this.
These days not a huge deal.
> Tabs take up less space in terms of bytes
Optimizing for size in the primary format for editing isn't that important. For deployment, sure, but you're going to minify for that anyway, right? So spaces vs. tabs makes no difference for that.
Optimizing for size in the primary format for editing isn't that important. For deployment, sure, but you're going to minify for that anyway, right? So spaces vs. tabs makes no difference for that.
I think the fact that tabs take up fewer bytes is basically irrelevant. For anything that matters, the JS will be minified anyway, removing the whitespace.
I decided to use spaces instead of tabs and convert a tab to two spaces because while typing I sometimes alternate between using the space bar and the tab while indenting something or editing code. So it is much easier for me to be consistent as an individual dev with spaces.
I prefer spaces (4 spaces to be precise), because I can write like this:
var abc = something,
var abc = something,
xyz = somethingElse,
stringOfAbc = abc.toString();
I remember once I got an error in an python script, and had to convert all tabs to space.
Btw I am JS developer.
This experience is more common than most people realize. A Python program mysteriously stops working, especially after being transferred to a new platform, and the most experienced hands will suspect a mixture of tabs and spaces, and/or tabs being treated differently than expected.
> Why do the majority of JS developers prefer spaces over tabs?
Because, with a fixed-pitch font such as is used in programming, the meaning of a space is unambiguous (unlike tabs). Also, having two indistinguishable whitespace characters is bad, and mixing them in a single file is worse. So one chooses the least problematic of the two.
Because, with a fixed-pitch font such as is used in programming, the meaning of a space is unambiguous (unlike tabs). Also, having two indistinguishable whitespace characters is bad, and mixing them in a single file is worse. So one chooses the least problematic of the two.
I'm a Python dev, and it's the same in Python world. I prefer spaces, and so do most other Python devs. This is in line with one of the Python community's core beliefs - "Explicit is better than implicit"
"Explicit is better than implicit"
I think making the implicit explicit is also a belief of most logical devs outside of the Python community.
I think making the implicit explicit is also a belief of most logical devs outside of the Python community.
> "Explicit is better than implicit"
Seems like a strong argument for sticking with strongly typed languages.
Seems like a strong argument for sticking with strongly typed languages.
Python is strongly typed.
Dynamic typing and weak typing are not the same thing.
Python:
Dynamic typing and weak typing are not the same thing.
Python:
>>>1 + "1"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>1 + "1"
2It helps that PEP define that spaces is explicitly correct as well.
Except when it comes to closing brackets... sigh
Why would you need those when you have indented blocks as a language feature? Unless you really like one-liners, in which case you should just use Perl or Ruby.
Kind of an old-school thing, I prefer the visual/literal cues of opening/closing brackets in statement groups, I guess I don't really trust encapsulation my mere indentation.
So yeah, I would prefer explicit (brackets) over just implicit (spaces), in python.
Perl and Ruby aren't Python.
So yeah, I would prefer explicit (brackets) over just implicit (spaces), in python.
Perl and Ruby aren't Python.
[1] http://sideeffect.kr/popularconvention/#javascript