Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #10622 > unrolled thread

Function Declaration as anti-pattern?

Back to article view | Back to comp.lang.javascript

Contents

  Function Declaration as anti-pattern? Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-01-27 11:45 +1100
    Re: Function Declaration as anti-pattern? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-01-26 17:34 -0800
      Re: Function Declaration as anti-pattern? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-01-26 19:53 -0800
    Re: Function Declaration as anti-pattern? John G Harris <john@nospam.demon.co.uk> - 2012-01-27 16:50 +0000
    Re: Function Declaration as anti-pattern? Scott Sauyet <scott.sauyet@gmail.com> - 2012-01-30 13:29 -0800
      Re: Function Declaration as anti-pattern? Gene Wirchenko <genew@ocis.net> - 2012-01-30 14:37 -0800
        Re: Function Declaration as anti-pattern? Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-01-31 18:32 +0100
    Re: Function Declaration as anti-pattern? Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-02-02 16:20 +1100
    Re: Function Declaration as anti-pattern? Matt McDonald <matt@fortybelow.ca> - 2012-02-02 08:25 -0700
      Re: Function Declaration as anti-pattern? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-02-02 11:21 -0800

#10622 — Function Declaration as anti-pattern?

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

[toc] | [next] | [standalone]

#10623

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"

[toc] | [prev] | [next] | [standalone]

#10628

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;
}

[toc] | [prev] | [next] | [standalone]

#10648

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

[toc] | [prev] | [next] | [standalone]

#10804

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

[toc] | [prev] | [next] | [standalone]

#10805

On Mon, 30 Jan 2012 13:29:56 -0800 (PST), Scott Sauyet
<scott.sauyet@gmail.com> wrote:

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

     My, my!  Someone not forcing his way down everyone else's throat?
I may faint.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#10896

On Mon, 30 Jan 2012 14:37:27 -0800, Gene Wirchenko wrote:

>On Mon, 30 Jan 2012 13:29:56 -0800 (PST), Scott Sauyet
><scott.sauyet@gmail.com> wrote:

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

>     My, my!  Someone not forcing his way down everyone else's throat?
>I may faint.

Yes, a truly notable exception! (:-)

Hans-Georg

[toc] | [prev] | [next] | [standalone]

#11002

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

[toc] | [prev] | [next] | [standalone]

#11143

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

[toc] | [prev] | [next] | [standalone]

#11214

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web