Should our team order Javascript class methods/properties consistently? If so, how?

Question

As our team is growing I've noticed that different developers put their class methods in different orders. For instance:

var Foo = Backbone.Model.extend({
    someVar: {},

    initialize: function() {...},

    fetch: function() {...},
    handleFetchRepsonse: function() {...},

    getFoo: function() {...},

    render: function() {...},
    renderFoo: function() {...},
});

vs.

var Foo = Backbone.Model.extend({
    fetch: function() {...},
    getFoo: function() {...},
    handleFetchResponse: function() {...},
    initialize: function() {...},
    render: function() {...},
    renderFoo: function() {...},
    someVar: {},
});

It seems like it'd be more convenient if everyone used roughly the same criteria when they order their methods (if for no other reason than to make it easier to find stuff). However, I'm wondering if:

A) that is even possible/realistic (or should I simply accept the fact that everyone is going to have a different order)?

B) if so, what sort of ordering should that be (the only really consistent one I can think of is alphabetical, but that seems less than ideal)?

Answer 1

Everyone will have their own different preferred standard, but it's important for everyone to put their ego aside for the betterment of the team and stick with a consistent standard.

Code reviews are a good way to enforce a coding standard.

What the specifics of the coding standard are up to you and your team. Different teams have different requirements and will be optimized with different standards.

It's important to focus on what you're trying to achieve before deciding on a coding standard.

My team needs to be able to write code quickly and integrate with many large inherited code bases of varying degrees of quality. Our job is usually about implementing new features or extending existing ones. This means we need to write code quickly and have it be easy for anyone else on the team be able to pick it up and run with it.

Because of those requirements our code standard focuses on readability on the small scale. Code we write should generally be short and to the point, and organized in a way that can easily be searched. As we tend to have a moderate number of interns, it's also important that we can train them quickly.

This means we've picked alphabetical ordering because it's faster to teach and reasonably fast to write.

If your requirements are different, such as long-term maintenance with a team of more experienced developers, I'd recommend a structure that's comfortable to work in. An example might be:

For function bodies:

• directives
• var declarations
• function declarations
• variable initialization
• main execution

For prototypes:

• initialization methods
• API methods
• event handlers
• pseudo-private methods
• etc...

Again, the specifics of the order should be determined by your team with emphasis on improving the performance of the team overall. Some teams work great when they don't have to work with any formal standard, and others can't work without a well-documented rigorously enforced standard.

Answer 2

It's a matter of team policy, just like naming conventions. It is a good idea to have an accepted order for the sake of readability, so long as most people follow it.

As you say, there are a couple of options:

• No order at all.
• Properties, methods, and fields grouped by subject (thing, readThing, writeThing, deleteThing...)
• Members grouped by behavior (thingA, thingB, readThingA, readThingB, writeThingA, writeThingB)
• And so on...

Before you agree on any policy, make sure that the expectation of how to follow it is clear.

Answer 3

I don't think it would work. You'd have to define was the order was, and that definition would have to be unambiguous, and it would also have to include a naming standard that defines the name for every possible function because maybe "relaxGraphNodes()" shouldn't go in the same place as "evenOutPointSet()".

It'd be an immense investment... the one group I've seen do something similar was the Microsoft Office dev team, and it took them years to work it all out and they ended up with a hundred-some-page-long standards document.

Answer 4

I always order methods based on their role, critical (usually small) methods on the bottom, methods that apply the prior methods on top. Don't order them alphabetically, that will you will fade clues that reveal the consistency of the code, this is necessary when you need to refactor the code.