// Coders, if your goal is to align foo and bar, using a <tab> character is | |
// incorrect. If your goal, however, is to create an additional level of | |
// indentation, then go you. Either way, with a tab size other than 4, this | |
// looks like shit. | |
var foo = 1, | |
bar = 2; |
Absolutely. Tabs are semantic, spaces are presentation.
+1. This bugs the hell out of me even when spaces are used for formatting. Linters wanna call you out for mixing spaces and tabs. However, JSHint can be configured to ignore this by setting "smarttabs": true
.
I still don't understand why everything needs to be perfectly lined up anyway.
@timw4mail Because OCD.
@mathiasbynens I could say the same thing about tab-stops - like everybody should have tabstops set to 4, and then there's no issue.
Mixing tabs and spaces leads to a mess unless it's at your tabstop level anyway.
@timw4mail this doesn't just apply to variable declarations. If you're ever using hard tabs for indentation, you MUST "format" code using spaces. The reason why so many claim tabs are superior is because individual developers can configure them to their preference. You break that if you enforce tab widths.
FWIW, the issue becomes moot if you just do this.
// Tabs? Spaces? It doesn't matter.
var foo = 1;
var bar = 2;
@cowboy superfluous var statements?
In the spirit of compromise I propose we all use semicolons as the indent. It lines things up perfectly no matter your tab stops, avoids trailing semicolons despised by ASI followers, and makes accidental line breaks really easy to see. No downsides.
;function baz() { ;;var foo = 2, bar=1 ;;if ( foo > 7 ) { ;;;alert("Stack overfoo") ;;} ;}
Or you can just...
var foo = 1, // there's a tab between var and foo
bar = 2;
Which looks perfectly fine inside an editor (but in all seriousness, tabs do suck).
fuckit. var foo=1,bar=2; FTW. (?)
I posted a followup blog post, Multiple var statements in JavaScript, not superfluous.
Personally, I use IAP (Indentation Abstraction Pattern). You've probably never heard of it before. It's something I've developed after years of implementing ESCM (Enterprise Social Cloud-based Mobile) Apps. It goes a little something like:
var IDNT = "tabs";
function baz() {
IDNT;var foo = 2, bar=1;
IDNT;if ( foo > 7 ) {
IDNT;IDNT;alert("Stack overfoo")
IDNT;}
}
Now that's a level of abstraction even your most bearded Java developer could appreciate.
David Desandro wrote a nice post explaining why he uses multiple vars.
http://dropshado.ws/post/17210606192/varry-var-var
"At first I gawked at this style, but after using it for two months, I’m sticking with it. Using multiple vars have a couple benefits:
Easier to add more variables, no need to change any trailing comma or semi-colon.
Eliminates unnecessary git commit diffs, where a line has changed only because you changed a trailing semi-colon or comma.
Easier to read (IMO). var is a reserved keyword, so it jumps out when syntax highlighted.
Eliminates awkward tab spacing underneath the var. It only lines up if your tabs are 4 spaces wide.
[Per JFSIII] Helps collaboration, other devs might miss the change of semi-colon and accidentally add a global variable.
If you’re worried about bloating your code with all the superfluous vars, that should be taken care of when using a proper minifier."
I, personally, go with Desandro on this. After all, it's only a preference, not a coding convention.
I think people are forgetting that a preference
differs slightly than a convention, in that you're adopting your own style, not a codified "way" of doing things.
Google for "coding conventions javascript" and you'll see many codified ways of writing JS.
i recently just tried doing:
var
foo = "bar",
baz = {
bat: "bam"
},
etc = [ "etc" ];
i'm not sure how i feel about it.
// Initialize program vars
var foo, baz, etc;
// Some useful comment
foo = "bar";
// Another useful comment
baz = {
bat: "bam" + foo
};
// Moar useful
etc = [ "etc" ];
I wish I could lock gist comments.
First semi-colons, now tabs or spaces... Are these the meaningful topics to discuss? What a community we have JS people...
Every topic is meaningful.
I know this is a year old now, but I still find this topic very interesting. I kind of like the stack way of declaring variables if you must comma separate a group of variable declarations, such as:
var
foo = 'bar',
baz = 'qux';
This way, indentation dosen't matter, and there is kind of a visual hierarchy which is important (The var acts as a heading, giving purpose to the following lines).
On the other hand, with the more common comma separated declaration, just one var is visually flagged as a newly declared variable, and the others could look like they may have been previously declared... until you notice that there is a ,
there, not a ;
Why not just take the ambiguity away? Just add a 'var' keyword to purposely identify each new variable declaration. Superfluous? No. Considerate, good for readability, future proofing and collaboration. Yes.
var foo = 'bar';
var baz = 'qux';
It's just not that bad.
To everybody who writes “mixing spaces with tabs is evil” and "tabs are semantic, spaces are presentation" to fix that. At first, using both does create the mixture, "which is evil". Secondly, you, as big experts in presentation, tell me: isn't HTML a special presentational format? How do you use spaces for indentation in HTML? What?
Spaces are for (inter-word) spaces, tabs are for indentation. As of github, it has a perfect solution to "set the tab size". It just stops to work outside the Ace editor, http://stackoverflow.com/questions/8833953/how-to-change-tab-size-on-github. The solution is to save the option along with edited post.
The same answer in StackExchange http://programmers.stackexchange.com/a/72/63834. These are you, spaces people, who confuse presentation with data and create chaos.
BTW, I have made a tabs <-> spaces conversion utility, http://valjok.blogspot.com/2014/07/indentation-correction-for-exposing.html. I was forced to create it intentionally for gist formatting.
Amen to that. Also, this is why the whole “mixing spaces with tabs is evil” thing needs to die. Use spaces for presentational whitespace, and tabs for indentation.