Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Function Declaration as anti-pattern?

11 views
Skip to first unread message

Ross McKay

unread,
Jan 26, 2012, 7:45:25 PM1/26/12
to
OK, this is different: apparently, the function declaration is now seen
as an anti-pattern. This doesn't sit comfortably with me; can the
resident experts please weigh in and discuss?

I can understand Resig's logic in better enabling students to come to
grips with functions as first-class objects, but... an anti-pattern?

---

http://www.blog.highub.com/javascript/javascript-pattern-roundup-issue-2/

[...]
Function Declarations is added under General Patterns section, it was
first mentioned on John Resig's recent blog post.

// antipattern
function getData() {}

// preferred
var getData = function() { };

[...]

---

http://ejohn.org/blog/javascript-as-a-first-language/

[...]
As we've begun to look at the prospect of JavaScript-as-a-first-language
a number of obvious warts stick out (as is obvious to anyone who has
worked with JavaScript for any duration). To make sure that general
warts don't crop up we will be using some form of linting (either JSLint
or JSHint or similar) in the code editor to give the users contextual
information on what's happening with their code and why they should be
writing their code in a certain way.

We want to go beyond basic syntax tweaks though and find ways of using
the language that'll result in an easier learning experience. In
particular there are two changes which will likely result in a much
simpler on-ramp to learning.

[...]
Perhaps the most interesting change that we can make is a rather subtle
one, but it's eschewing normal function declarations for creating
anonymous functions and assigning them to a variable.

// Don't do this:
function getData() { }

// Do this instead:
var getData = function() { };

There are a number of good habits that are instilled when you use this
particular technique.

* Makes it easier to understand "functions as an object". I've found
that when you show new developers a function being assigned to a
variable it suddenly becomes much more obvious that a function is
actually an object and can be manipulated as such (and that a function
can be passed as an argument to another function). Thus students are
advanced along the path towards a better understanding of functional
programming.

* It enforces good semicolon habits. Traditional function declaration is
the only situation in which semicolons aren't needed (save for
conditional statements and loops, naturally) and it makes it much more
obvious when they're required all the time.

* Doesn't have much of the baggage traditionally associated with
functions and scope.

[...]
--
Ross McKay, Toronto, NSW Australia
"The chief cause of problems is solutions" -Eric Sevareid

Michael Haufe (TNO)

unread,
Jan 26, 2012, 8:34:33 PM1/26/12
to
On Jan 26, 6:45 pm, Ross McKay <au.org.zeta.at.ro...@invalid.invalid>
wrote:
> OK, this is different: apparently, the function declaration is now seen
> as an anti-pattern. This doesn't sit comfortably with me; can the
> resident experts please weigh in and discuss?

Ignore this non-sense.

The primary reason for writing the 2nd form originally was to avoid a
bug in IE.

Since they want to talk about "anti-pattern"s, they should probably
realize that "var" is an "anti-pattern" as well as it is function-
scoped instead of block scoped... the language committee is moving
slowly but steadily towards finally deprecating it.


> I can understand Resig's logic in better enabling students to come to
> grips with functions as first-class objects, but... an anti-pattern?

He can teach however he wants, but I do see this as an exaggeration at
best in teaching.

> As we've begun to look at the prospect of JavaScript-as-a-first-language
> a number of obvious warts stick out (as is obvious to anyone who has
> worked with JavaScript for any duration). To make sure that general
> warts don't crop up we will be using some form of linting (either JSLint
> or JSHint or similar) in the code editor to give the users contextual
> information on what's happening with their code and why they should be
> writing their code in a certain way.

So is the intent to teach programming, or to teach JavaScript? Warts
can be avoided by having a better curriculum, and telling students to
use a modern browser.

The second pattern is unnecessary if cutesy code tricks are avoided,
and since this is a "first-language", cutesy code tricks shouldn't
even be used in the first place.


> * Makes it easier to understand "functions as an object". I've found
> that when you show new developers a function being assigned to a
> variable it suddenly becomes much more obvious that a function is
> actually an object and can be manipulated as such (and that a function
> can be passed as an argument to another function). Thus students are
> advanced along the path towards a better understanding of functional
> programming.

Unless the function is being used as a static object, this lesson is
not helpful as a beginner. Instead focus on the difference between
these:

function add(x,y){
return x + y;
}

function Point(x,y){
this.x = x;
this.y
}

> * It enforces good semicolon habits. Traditional function declaration is
> the only situation in which semicolons aren't needed (save for
> conditional statements and loops, naturally) and it makes it much more
> obvious when they're required all the time.

I can't argue strongly one way or another on this....

> * Doesn't have much of the baggage traditionally associated with
> functions and scope.

Of course, let us not overlook the fact that the "pattern" and the
"anti-pattern" are semantically different:

var a = function(){}

a.name // ""

function a(){}

a.name // "a"

Michael Haufe (TNO)

unread,
Jan 26, 2012, 10:53:58 PM1/26/12
to
On Jan 26, 7:34 pm, "Michael Haufe (TNO)" <t...@thenewobjective.com>
wrote:
>
> function add(x,y){
>     return x + y;
>
> }
>
> function Point(x,y){
>     this.x = x;
>     this.y
>
> }

bug fix:

function add(x,y){
return x + y;
}

function Point(x,y){
this.x = x;
this.y = y;
}

John G Harris

unread,
Jan 27, 2012, 11:50:39 AM1/27/12
to
On Fri, 27 Jan 2012 at 11:45:25, in comp.lang.javascript, Ross McKay
wrote:
>OK, this is different: apparently, the function declaration is now seen
>as an anti-pattern. This doesn't sit comfortably with me; can the
>resident experts please weigh in and discuss?
>
>I can understand Resig's logic in better enabling students to come to
>grips with functions as first-class objects, but... an anti-pattern?

To be fair to Resig he suggests absolute beginners are best served by
using assignment of an expression, not that declarations are wrong.

Presumably declarations will be introduced later on, else the students
are going to get a horrible shock when moving to Java, and especially to
C++ with its function objects.

John
--
John Harris

Scott Sauyet

unread,
Jan 30, 2012, 4:29:56 PM1/30/12
to
Ross McKay wrote:
> OK, this is different: apparently, the function declaration is now seen
> as an anti-pattern.

Nonsense.

I do choose to use function expressions instead of function
declarations for similar reasons as Resig. There are a great number
of beginning and intermediate JS users who (unfortunately for them)
often use my code as samples of how to develop. So I tend to favor
consistency, and since I *need* function expressions but not function
declarations, I use the former everywhere.

But for systems where that level of consistency is not important, or
where function expressions are not needed, there is no reason to try
to force the function expression style on users.

-- Scott

Gene Wirchenko

unread,
Jan 30, 2012, 5:37:27 PM1/30/12
to
My, my! Someone not forcing his way down everyone else's throat?
I may faint.

Sincerely,

Gene Wirchenko

Hans-Georg Michna

unread,
Jan 31, 2012, 12:32:52 PM1/31/12
to
Yes, a truly notable exception! (:-)

Hans-Georg

Ross McKay

unread,
Feb 2, 2012, 12:20:48 AM2/2/12
to
Thanks for the responses on this, pretty much in line with what I
thought.

cheers,
Ross
--
Ross McKay, Toronto, NSW Australia
"The documentation and sample application having failed me,
I resort to thinking. This desperate tactic works, and I
resolve that problem and go on to the next"
- Michael Swaine, "Programming Paradigms", Dr Dobb's Journal

Matt McDonald

unread,
Feb 2, 2012, 10:25:07 AM2/2/12
to
On 12-01-26 05:45 PM, Ross McKay wrote:
> OK, this is different: apparently, the function declaration is now seen
> as an anti-pattern. This doesn't sit comfortably with me; can the
> resident experts please weigh in and discuss?
>
> I can understand Resig's logic in better enabling students to come to
> grips with functions as first-class objects, but... an anti-pattern?

John Resig is not to be trusted as a source of JavaScript
expertise. He is a charlatan of the highest order.

> Perhaps the most interesting change that we can make is a rather subtle
> one, but it's eschewing normal function declarations for creating
> anonymous functions and assigning them to a variable.
>
> // Don't do this:
> function getData() { }
>
> // Do this instead:
> var getData = function() { };
>
> There are a number of good habits that are instilled when you use this
> particular technique.
>
> [function as object, etc]

This is utter nonsense. When one reads jQuery code—typically
from beginners—a common observation is the utter abuse—and
nesting—of anonymous functions. Why? Resig and his acolytes
love the pattern. This anti-pattern is a positively terrible
way to develop an application.

> It enforces good semicolon habits. Traditional function declaration is
> the only situation in which semicolons aren't needed (save for
> conditional statements and loops, naturally) and it makes it much more
> obvious when they're required all the time.

Semicolons really aren't difficult to understand. Any
programmer that's worked in a C-type language (PHP et al.)
knows their importance. The real confusion comes from
people embracing ASI that flaunt their "knowledge"
of ECMAScript.

--
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

Michael Haufe (TNO)

unread,
Feb 2, 2012, 2:21:10 PM2/2/12
to
On Feb 2, 9:25 am, Matt McDonald <m...@fortybelow.ca> wrote:

> John Resig is not to be trusted as a source of JavaScript
> expertise. He is a charlatan of the highest order.

Never attribute to malice that which is adequately explained by
ignorance.
0 new messages