What is a good function, or method, as long as the function clearly expresses its intention, so that the reader can see at a glance what kind of function it is, what parameters it takes, what results it returns, and what it does. If you can do that, that’s probably a good function, so it looks pretty simple. So the question is, what if you do that?
1. Short
Think of a complex function that beats navigation or a function that has only a dozen lines. Which one is more likely to make the intent and behavior visible at a glance? Clearly the latter. Of course, most languages today can fit hundreds of lines of code into a single line, so unformatted code would just be hard to understand.
2. Code blocks and indentation
For if, else, etc., it is best to contain a single line of code, which should be a function call so that the reader can see the intent
3. The function name
A good function name is very important, how to define a good function name? You can. A function is a good function name if you can just look at its name and see what it does and what it returns.
4. Do only one thing
A function should only do one thing, and do it well enough. We all admit this, and it is already a consensus, but it is easy to say, but it is not so easy to do. So how do you make sure that the function only does one thing? We can try to separate a function from a function. Of course, the separated function can’t just carry the code over, it should have its own responsibility to give the new function a good name. If you can’t pull out a function like this, then he should be able to.
5. Function parameters
The optimal number of arguments is 0, then increasing, so 3 arguments is a lot.
As far as function testing is concerned, function testing without parameters is a piece of cake. Once you have one parameter, you need to test many combinations, and with each additional parameter, the number of combinations tested grows exponentially.
As far as the caller is concerned, a function with no parameters can be called directly, while having parameters requires understanding what each parameter is, which also increases the caller’s time.
If a function argument has a Boolean value, sorry, this is not recommended, because it explicitly tells the caller to do so if true and to do so if false. It’s better to split it into two functions.
Also, if a function requires more than three arguments, consider wrapping some of those arguments into classes. Like x, y, cartesian coordinates.
6. No side effects
A side effect is a lie about a function whose name promises to do just that, but which secretly does something else.
For example, a function called checkOrderStatus obviously checks the status of an order, but if it changes the status while checking it, it can be confusing and you won’t even click on such a function when checking for errors. It’s better to split it into two functions.
7. One level of abstraction per function
It’s easy to say that when we read code, we tend to look at it from the top down, and if each function only deals with its own level of logic, it’s comfortable to read and maintain.
This makes sense to me, but I don’t get it.
. , etc.
So the question is, how do you write code that conforms to this specification?
In fact, there is no need to write in accordance with the rules at the beginning of writing, as it is easy to upset the train of thought, or even half the effort. You can come back after you’ve written it and polish it, disassemble functions, change names, eliminate duplicate code, and so on.