To check the practice of parameter counts, we collected OSS projects, and counted the number of parameters for each method, function and closure that we could analyze with Exakat. We only took into account arguments that were explicitly defined. It is interesting to see that most methods take at least one parameter. In a way, a method without parameter has less use than a method with parameters. First, there is a category of methods that are database access.
They may be created automatically, like this one:. Note the total absence of typehint, and the consistence of the naming scheme: this was generated from the database model. Other long list of arguments are needed to handle dependency injection. This is the case for constructor, and they are easy to spot: they make systematic usage of Typehint. Those are usually handcrafted. Passionate about React, Node and writing clean and maintainable JavaScript. Uses linters currently ESLint every day to help achieve this.
This project is supported by orangejellyfish , a London-based consultancy with a passion for JavaScript. Please consider donating to help us continue writing and improving these articles. This function has too many parameters. When do I get this error? Why is the student name and ID in this method? What does that have to do with the function of calculating tuition? Can a student's tuition vary based on their name? Or is the method doing too much?
Undoubtedly we'll find if statements or switch statements based on them. We may find a long method with a lot of branches that are difficult to understand, and therefore difficult to maintain. Here we have a method that prints out a student's schedule. There are only six parameters.
Is that too many? Certainly, some developers would say no. But if you have an eye for code smells, and a low tolerance for long parameter lists, you may say "anything over four is a code smell" and so when you see six, you look deeper. In this case this parameter list may indicate a problem in the code. Look at the first three parameters: the student's first name, last name, and ID. They are all related. If we need those three pieces of information about the student, it could be likely that we will soon need another piece of information, and then end up adding another parameter.
Maybe we started with just the student ID, then later added the last name, and then finally in a different change, we added the first name. Each time it was natural to just add one more parameter. Our code slowly grew from a beautifully crafted piece of art into a hodgepodge of changes. Maybe when we investigate the implementation we don't find a problem. But if we investigate when we see these code smells, we may find trouble brewing.
Code smells are often related to each other. A keen "nose" helps us keep our application from growing into an unmaintainable mess. Contrary to some funny Dilbert cartoons, coding up a mess of spaghetti code that nobody else can decipher is NOT job security. Writing code that is easy to change is the best way to job security.
I've never seen a guideline, but in my experience a function that takes more than three or four parameters indicates one of two problems:. It's difficult to tell what you're looking at without more information. Chances are the refactoring you need to do is split the function into smaller functions which are called from the parent depending on those flags that are currently being passed to the function.
According to "Clean Code: A Handbook of Agile Software Craftsmanship", zero is the ideal, one or two are acceptable, three in special cases and four or more, never! The ideal number of arguments for a function is zero niladic. Next comes one monadic , followed closely by two dyadic. Three arguments triadic should be avoided where possible. In this book there is a chapter talking only about functions where parameters are large discussed, so I think this book can be a good guideline of how much parameters you need.
In my personal opinion, one parameter is better than no one because I think is more clear what is going on. As example, in my opinion the second choice is better because is more clear what the method is processing:. If the domain classes in the application are designed correctly, the number of parameters that we pass into a function will be automatically reduced - because the classes know how to do their job and they have enough data to do their work. For example, say you have a manager class which asks a 3rd grade class to complete the assignments.
The correct model always reduces the function parameters between the method calls as the correct functions are delegated to their own classes Single responsibility and they have enough data to do their work.
Whenever I see the number of parameters increasing, I check my model to see if I designed my application model correctly. There are some exceptions though: When I need to create a transfer object or config objects, I will use a builder pattern to produce small built objects first before constructing a big config object.
When a function call is made in ARM for instance, the first four arguments are placed in registers r0 to r3 and remaining arguments have to be pushed onto the stack. Keeping the number of arguments below five can make quite a difference for critical functions. For functions that are called extremely often, even the fact that the program has to set up the arguments before each call can affect performance r0 to r3 may be overwritten by the called function and will have to be replaced before the next call so in that regard zero arguments are best.
KjMag brings up the interesting topic of inlining. Inlining will in some ways mitigate this since it will allow the compiler to perform the same optimizations that you would be able to do if writing in pure assembly. When the parameter list grows to more than five, consider defining a "context" structure or object. This is basically just a structure that holds all the optional parameters with some sensible defaults set.
In the C procedural world a plain structure would do. Don't mess with getters or setters because the sole purpose of the object is to hold "public"ly settable values. Personally, more than 2 is where my code smell alarm triggers. When you consider functions to be operations that is, a translation from input to output , it is uncommon that more than 2 parameters are used in an operation.
Procedures that is a series of steps to achieve a goal will take more inputs and are sometimes the best approach, but in most languages these days should not be the norm. But again, that's the guideline rather than a rule.
I often have functions that take more than two parameters due to unusual circumstances or ease of use. If you take a look at jQuery's ajax class there are a lot approximately 30 more properties that can be set; mostly because ajax communications are very complex.
Fortunately, the object literal syntax makes life easy. C intellisense provides active documentation of parameters so it's not uncommon to see very complex arrangements of overloaded methods. I prefer object literal definitions even in C for managing complex methods because you can explicitly see which properties are being set when an object is instantiated. You'll have to do a little more work to handle default arguments but in the long run your code will be a lot more readable.
With object literal definitions you can break your dependence on documentation to understand what your code is doing at first glance. Note: If I remember right readonly access control should work for object literal constructors in C.
They essentially work the same as setting properties in the constructor. It can be an enlightening experience. I probably should have provided examples to demonstrate use in a statically typed language but I'm not currently thinking in a statically typed context.
Basically, I've been doing too much work in a dynamically typed context to suddenly switch back. What I do know is object literal definition syntax is completely possible in statically typed languages at least in C and Java because I have used them before.
In statically typed languages they're called 'Object Initializers'. Here are some links to show their use in Java and C. Very much like Evan Plaice is saying, I'm a huge fan of simply passing associative arrays or your language's comparable data structure into functions whenever possible.
Wordpress does a lot of stuff this way, and I think it works well. Though my example code above is imaginary, and is not itself an example from Wordpress. This technique allows you to pass a lot of data into your functions easily, yet frees you from having to remember the order in which each must be passed.
You'll also appreciate this technique when comes time to refactor - instead of having to potentially change the order of a function's arguments such as when you realize you need to pass Yet Another Argument , you don't need to change your functions's parameter list at all. Not only does this spare you from having to re-write your function definition - it spares you from having to change the order of arguments each time the function is invoked.
That's a huge win. A previous answer mentioned a reliable author who stated that the less parameters your functions have, the better you are doing.
The answer did not explain why but the books explains it, and here are two of the most convincing reasons as why you need to adopt this philosophy and with which I personally agree with:. Parameters belong to a level of abstraction which is different from that of the function. This means the reader of your code will have to think about the nature and the purpose of the parameters of your functions: this thinking is "lower level" than that of the name and the purpose of their corresponding functions.
The second reason to have as less parameters as possible to a function is testing: for example, if you have a function with 10 parameters, think about how many combinations of parameters you have to cover all the test cases for, for instance, a unit test. To provide some more context around the advice for the ideal number of function arguments being zero in Robert Martin's "Clean Code: A Handbook of Agile Software Craftsmanship", the author says the following as one of his points:.
Arguments are hard.
0コメント