1

In some languages such as Python, the order of keyword arguments in function calls does not matter. But is there a best practice for it?

For instance, suppose that a function's signature is def foo(bar, baz, qux).

foo(bar=3, baz=8, qux=9) is of course the same as foo(qux=9, bar=3, baz=8). But isn't the former easier to read for someone who is referring to the documentation at the same time?

Similarly, suppose that a program includes two calls to function foo.

First version

foo(qux=10, bar=9, baz=8)
# (...)
foo(baz=8, qux=10, bar=8)

Here we can see that the only difference between the two call is the value of bar, but it takes a split of a second to realize it.

Second version

foo(bar=9, baz=8, qux=10)
# (...)
foo(bar=8, baz=8, qux=10)

Here, in my opinion, it's easier to compare the two calls.

Hence, I would be tempted to say that it is generally better to write the function arguments in the exact same order as in the signature. However I cannot find any reference for that, nor any rules in common linters such as pylint or flake8.

I agree that it is really a detail, but as it is often said that code is read much more often than it is written, wouldn't it be interesting to encourage using such a convention in a project? The function calls could, of course, be autofixed by a formatting tool.

4
  • Is this a question that is rooted in the absence of a good reason to do this being used as the "proof" that it's therefore a bad thing to do? Or is there something that actively argues why it should never be done?
    – Flater
    Apr 18, 2023 at 1:39
  • @Flater For me keeping a standard order for the named arguments looks like a reasonable thing to do, but I'm surprised to see that it isn't recommended anywhere, so I'm just trying to figure out if there is a compelling reason against it that I would have missed.
    – Scarabee
    Apr 18, 2023 at 9:13
  • @Scarabee, I think it's just considered too obscure and low-stakes for anyone to have remarked upon - until now, at least.
    – Steve
    Apr 18, 2023 at 17:29
  • 1
    @Scarabee: I think it makes sense to keep all the plates in my house in the same stack in a kitchen cupboard, but I have yet to see explicit documentation that I shouldn't store my plates by spreading them out across different rooms. The absence of advice is not the same as intentional confirmation of the opposite.
    – Flater
    Apr 18, 2023 at 22:45

2 Answers 2

2

It would certainly seem like a poor practice to call the same method in the same context, and with the same named arguments, but with a different ordering of named arguments for each call.

And assuming the developer of the method put the slightest thought into the default ordering of parameters, it makes sense to accord with this default order, if there is no strong reason to deviate.

I would argue that named arguments exist primarily to increase the explicitness of code (especially when dealing with methods taking several or more parameters), and to allow optional parameters to be skipped/omitted by leaving their names absent. These two needs/benefits are primarily what justify the existence of the syntax of named arguments.

The ability to actually reorder arguments by stating their names in a different order is, in my view, a byproduct feature, and would be used only rarely.

In those rare cases, I suspect the method being called would be regarded as having some design deficiency - either having an illogical default ordering of arguments, or having such diverse possibilities to include and combine optional arguments together that no one default ordering could seem logical for all uses.

I suspect parameters are more often reordered in ignorance rather than intentionally, either as a consequence of the programmer not knowing the default order, or as a consequence of adding an additional optional argument later which ends up being incorporated in arbitrary order.

1

Name arguments are a feature of many programming languages. Indeed, there are no commonly accepted guidelines determining the order a caller specifies these arguments. This is a matter of personal taste. Your team might have guidelines, but these won't be backed by any industry "best practice" or policy.

The primary benefit of named arguments is readability. Even the notion of "readability" is subjective. If the code is hard to understand, then pointing out the argument order in a code review is justified, but not mandatory.

Bottom line: you won't get consensus from your team — much less the rest of the software development industry — on a recommended order for arguments in languages where named arguments are supported.

4
  • Thanks for the answer! Could you elaborate on why there are no guidelines on this? There are widely known guidelines about subjects such as final newlines, trailing whitespaces, ordering of imports...
    – Scarabee
    Apr 18, 2023 at 16:12
  • @Scarabee: There are no guidelines on this because nobody can come to a consensus. And nobody can come to a consensus, because this is up to personal taste. This is determined by personal taste, because we all cannot agree on one way that is more beneficial than the rest, which brings me back to "nobody can come to a consensus." :) Apr 18, 2023 at 17:10
  • As for newlines and trailing white spaces, guidelines might be specific for a language, but across the IT industry you won't find consensus. Ordering of imports? Again, a specific language might make some recommendations, but many times they recommend something so people stop asking them which order their imports should appear in (unless there is a technical reason). Apr 18, 2023 at 17:12
  • 1
    In Objective C and Swift the argument names are part of the function signature, so the order in a call is fixed. Swift becomes interesting when you put default arguments into the mix and have functions with similar signatures.
    – gnasher729
    Apr 18, 2023 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.