Javascript patterns

http://shichuan.github.io/javascript-patterns/

by ekpyrotic • 13 years ago

210 45 13 years ago

shichuan.github.io

Good.

theonej• 13 years ago

these patterns are cute. I especially like the one where for loops are described, as if the variable declaration practices are important.

deelowe• 13 years ago

And the recommendation to avoid i++ due to "excessive trickiness?" followed by a recommendation to use while(i--) with i initialized somewhere else as a for loop substitute? What the heck? That sounds terrible.

rnd336• 13 years ago

Regarding function declarations, it considers function declarations to be an antipattern and advises you to instead use function expressions at all times (https://github.com/shichuan/javascript-patterns/blob/master/...).

I'm really skeptical about this. Using function expressions has some quite subtle consequences (hoisting, accidental/unintended closures) which you automatically avoid when using function declarations. Function declarations are also very useful since they allow you to use the function before it is defined (in the code), which mean you can read the code (and use the function name as an abstraction) without having to scroll past all function implementations.

To expand a bit on the accidental closures part, a variable bound by a closure is an implicit dependency of that function. By breaking function expressions out as function declarations you can be more explicit about what kind of input that piece of code needs from the outside. I just think overuse (nesting etc.) of closures can lead to some quite messy code, it gets harder to reason about when a variable was actually bound and to what.

fbgv• 13 years ago

I also doubt its enforcing of good semicolon habits, considering that semicolons are not needed after many a statement in C-like languages, including Javascript.

This seems more of enforcing one's personal opinion than anything else, to me.

ivanca4• 13 years ago

It does bite you if you are not careful, for example:

    (function(){
        var foo = 1;
        console.log(foo);
    })() // Semicolon missing!

    (function(){
        var bar = 1;
        console.log(bar);
    })()

It's ambigous for the parser so this will throw a TypeError: "undefined is not a function". So overall I don't think is a stylistic choose but a safety one.

woah• 13 years ago

I would rather have code that always works than have it be all pretty and semicolonless.

arnorhs• 13 years ago

Actually, the reason you can use the function at a place in code before it's defined is actually because of variable hoisting. The name of the function is hoisted to the beginning of the scope in which it's defined. (this may be what you mean, but it was unclear from the comment)

But I agree that I don't think doing var func = function(){}; is in any way better than a normal function declaration. Actually, I think it's a bit ridiculous to even have one recommended over the other.

rnd336• 13 years ago

Yes, a function definition is hoisted too but its implementation is always hoisted together with its declaration, preventing some bugs caused by variable hoisting.

I made an example here: http://pastebin.com/2nS9EDPb

(Please correct me if I'm wrong, I wasn't aware for example that function declarations were treated as variables, redefinable etc)

jbnicolai• 13 years ago

Not just the name, the entire function declaration is hoisted. That's the difference between:

    function () {
      ...
      var a = function () {};
    }

which gets hoisted to:

    function () {
      var a;
      ...
      a = function () {};
    }

and:

    function () {
      ...
      function a () { };
    }

Which gets hoisted in it's entirety to:

    function () {
      function a () { };
      ...
    }

Which will cause difference behaviour between the two when calling a in the ... section, working in the latter case but undefined in the first.

I don't think the grandparent was unclear about this in his post though.

jaredmcateer• 13 years ago

The main argument for a function expression assignment is that it behaves like everything else where as the function declaration does some magic. As long as you and all your team members are aware of said magic it's probably fine but personally I would side on consistency.

tracker12• 13 years ago

I happen to rely on function hoisting as well.. which each file being a module, I tend to define the module at the top, and have declarations below.

I also tend to prefer methods that accept an object parameter as opposed to using "this" and will often put wrappers on objects such as...

  Foo.prototype.bar = function(){ 
    Foo.bar.apply(null, p(arguments, this)); 
  }

with p being an alias to Array.prototype.shift.apply, put the second arg to the top of the former as an array... it's generally wrapped in a utility function... With that in place my entire prototype's functions are just pass through to static Foo.fn .. in general this makes it easier to test modules that are instance objects.

Though prefer to have utility modules over modules that expose an object constructor... Exception being Models, which inherit from EventEmitter2

raganwald2• 13 years ago

We have a special on combinators this evening. Why not try a side order?

    function explicitize (fn) {
      return function () {
        return fn.apply(null, p(arguments, this));
      }
    }

Now you can write:

    foo.prototype.bar = explicitize(function (myself, something, etc) {
      // ...
    }

raganwald2• 13 years ago

Using function expressions has some quite subtle consequences (hoisting, accidental/unintended closures) which you automatically avoid when using function declarations.

Obviously, there is the issue of hoisting the function's expression as well as its name when you use a declaration, versus only hoisting the variable when you use an expression.

Are there any other subtle hoisting consequences to consider?

With respect to accidental/unintended closures, can you elaborate on this? Perhaps provide an example showing why a function assigned as an expression creates an accidental closure but a function that is declared does not?

You say: A variable bound by a closure is an implicit dependency of that function. By breaking function expressions out as function declarations you can be more explicit about what kind of input that piece of code needs from the outside.

I admit I don't understand at all how a function declaration changes the behaviour of its free variables. What is there about a function declaration that provides more control over its dependencies on its enclosing environment?

rnd336• 13 years ago

Are there any other subtle hoisting consequences to consider?

I can't think of any, other than consequences from the hoisting such as making the order of the variable declarations important (whereas it's not important if they were function declarations).

I admit I don't understand at all how a function declaration changes the behaviour of its free variables. What is there about a function declaration that provides more control over its dependencies on its enclosing environment?

You are correct, it doesn't. I realise now that in my head I was not strictly comparing function declarations to function expressions, but rather top-level function declarations (like in C) versus function expressions defined at some inner scope.

Using function declarations at any other scope than the top-level is something I would consider an anti-pattern (if I had to use that word), since it's very confusing to programmers from other C-like languages.

With respect to accidental/unintended closures, can you elaborate on this? Perhaps provide an example showing why a function assigned as an expression creates an accidental closure but a function that is declared does not?

So, as I said above I was referring to function expressions versus top-level function declarations, which probably makes this question obsolete. I should perhaps have said unnecessary closures, since if you capture 10 variables but only use one then perhaps you should rethink your design. Closures are super useful but they tend be abused (yay access to everything!) which leads to bad design (low separation of concerns and overall spaghetti code).

I suspect from your questions you already know all of this. I should have been more clear that I was not talking about any semantic differences between function declarations and function expresses, since you are correct in that there are none, but rather the design choice of using a function expression (and thereby capturing the variables in scope) versus breaking it out as a top-level function declaration thus making it necessary to explicitly state all input as arguments.

mattmanser• 13 years ago

Personally whenever I see a javascript programmer doing this with simple functions, I think it shows a pretty fundamental misunderstanding of programming to me.

The guy even hints at the misunderstanding in his code with the comment 'Makes it easier to understand "functions as an object"'. So what, most other languages have this now, but you don't see them taking one of the fundamental building blocking of programs and code encapsulation, simple function declaration, and bunging it in the middle of another method.

It's much clearer using the style for closures only so you're explicitly making it clear 'hey look, I'm making a closure people!!'.

It's a style that's practically begging for you to write heavily coupled code and is anti-code reuse. It's a terrible habit, it was all started by Crockford's the good parts, a style he just happened to be using at the time as far as I can tell, and even he doesn't even do it any more.

It also makes your code harder to read as you can't just move the function declarations wherever you want, just in case.

IMO you should never assign a function to a variable unless you are going to use it as a closure or actually use it like a variable and potentially over-ride it later in your code.

To me it's a massive code smell when I see simple functions assigned to variables.

feider• 13 years ago

Massive use of unclear 'it' reference in this text. Funny how it reminds me js..

bulatb• 13 years ago

Previous discussion: https://news.ycombinator.com/item?id=5392984

This source has some problems.

dpweb• 13 years ago

Why call eval like this? (1, eval)('this');

dcherman• 13 years ago

I'm pretty sure it's due to http://es5.github.io/#x10.4.2 section 1A.

Calling eval like that causes it to be an indirect eval call which results in it being executed in the global context.

nairteashop• 13 years ago

I was wondering too. There is a nice answer at SO that expands on what dcherman said: http://stackoverflow.com/a/9107367

kangax• 13 years ago

http://perfectionkills.com/global-eval-what-are-the-options/...

simoncion3• 13 years ago

This UI is pretty terrible on somewhat small screens. Here's what it looks like when sized to 1024x768:

http://i.imgur.com/X78sHxx.png

Note that the links behind the blue translucent rectangle are unclickable.

kristopolous2• 13 years ago

Grey on grey is usually a bad usability move if you expect people to read your content.

(For FF use nosquint: https://addons.mozilla.org/en-US/firefox/addon/nosquint/ and Chrom* use high contrast: https://chrome.google.com/webstore/detail/high-contrast/)

I don't know about others, but there's really no chance I'd be physically able to read those words without things like this. My eyes blur and I feel a physical strain on them - like I'm trying to do some type of eyeball aerobics.

I literally can't read more than about a sentence without having to look away a few moments and then return.

simoncion3• 13 years ago

I can read grey on grey just fine, even on my old laptop with its terrible color and worse grey resolution. Moreover, that site isn't grey on grey, it's grey on light cream ( https://en.wikipedia.org/wiki/Cream_(colour) ).

If you haven't already, go to a doctor and get your eyes checked out. What you're describing is not typical.

voltagex_• 13 years ago

Considered adding a Github Issue for this? https://github.com/shichuan/javascript-patterns/issues

(or do you mind if I add one for you?)

simoncion3• 13 years ago

Feel free to add one for me. Link to that imgur picture if you care to. Thanks! :)

thomasfl• 13 years ago

Or even better. Consider to send a pull request too.

avodonosov• 13 years ago

Are you really going to write "var getData = function getDataF () { };"

instead of "function getData() {}"

for pseudo benefits like

* 1. Makes it easier to understand "functions as an object". * 2. It enforces good semicolon habits. * 3. Doesn't have much of the baggage traditionally associated with functions and scope.

rnd336• 13 years ago

Agreed, and what exactly is the baggage traditionally associated with functions and scope that you avoid by using a function expression?

amckinlay• 13 years ago

Aren't these considered "idioms"?

_mikz• 13 years ago

one page PDF would be great

alfl23• 13 years ago

It's not bad, but you barely scratch the surface. Here's one: http://stackoverflow.com/questions/12973706/javascript-colle...

mattparlane• 13 years ago

Very cool. I'd recommend adding something about callbacks defined in loops, ie:

  for (var i = 0; i < 10; i++) {
    $('.thing').click(function() {
      alert(i);
    });
  }

Javascript patterns

Related Stories