My favorite reason for using single quotes whenever possible, is that it doesn't require two fingers (Shift for double quotes), so it's easy on my fingers and faster, and it's also easier (for me) when switching languages, as normally you can use string interpolation when using double quotes. Similarly I find myself favoring += 1 for increments over ++ as the latter doesn't work in Ruby.
I'm yet to see a compelling argument for either. My original paragraph for string creation forgave C style strings, as they do seem very clean cut and easy to identify. I think this is an area that needs some debate.
I think the idea is that if you use single quotes for strings, you don't have to escape the double quotes that are often found in html. '<p id="foo">something</p>'
But the same goes for something like "you can't do that"
I guess it just depends what you don't want to escape. For Google, the more probable scenario was probably the former.
Single quotes are not 'C-style strings'. The article is wrong on strings in C. In C, strings and characters are different things (well actually, strings don't even really exist - they are pointers to the beginning of a char-array). So you can say char a1 = 'a'; and char* a2 = "a"; and they're very different things; for one, a2 has a terminating zero. (meaning: the first influences only the contents of a single byte, the second one two, leaving aside alignment).
In C: single quote = character, double-quote = easy initialization of array of characters terminated with \0.
(the above contains many simplifications, of course)
I usually aim to make code that solves the problem it was intended to solve, as elegantly as possible. (Where elegance correlates closely to efficiency.) Whether it's understandable or not is completely secondary.
Often this means that if I don't leave myself a reasonable comment about what I'm doing in that spot and why, I'll relearn the importance of good comments later.
What you're describing is often considered to be bad code, not good code.
Maintainability is quite often the most important thing when it comes to coding not terseness (which many do not consider to be elegant at all, quite the opposite, they see it as unnecessarily complicated and obtuse).
What you're describing is often considered to be good code.
Maintainability is quite often the most important thing when it comes to coding. Cryptic code, though sometimes a tad bit harder to understand, is often preferable when it substantially increases the performance of the application. Short, descriptive comments do the rest of the work for the maintainer.
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've been trying to follow the "do what is typical in the language in which you're writing" philosophy. So, in Ruby, I use underscores, because most methods and variables in common Ruby libs use underscores. In Javascript, I use camel-case, for the same reason. In CSS, I use a dash. In PHP, I do whatever tickles my fancy at that moment in time.
It's much more common practice in JavaScript. If you ever expect anyone else to have to deal with your code, it's nicer for them if you followed the conventions that most people are used to seeing.
I think it comes down to the readability and weight of the two, with underscore separated variables taking more horizontal space. But like same line braces, one persons readability is not the same as anothers.
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.
No. forEach() being native doesn't prevent it from generally being slower than a foor loop, because it still has to do a function call on every iteration.
It depends on what you're doing within the loop. With a for loop, you still have to perform an array lookup. For something simple, like summing up all the numbers in an array, forEach is definitely faster. Try JSLitmus'ing it.
Yep, I swapped it out at the last second. The previous typeface allowed embedding without OTF and TTF. Someone raised the issue over Twitter and it is now being tracked on GitHub.
Generally not bad, but there are some errors and oversights in here:
- 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.
- The comments example is demonstrating unnecessary comments. The check and the call in
if (zeroAsAString === 0) {
doHeapsOfStuff(param1, param2)
}
... are self-explanatory to even the an inexperienced developer and do not require comment. What may require comment is why the code performs this check and this call.
- 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
var bigArray = new Array(1000);
- 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?
I find that much more readable, especially when looking at code completion in the IDE, I can always tell whether a property is a method or not.
For example, you might have an object foo that has a property called isBar. I like being able to tell that that is a function that returns a true or false value, as opposed to is_bar which just holds the boolean value.
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.
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.
2. The user is always right. Even when they run unpatched IE7 with JavaScript and CSS on but images hidden.
Then a few pointers I would like to add:
- 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.
- 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.
I was keen to write a foreword explaining that I am self-taught, so there are going to be shortcomings in my theory knowledge - as I never did a CS degree. It was to mitigate the shread-tearing I expected to receive in the comments section of HN ;)
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.
I'll put my hand up for that mistake. I think the word I was looking for was "redundant", and not "ambiguous". Following the other concept of prefixing your booleans with "can" "has" and "is", your variable names should be self explanatory.
if (isSelectable === true) { ... }
versus:
if (isSelectable) { ... }
It's a shorthand method, similar to why you would use int++; instead of int = int + 1;
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.
The Google JavaScript Style guide recommends single quotes over double quotes for this reason:
http://google-styleguide.googlecode.com/svn/trunk/javascript...