Conventions for order of parameters in a function

Question

In writing functions my brain always spends a few milliseconds to check which order of parameters would be best for a given function.

should I write:

    public Comment AddComment(long userID, string title, string text)

Or probably:

    public Comment AddComment(string title, string text, long userID)

Why not:

    public Comment AddComment(string title, long userID, string text)

Do you follow any rules when ordering the parameters for your functions? Which parameter would you place first and which would follow?

Answer 1

Personally, I'd do the first one because that's exactly the order I would have in the GUI: User, Title, Text.

But as David said, this is very open ended. If my project standards required a special order I would use that.

Answer 2

There are only 3 rules I usually apply:

• If a language allows passing a hash/map/associative array as a single parameter, try to opt for passing that. This is especially useful for methods with >=3 parameters, ESPECIALLY when those same parameters will be passed to nested function calls.

  This allows for easier maintenance - adding another parameter (especially when that same list of parameters is passed between 10-level-deep nested function calls) involves changing 1 place in the code (the ultimate caller) instead of EVERY single function which takes that list and passes it on elsewhere.

  This has a minor drawback of no type checking in languages like C++ (e.g. your compiler can't check whether the hash/map contains correct types of values in it for expected types of keys) - if that's a concern, you can encapsulate that parameter map as a struct/class instead.

• If a language allows default values for parameters (such as C++, Sybase stored procedures), you obviously leave the optional parameters to be the last, and the less likely the parameter is to be specified with a value, the later in the list it should go.

• Otherwise, order them in whatever logical grouping is most readable/maintainable.

  This may be a bit subjective - e.g. next/previous weight/height can be ordered next_weight,next_height, prev_weight, prev_height or next_weight, prev_weight, next_height, prev_height equally validly. Again, the 3 main considerations are readability/logicaleness for you, and ease of maintenance.

  As far as readability, you can order them by type, or by meaning.

  As far as "logicalness", you can order them by meaning (e.g. group all "next" together, or all heights together), OR by some order imposed elsewhere - for example, column order in a corresponding database table, or field order in a GUI (worse, as it's likely to change).

  As far as maintenance, if no obvious meaningful order crystallizes, alphanumeric order is the best since it allows VERY easy way to find a parameter by scanning and especially to decide where to insert a new parameter.