I disagree on the usage of double quotes over single quotes for strings. Single quotes are useful when the string contains HTML.<p>The Google JavaScript Style guide recommends single quotes over double quotes for this reason:<p><a href="http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Strings#Strings" rel="nofollow">http://google-styleguide.googlecode.com/svn/trunk/javascript...</a>
"Javascript code requires regular commenting in order to make it easily understandable."<p>Or you could, you know, just make code that's understandable.<p>I'm such an Internet jerk.
Why do you believe camelCaseIsBetter and more readable then using_underscores_in_variables ? While you're entitled to your opinion, calling one "good" and the other "bad" is a bit overboard.
I'd like to point out that if jQuery fell back to the fundamental Array.prototype.forEach function when available, $.each would be /much/ faster than a for loop. Array.prototype.forEach, when available, is native code.
A deep link for those that want to skip my pre-amble:<p><a href="http://taitems.github.com/Front-End-Development-Guidelines/" rel="nofollow">http://taitems.github.com/Front-End-Development-Guidelines/</a>
Generally not bad, but there are some errors and oversights in here:<p>- At the end of the "Always Use === Comparison" section, the example will throw a ReferenceError if (as is suggested) the variable `bar` has not been declared. If you're testing a variable that may not have been declared, you either need to use a `typeof` check or declare bar using `var bar;`, which will be essentially a no-op if bar exists and declares it with a value of `undefined` otherwise.<p>- The comments example is demonstrating unnecessary comments. The check and the call in<p>if (zeroAsAString === 0) {
doHeapsOfStuff(param1, param2)
}<p>... are self-explanatory to even the an inexperienced developer and do not require comment. What may require comment is <i>why</i> the code performs this check and this call.<p>- Your array in the "Loop Performance - Use ‘break;’ & ‘continue;’" section has one element. I know it's just an example, but it would be better as an example if it worked. You could instead use<p>var bigArray = new Array(1000);<p>- Chaining has downsides, the main one being it makes debugging much harder. You might want to mention this.
This is good, but some of the advice isn't quite right. For instance "self" is a reserved keyword in JavaScript, so often people use "_self" instead. And camel casing variable names is right, unless they're constants, in which case "THIS_IS_A_CONSTANT" is more appropriate. Too nit picky?
Nice guide & nicely written!<p>This example snippet actually generates a Javascript error (at least, in IE9):<p><pre><code> var foo = null;
// foo is null, but bar is undefined as it has not been declared
if (foo == null && bar == null) {
// still got in here
}
</code></pre>
It will work if <i>bar</i> is <i>declared</i> but has value <i>undefined</i>, but not if <i>bar</i> is completely undeclared as shown.
These are good, I am pondering how to add to them. I think I would like to start with a principles section. It is at least possible these days to get a "principles of CS" education. But the principles of front-end are somewhat different.<p>1. This is the web. Users will resize the window, copy and paste, click a button five times, turn off JavaScript, and arrive from every possible combination of browser, operating system, and language. You will maintain an appropriate fear of any trick so complicated that you don't know what it will do under all of those circumstances.<p>2. The user is always right. Even when they run unpatched IE7 with JavaScript and CSS on but images hidden.<p>Then a few pointers I would like to add:<p>- Think twice before binding to every instance of an event. Are you looking for a keydown, a mouse move, or a scroll? Throttle your function to make sure it runs only ten times a second, or whatever is appropriate. Ironically, the faster browsers and JS environments become, the slower your pages will be if you calculate something on all 1000 scroll events per second.<p>- For heaven's sake try to avoid absolutely positioning your whole interface. But if you do, you better try it in every browser and resize it real fast to see if it works.
Kind of surprised that there's no love for sass/scss here. Scss has made producing css a delight and v3.1 was just released which is great. Any front end developer who hasn't given it a shot should try it at least once.
Its better to link directly to the source, not a blog. <a href="http://taitems.github.com/Front-End-Development-Guidelines/" rel="nofollow">http://taitems.github.com/Front-End-Development-Guidelines/</a>
I remember awhile back another post kinda like this where it was a companies new front end dev training material. Anyone remember that or have a link? I've been trying to find it.
This looks good - however some of the language used is a bit interesting. I laughed when I read "chain like a sick bitch" but I believe most people (especially young kids, who will benefit from this the most) may see it as a bit aggressive / over the top.