Number of arguments in methods. OOP?

Question

Programming

Good day.
Re-reading Robert Martin's book, Clean Code, I found some very interesting advice related to the number of arguments in methods.
It all boils down to writing methods with only 1 (unary), 2 (binary) and 3 (ternary) arguments (well, no arguments too).
Anything more needs to be cut off, and it is very rare to write ternary functions.
The first thing I did after reading this was to look at my code (lots of PHP :) ), and naturally I found multiple non-compliance with this rule.
Like any good programmer, I want to write good code, and not having found enough information on this issue, I would like to know the opinion of other programmers.
Questions:
1. Do you follow Martin's advice on the number of arguments in methods?
2. Have you had problems or just wasted time with this problem?
3. When refactoring tests, is increasing the number of arguments a problem for you?
And I would like to hear just an opinion, to learn about someone else's experience.
Thank you for your attention.

Answer 1

Following the Single Responsibility principle (invented by Robert Martin, by the way) when describing methods, the number of arguments really rarely exceeds 1.
In general, when reading such books, one should always pay attention to what is written in small print (usually under a loud title). I think, having written a whole book of advice about programming, Martin should have explained why he gives such advice.

Answer 2

In most cases, yes, but there are methods that take 4-5 arguments, and I don't see anything wrong with that.
All such rules are actually recommendations that cannot be followed by turning off your own logic and common sense.

Answer 3

Interestingly, the authors of all these books really think that the number of arguments in methods and other attributes of “good code” have at least something to do with the quality of the final product?

Answer 4

1. Yes. The exception is constructors.
2. Of course - the more arguments, the more difficult it is to refactor the use of this method. It grows exponentially.
3. Yes
If the method has 1-2 arguments, its purpose can be fully described by its name so that it is clear from the name what needs to be passed to it and how it will be used. For example: sendEmail(email), setPasswordForUser(password, user). And code readability is a very, very important factor.

Answer 5

If you follow this rule when creating wrappers for variables of the same type (for example, Point), leave the function with the original set of parameters. It's very common to see things like
setPlayerCoord(new Point(1, 2, 3));

Answer 6

My main rule is that the method should be scattered as little as possible: perform an explicit task. With this approach, the number of arguments will definitely not exceed the maximum according to Martin.
And yes, what about an array that passes for one argument with a bunch of values?

Answer 7

One type of code with a large number of arguments is getting data from a database. In it, you can see in practice why a large number of arguments is bad.
habrahabr.ru/post/154245/#comment_5254885

//Get record
abstract public function getRecords($what='*',$where=NULL, $limit=NULL, $order=NULL,$join=NULL,$debug=false);
the fun begins when we sort more often than we limit and decide to swap the $limit and $order parameters. or when we decide to add another parameter that comes after $debug. or when we decide to remake the list of parameters into a parameter in the form of an array. or when...

Answer 8

When reading this book, keep in mind that it is written for an object-oriented programming language. In OOP, data can be passed in the constructor, setter, and methods themselves. Those. method arguments refer directly to the method. If there are many arguments, then they can be combined into some class of the <businessmethod> type.

Answer 9

1. I definitely comply. Compliance is faster and more convenient.
2. No. Time savings happened.
3. When refactoring, it decreases (due to improved code quality).