What is the general and reasonable order of parameters for functions?

Question

Assuming all of them are required:

function search (haystack, needle) function search (needle, haystack) function placeObject (object, column, row) function placeObject (column, row, object) function newObject (parent, width, height, isVisible) function newObject (isVisible, width, height, parent) function newObject (width, height, isVisible, parent) 

I think that often this is a matter of personal choice, which should be consistent throughout the project. But I wonder if there is a deeper logic that will determine the order for each case.

Answer 1

Try making the intended call.

 function search (needle, haystack) 

Look for a needle in a haystack.

 function placeObject (object, column, row) 

Put the object in (column, row).

newObject is tough: try to keep it consistent with your wireframe structure, if any, set the general parameters first. I would put isVisible last only because it is logical, and from a Boolean literal it can be difficult to conclude what it does. With a few logical values, I prefer to combine them into an integer type flag object built using a bitmask (or a dictionary of key values ​​or a string depending on the language) for readability:

 openFile(path, READ | LOCKED | COMPRESSED | ...) 

Answer 2

I can think of several things, although none of them is a "rule". This is what is convenient for me.

• Sequence

  . If you have, for example, functions that copy objects, then they must correspond to the order in which the source and destination are indicated. You can use existing presets that people may have (for example, the operand order in the MOV assembler directive or the order arguments for the strcmp standard C library strcmp ).

• Grouping. It is useful to put things that are logically “grouped” together. for example, if your function opens a database connection, the username and password should be together (and probably in that order).

• readability. The "large" parameters by which operations occur must precede the smaller ones. e.g. draw_line(canvas, x0, y0, x1, y1) rather than draw_line(x0, y0, x1, y1, canvas) .

• It is also useful to think of a function as a prefix operator on its arguments, and then try to convert it to an infix to see what is natural.

If your language supports keyword arguments, it is usually recommended to use them (unless it is clear what arguments and order should be).

Answer 3

I have the feeling that ordinary logic is a function of time. You see, if you have a function:

 public Pizza makePizza(cheese, sauce){} 

And then you create a variable that determines the number of the vertex in the array:

 int toppingNo = 3; 

You probably want to send this to your function too, right?

 public Pizza makePizza(cheese, sauce, topping){} 

And now, my son, how parameters are born!

Sarcasm aside, that I always did this if you do not have parameters that obviously should be grouped due to their similarity, for example, a coordinate system.