Function Declaration as anti-pattern?

Discussion in 'Javascript' started by Ross McKay, Jan 27, 2012.

  1. Ross McKay

    Ross McKay Guest

    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
     
    Ross McKay, Jan 27, 2012
    #1
    1. Advertisements

  2. On Jan 26, 6: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?


    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), Jan 27, 2012
    #2
    1. Advertisements

  3. On Jan 26, 7:34 pm, "Michael Haufe (TNO)" <>
    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;
    }
     
    Michael Haufe (TNO), Jan 27, 2012
    #3
  4. 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
     
    John G Harris, Jan 27, 2012
    #4
  5. Ross McKay

    Scott Sauyet Guest

    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
     
    Scott Sauyet, Jan 30, 2012
    #5
  6. On Mon, 30 Jan 2012 13:29:56 -0800 (PST), Scott Sauyet
    <> 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
     
    Gene Wirchenko, Jan 30, 2012
    #6
  7. On Mon, 30 Jan 2012 14:37:27 -0800, Gene Wirchenko wrote:

    >On Mon, 30 Jan 2012 13:29:56 -0800 (PST), Scott Sauyet
    ><> 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
     
    Hans-Georg Michna, Jan 31, 2012
    #7
  8. Ross McKay

    Ross McKay Guest

    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
     
    Ross McKay, Feb 2, 2012
    #8
  9. 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
     
    Matt McDonald, Feb 2, 2012
    #9
    1. Advertisements

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
  1. Antti S. Brax

    Name that anti-pattern

    Antti S. Brax, Sep 29, 2005, in forum: Java
    Replies:
    15
    Views:
    1,196
    Chris Smith
    Sep 30, 2005
  2. Ovidesvideo
    Replies:
    4
    Views:
    845
    Andrey Tarasevich
    Dec 10, 2004
  3. pratham

    is PetShop 2.0 Anti pattern?

    pratham, Aug 31, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    620
    Juan T. Llibre
    Sep 3, 2006
  4. Replies:
    4
    Views:
    1,432
    Richard Tobin
    Dec 12, 2006
  5. Bolin
    Replies:
    4
    Views:
    615
  6. Demian Brecht

    Are ABCs an anti-pattern?

    Demian Brecht, Oct 2, 2012, in forum: Python
    Replies:
    0
    Views:
    335
    Demian Brecht
    Oct 2, 2012
  7. Steven D'Aprano

    object.enable() anti-pattern

    Steven D'Aprano, May 8, 2013, in forum: Python
    Replies:
    74
    Views:
    852
    Wayne Werner
    May 13, 2013
Loading...