Parameter order

https://softwareengineering.stackexchange.com/questions/101346/what-is-best-practice-on-ordering-parameters-in-a-function

 I don't over-think it, except for public API design.

Selection Funnel

1. Semantics
2. Importance / Relevance
3. Frequency of Use
4. I/O Concerns

1. Semantics First

Especially in OOP, pick parameters based on their semantical significance for the action or message. The signature of a well-named method with a well-named parameter should:

• feel natural to call,
• be self-descriptive in terms of intent and behavior.

(For these reasons, sometimes using custom types or aliases instead of primitives might increase the expressiveness of your signature.)

2. Then Importance

The most "significant" parameter comes first (or next...)

3. Then Frequency

The frequency matters as well, especially in a language where you don't have named parameters but can have default values on positional parameters. That implies that the order of the parameters doesn't vary, and that obviously you cannot set the N + 1 parameters if you want to force the default value of the Nth parameter (except if your language has a concept of a place-holder parameter).

The good news for you is that usually, frequency relates to importance, so that goes hand in hand with the previous point. And then it's probably up to you to craft your API for it to have the appropriate semantics.

4. Let's Not Forget I/O

if your method/function takes some input and produces an output, and the latter is not to be "returned" (via a return statement) or "thrown" (using an exception system), then you're left with the option to pass values back to the caller using your other parameters (or the input parameter). That relates to semantics, and in most cases it will make sense to have the first parameters define the output, and the last parameters receive the output.

Additionally, an other approach to have less parameters and maximise semantics would be to use a functional approach, or to define a Builder pattern, so you can clearly stack up your inputs, define your outputs, and retrieve them when need be.

https://stackoverflow.com/questions/2796557/conventions-for-order-of-parameters-in-a-function

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

 group arguments of similar origin together