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

21–30 of 51 posts

Re: Front End Development Guidelines

#21

Post by M1573RMU74710N »

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?

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

Re: Front End Development Guidelines

#22

Post by joeyespo »

taitems wrote: post #14
hartror wrote: post #13

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.

Re: Front End Development Guidelines

#25

Post by Breefield »

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.

My thoughts exactly.

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

Re: Front End Development Guidelines

#26

Post by taitems »

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.

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

Re: Front End Development Guidelines

#27

Post by neimado »

Painbird wrote: post #4

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.

"industry dream-boat Paul Irish" is where I stopped reading. eww. he doesn't even know how setTimeout works.

Re: Front End Development Guidelines

#28

Post by warfangle »

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.

Re: Front End Development Guidelines

#29

Post by thaumaturgy »

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.

Re: Front End Development Guidelines

#30

Post by akavlie »

mileszs wrote: post #7
pixeloution wrote: post #3

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.
Post reply on HN