I hope it's clear that I'm not suggesting there are no other ways to solve this problem. I just tried to pick an example of something I actually learned reading the book that arose as a consequence of things I thought I already knew but hadn't put together.
I was trying to give a sense of why, if you look at the TOC and see that it discusses topics A, B, and C that you already know, you may be very pleasantly surprised when you read the book by something you didn't know about A+B, B+C, A+C, or A+B+C.
Exactly, the issue mentioned shouldn't be why there's a semicolon before the function wrap, but why are you wrapping your code like that in the first place.
I think more that the bug is in the code that's doing the wrapping, and therefore the fix should also be in the code doing the wrapping, and not in the code being wrapped.
The problem is if you're using 3rd party libs, especially if the 3rd party code is coming from developers with the philosophy that ASI is a good thing and intentionally leave out the semi-colons from their code. Adding the semi-colon to the code you control is safe and doesn't hurt anything.
If you're using a library that stitches together multiple JavaScript files - all of which work when included via separate script tags - and the resultant file doesn't work (due to the issue mentioned in TFA at least), then that's a bug in the library that stitches multiple JavaScript files together, and should be fixed there.
Adding a semicolon to the start of your IIFE doesn't really hurt, but it's a workaround more than a solution.
I came across this issue when stitching some files together for min/merge... I simply had the merge process insert a semicolon after each file, for effectively the same reason.. multiple semicolons aren't going to hurt anything... The reason for wrapping your script in an anonymous function is similar, not polluting the global namespace, or at least not relying on certain globals.
These are conventions, not because you have to, but because you avoid other issues further down. You COULD simply write all your scripts inline.. and if you are judicious it is probably a bit better performing. That doesn't mean you want to... JavaScript in practice is much more about convention to prevent/limit obstacles than a "one right way" philosophy.
Hell, look at CommonJS vs AMD and the various solutions there alone... not even including all the one-off processes that have been used over the years.
I wasn't asking you directly, the question was kind of rhetorical. The reason is that boilerplate code like that, should be abstracted away from the actual code that we write and I was kind of hoping to see that mentioned when I saw the jQuery boilerplate.
Very good point, thanks! That is one of the little joys of CoffeeScript, many of the "defensive" coding practices don't exist. Fortunately, the book isn't just about avoiding problems but also about positive, productive idioms and practices.
I think I picked this example in a bootless attempt to humblebrag by pointing out something I'd been cargo culting.
Buy the eBook at the link below with a 45% off coupon code (and you get it in 3 formats: .mobi, .pdf, and .epub — UNBELIEVABLE. (I have never gotten more than one format of the eBook anywhere).
http://www.informit.com/store/effective-javascript-68-specif...
Many tech publishers now sell their ebooks as bundles: one price for multiple formats (usually the big three, sometimes even more). O'Reilly, PragPublishing, NoStarch, Informit spring to mind. (Not saying that it isn't a good thing, but I'm surprised you think it's rare.)
Thanks for the info, telemachos. I have always bought my eBooks from Amazon and, on some rare occasions, from iBooks iPad app. So I am happy to know there are better deals outside of Amazon.
In most cases, however, the eBooks (Kindle) are cheaper on Amazon, but I am willing to pay a few dollars more to get the eBooks in all 3 formats (.pdf. .epub, and .pdf). I personally prefer to use iBooks (.epub works fine), when I am on my iPad, and the .pdf—when I am on my laptop.
No offense but the idiom you talked about sounds like "clever code" (in the bad way). One shouldn't have to be guessing what a sequence of semicolons and parentheses are for. There are perfectly self-explanatory language constructs to deal w/ post-file-concatenation code integrity (e.g. "new function" is just one character longer, and if you really want to be explicit and/or pedantic, there's "void function() {}()", which is not that much longer.
As I pointed out, I was using this idiom out of superstition, I didn't fully understand what it did and why I was doing it. Now that I read The Fine Book, I'm in a better position to evaluate whether it is necessary and why other approaches may be superior.
I see that the review could be improved by explaining that the idiom is not something the book recommends pr se, but rather something I understood once I read the book.
Correct me if I'm wrong but I believe that the straightforward option is that the tools that perform concatenation handle this as well. Are there any downsides to this approach?
Technically speaking no, but socially speaking yes. You wouldn't want your code base made entirely out of code golfing that works through miraculous twists and bends. By the same logic, you should prefer even small aspects of your code to be clear to a junior developer (or even yourself a year from now), rather than overly clever and packed with several layers of obscure knowledge in a single character.
I completely agree, that's why I'm saying that it shouldn't be in the codebase. It should be handled by external tools that are performing the concatenation.
Of course that begs the question if this is necessary at all since I personally haven't seen it used but I haven't read the source of many JavaScript projects either.
I'm of the opinion that the behavior of code shouldn't be changing depending on what tool you pass it through. If down the road your homebrew concatenation script gets replaced by, say, a minification tool that does concats, but no ASI defensive code, then your code might break.
Besides, you don't necessarily want all files to be automatedly wrapped in a function. jQuery for example would break.
[1]https://github.com/component/component