0

I was recently changing a method to add in an additional parameter, and I couldn't help but wonder if there were "best practices" or "generally accepted rules" in deciding what order parameters of a method should go in? Obviously, you could put it in any order you like... I'm more wondering if there are any official (or unofficial) guidelines for this. My particular language is Java but I'm thinking this could apply to any language with arguments.

Example Parameter List:

public String generateMessage(Object o, String prefix, String suffix)
    //generates a message such as: "prefix : objectName : suffix"

I am adding a boolean, which is whether the prefix should be shown.

public String generateMessage(Object o, String prefix, boolean isPrefixVisible, String suffix)
Roman Mik
  • 131
  • 9
DoubleDouble
  • 603
  • 1
  • 5
  • 11
  • 1
    Well, if you are adding a parameter to a method that is already in use, you probably want to add it to the end so unupdated code isn't sending the old #3 to the new #3. – HamHamJ Oct 07 '14 at 18:19
  • In this specific case, don't add a boolean. Instead, don't show the prefix if it is `null`. Because a `String` is a reference type, you can have different behaviours for `null` and the null object `""`. – amon Oct 07 '14 at 18:27
  • one may argue that conceptually, this has been addressed in [How would you know if you've written readable and easily maintainable code?](http://programmers.stackexchange.com/a/141010/31260) If your peers keep complaining about your way of doing things, be it one way or another, you better change to make them feel better – gnat Oct 07 '14 at 19:08
  • @amon Unfortunately, for this case, there could still be a prefix even if I don't want to show it. Thanks for the idea though. – DoubleDouble Oct 07 '14 at 19:36
  • @gnat I see what you are getting at. It's not so much that peers are complaining about how I do things, as it is about me wanting to write the cleanest code possible. For my group, I doubt something as small as the order of my parameters would ever come up during a code review. – DoubleDouble Oct 07 '14 at 19:46
  • 1
    I think, in this particular example, the best order would be: object, boolean, prefix, suffix. The prefix and suffix are the same type and quite similar in meaning, so they should go together, and the prefix and the boolean modifying the prefix are related and should go together as well. However, the amount of clarity gained here is very small. A 4-element parameter list is just not complicated enough to be confusing. – Michael Shaw Oct 07 '14 at 20:10
  • In this particular case, I personally would encapsulate all parameters into a single object (MessageInfo for example). 3 arguments is pushing it in my book, not to mention the 4th one. Also, this function looks like it has a potential to grow with more arguments in the future, so that's another reason for combining all of them into a single object. – Eternal21 Oct 07 '14 at 20:49

1 Answers1

4

This question is highly subjective.

In my experience, I have found that parameter lists are clear when they meet the following criteria:

  • The primary object upon which the method or function operates comes first. In English, a sentence might contain a noun, a verb, and another noun upon which the verb could act. E.g.: "Alice sends a message." In OO parlance, "Alice" could be the object to which the method belongs. "Sends" could be the method itself, and "a message" is its parameter: alice.sends(message). Maybe there are other parameters, but they should read roughly like a sentence: "Alice sends a message, but gives up after 30 seconds if nobody listens." alice.sends(message, 30). It is natural, our brains are already trained to think this way from an early age.

  • If there are more than (insert subjective number here, maybe four or five) parameters, break up the method call somehow. Maybe there is an object (e.g. builder) screaming to be refactored out. If a parameter list is long enough that you have to ask this question, it is already long enough to be difficult to understand.