11–20 of 51 posts
The Google JavaScript Style guide recommends single quotes over double quotes for this reason:
http://google-styleguide.googlecode.com/svn/trunk/javascript...
I disagree on the usage of double quotes over single quotes for strings. Single quotes are useful when the string contains HTML. The Google JavaScript Style guide recommends single quotes over double quotes for this reason: http://google-styleguide.googlecode.com/svn/trunk/javascript...
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 find Avoid Comparing to true and false a little pedantic and can someone explain how it is "... bad as it's ambiguous"?
if (isSelectable === true) { ... }
versus:
if (isSelectable) { ... }
It's a shorthand method, similar to why you would use int++; instead of int = int + 1;
I disagree on the usage of double quotes over single quotes for strings. Single quotes are useful when the string contains HTML. The Google JavaScript Style guide recommends single quotes over double quotes for this reason: http://google-styleguide.googlecode.com/svn/trunk/javascript...
It's interesting that Google and jQuery seem to disagree on this as per: http://docs.jquery.com/JQuery_Core_Style_Guidelines#Strings 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.
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.
Its better to link directly to the source, not a blog. http://taitems.github.com/Front-End-Development-Guidelines/
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 ;)
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?
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?