Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Front End Development Guidelines

taitems.tumblr.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Front End Development Guidelines

#31

Post by tremendo »

fuzionmonkey wrote: post #11

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.

Re: Front End Development Guidelines

#33

Post by taitems »

colinr wrote: post #32
taitems wrote: post #2

A deep link for those that want to skip my pre-amble: http://taitems.github.com/Front-End-Development-Guidelines/

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.

Re: Front End Development Guidelines

#34

Post by timdown »

warfangle wrote: post #28

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.

Re: Front End Development Guidelines

#35

Post by timdown »

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.

Re: Front End Development Guidelines

#36

Post by jacobolus »

bialecki wrote: post #18

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?

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

Re: Front End Development Guidelines

#38

Post by julian37 »

fuzionmonkey wrote: post #15
taitems wrote: post #12

Earlier quoted context omitted.

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. ' something ' 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 "something

" would work equally well.

Re: Front End Development Guidelines

#39

Post by mattmanser »

thaumaturgy wrote: post #29
evanwalsh wrote: post #24

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

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

Re: Front End Development Guidelines

#40

Post by roel_v »

taitems wrote: post #12
fuzionmonkey wrote: post #11

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.

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)

Post reply on HN