Front End Development Guidelines | Hacker News Reader

Front End Development Guidelines

taitems.tumblr.com

154 pointstaitems49 comments

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...

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.

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.

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.

The former isn't a very good reason: HTML/XML accept both double and single quotes, so "<p id='foo'>something</p>" would work equally well.

yes, but it is much more common for double quotes to be used in html

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)

"Javascript code requires regular commenting in order to make it easily understandable."

Or you could, you know, just make code that's understandable.

I'm such an Internet jerk.

You know what? I just noticed my team leader slipped that one in when he was proofing it. I might rewrite/remove that.

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.

My thoughts exactly.

I mean, you should comment your code, but Javascript doesn't make me think of "regular" commenting.

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.

My thoughts exactly. Much as I prefer the Python/Ruby convention of underscores, this is not the JS convention, and consistency is important.

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.

EDIT: The other response is more accurate.

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.

This is how underscore.js implements each()

A deep link for those that want to skip my pre-amble:

http://taitems.github.com/Front-End-Development-Guidelines/

Your examples don't show with JavaScript turned off. (this isn't to be pedantic, this is how I and many others browse)

Sorry to point this out, but doesn't your section "@font-face Use and Abuse" rule out embedding typefaces like Gotham?

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.

thank you for this excellent submission and write up - you've now given me some great suggestions to tackle this week on my Web app.

THIS is why I hang out here. :) Kudos..

Aah, I went there expecting guidelines for building a lexer and a parser. Then I realized this wasn't about a compiler frontend.

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?

> camel casing variable names is right,

Personally I disagree. In my code-bases it's:

functions: doSomeThing()

constructor: new Foobar()

object/array/primitive: some_object

"constants": SOME_VALUE

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.

"self" isn't a reserved keyword in JavaScript...

And there's those of us who prefer lowercase unix_case_for_variable_names and function names over camel case.

Nope, exactly the type of feedback I'm after. Thanks a lot!

Nice guide & nicely written!

This example snippet actually generates a Javascript error (at least, in IE9):

    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
    }

It will work if bar is declared but has value undefined, but not if bar is completely undeclared as shown.

common error.

  typeof bar === 'undefined'

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.

Indeed. But perhaps the author can't decide or doesn't want to recommend SASS over LESS and vice versa.

Its better to link directly to the source, not a blog. http://taitems.github.com/Front-End-Development-Guidelines/

I did that below as the first comment.

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.

Not sure if this is what you're looking for, but it covers very similar material http://na.isobar.com/standards/

Im not sure if this is the one or not, but definitely a great resource and more or less what I was looking for, thanks.

I find Avoid Comparing to true and false a little pedantic and can someone explain how it is "... bad as it's ambiguous"?

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;

I was just wondering the same thing. Thought there was some magic javascript concept I somehow missed. Glad you answered!

Good article, bookmarked it for reference/a checklist.

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.

I was a little off-put by the inclusion of that phrase.

Reply on news.ycombinator.com