Use semicolons. Always. It's looks cleaner, and you won't come up against stupid errors like
return
{
foo: 7
}
From the article -
When you're done trying to wrap your brain around
why would anyone in their right mind want to write
a return statement on a new line
Well, if they love having { on newlines, then it's pretty obvious:
function foo()
{
return
{
bar: 8
}
}
From the article -
That's 24 bytes right there. Stamp semicolons
everywhere and run it through a minifier:
var a=1;var b=2;var c=3;
Yeah um, hate to break it to you, but a minifier (and any experienced coder) would write it as "var a=1,b=2,c=3;"
// after minification
if(condition){stuff()}
Wrong again. Use a better minifier. Closure advanced mode for example will remove the {}, inline functions if it makes sense and hundreds of other things.
Easy solution: when a line starts with parenthesis,
prepend a semicolon to it.
;(d + e).print()
Ugly horrible hacky advice.
I remember when I first saw C code (coming from BASIC) and thought similar thoughts - eugh what are all those useless semicolons they don't do anything what's the point of them etc.
One important point is that it allows you to rearrange the whitespace in your code, without changing the execution meaning of your code. Which is pretty useful in making your code beautiful and readable and avoiding bugs.
I think my new pet-peeve is the word "clean". What you mean, when you say that, is that it looks good, according to your taste. That's a rather subjective statement, disguised as an objective one.
The original argument is not about the minifier, but about semicolons.
By the way, why would your better minifier introduce a semicolon here ? This is obviously a useless character in this example.
Also, I don't understand how adding a semicolon could help against the "stupid error" you cite. Could anyone please explain ?
Do we really want to heed advice when it's comes with obviously wrong advice like "Only people can detect and solve software bugs, not tools."
Static bug analysis is definitely not the be all and end all of software quality but definitely has a place. We automatically run FindBugs (along with unit test etc) on our code base every time new code is pushed by a developer and it definitely helps pick up quirky little errors much more cheaply than code reviews.
I use semicolons, and a linter to let me know when I miss them, because IE pukes all over itself if I don't. Same with trailing commas, IE HATES those.
the basic message seems to be "don't do what everyone else is doing just because everyone else does it".
Which is great in your bedroom, but in a team with lots of eyes on your code the most efficient way is to use the same style, with that style being one that is easy to read and that avoids potential misunderstandings and bugs.
I can't imagine any situation in the sphere of development this article is about in which worrying about a couple of hundred bytes is more important than having a set of code that someone other than yourself could happily sit in front of.
So in essence, the problem is still to be blamed on those specific JS implementations. Optional means optional, at which point making an implementation that demands the absence of semicolons is as bad as one explicitly requiring them, as both are breaking the set rule: optional.
(personally, I'm for the mandatory semicolon, to avoid mistakes)
The minifier he uses seems rather bad, wonder which one it was? Ie instead of var a = 1;var b=1; it could be var a=1,b=1;
Also in case of the single line if, the minifier could actually remove the brackets.
Simple question: Which code does preserve your lifetime? Highly optimized, less readable but really short code, or highly readable, good structured, better maintainable code? As for me, I really enjoy sharing my code with my colleagues. Maybe there are others who don't, but they always will have to work alone in the basement where light never reaches theirs pale faces (think of 'The IT Crowd', for example).
Hm, if we look a little more generalized at what that says, its like:
"If theres a language/library feature with a few quirks, use it anyway, if the border cases aren't that usual."
Thats really bad advice. The main disadvantage is that no one will, if you combine a lot of such decisions, have all this border and special cases in mind, all the time.
Gotta make a plug here for CoffeeScript, in which semicolons really are optional. CoffeeScript code compiles to neat, legible JavaScript (with semicolons).
I fail to see the problem with minification. The minificator can insert semicolons by itself because the algorithm for that is known and present in every JS engine. Besides, it just looks cleaner without them. Less for errors too.
The way this semicolon-free syntax is implemented should be reason enough not to rely on it: if the interpreter/compiler encounters an error, it steps back, inserts a semicolon and tries again.
axod|15 years ago
I remember when I first saw C code (coming from BASIC) and thought similar thoughts - eugh what are all those useless semicolons they don't do anything what's the point of them etc.
One important point is that it allows you to rearrange the whitespace in your code, without changing the execution meaning of your code. Which is pretty useful in making your code beautiful and readable and avoiding bugs.
danh|15 years ago
troels|15 years ago
I think my new pet-peeve is the word "clean". What you mean, when you say that, is that it looks good, according to your taste. That's a rather subjective statement, disguised as an objective one.
(end of rant)
peti|15 years ago
Also, I don't understand how adding a semicolon could help against the "stupid error" you cite. Could anyone please explain ?
travem|15 years ago
Static bug analysis is definitely not the be all and end all of software quality but definitely has a place. We automatically run FindBugs (along with unit test etc) on our code base every time new code is pushed by a developer and it definitely helps pick up quirky little errors much more cheaply than code reviews.
jameskilton|15 years ago
Article ignores reality.
lhorie|15 years ago
weego|15 years ago
the basic message seems to be "don't do what everyone else is doing just because everyone else does it".
Which is great in your bedroom, but in a team with lots of eyes on your code the most efficient way is to use the same style, with that style being one that is easy to read and that avoids potential misunderstandings and bugs.
I can't imagine any situation in the sphere of development this article is about in which worrying about a couple of hundred bytes is more important than having a set of code that someone other than yourself could happily sit in front of.
ronnier|15 years ago
nixy|15 years ago
hackermom|15 years ago
(personally, I'm for the mandatory semicolon, to avoid mistakes)
Tichy|15 years ago
mike-cardwell|15 years ago
if(condition) stuff()
To:
condition&&stuff()
So no, it doesn't add curly brackets and increase the size of the expression. And Google closure converts:
var a=1
var b=2
var c=3
To:
var a=1,b=2,c=3
Not what he said all minifiers do.
lzimm|15 years ago
Use semicolons or your shit wont work in IE... That's why semicolons in javascript AREN'T optional.
subbu|15 years ago
eterps|15 years ago
HendrikR|15 years ago
abp|15 years ago
"If theres a language/library feature with a few quirks, use it anyway, if the border cases aren't that usual."
Thats really bad advice. The main disadvantage is that no one will, if you combine a lot of such decisions, have all this border and special cases in mind, all the time.
earnubs|15 years ago
lhorie|15 years ago
http://www.ecma-international.org/publications/files/ECMA-ST...
Section 7.9.2 (page 37)
snitko|15 years ago
TrevorBurnham|15 years ago
http://coffeescript.org
RommeDeSerieux|15 years ago
phoboslab|15 years ago
maw|15 years ago
seasoup|15 years ago