current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 0 down vote favorite

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)
share|improve this question

closed as primarily opinion-based by gnat, MichaelT, Bart van Ingen Schenau, Kilian Foth, Dan Pichelman Oct 9 '14 at 0:43

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
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 7 '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 7 '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? 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 7 '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 7 '14 at 19:36
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 7 '14 at 20:10

1 Answer 1

up vote 4 down vote accepted

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.

share|improve this answer

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