Naming conventions
The length of the name should correspond to its scope size. For example, a static method that can be used anywhere or a static variable name can be longer. Some functions use internal variables with shorter names. If it is some variables to be used in the loop, you can simply use a letter to represent, ** but try not to use the letter E, because the letter E is the most commonly used letter in English, it will be troublesome to search.
The function definitions
Switch statements with more than three cases are best optimized using policy mode. The function should be as short as possible. In particular, a function with no more than three parameters is difficult to understand. Consider merging several parameters into one.
Do not define functions that have side effects
This is an example of how not to use a function that checks for a valid password to hide the logic of session init. The side effects of this function are enormous. Because most people don’t check the implementation of every function when the version is iterated quickly.
I’ve been cheated by a similar function myself.
So the best thing to do when you’re defining functions is to keep your responsibilities simple. Do only the things you name and don’t do too many things.
Use exceptions instead of error codes
Error codes work well in a single layer of logic, but once you get to multiple layers of logic the error code becomes a nuisance, difficult to use and difficult to maintain.
Such as:
Such code is expensive to maintain. This is especially true for form input validation, or for cascading CRUD.
Let’s do it a different way
Do not use enum for error codes
Such as:
This error code is problematic, and modules that rely on it will have to be recompiled each time the class is upgraded. The coupling is too high. In fact, you can use a custom exception. Future updates are as long as the extends old exception produces a new one.
Insist on maintaining comments
This is very important, I believe you have experienced, when maintaining some old code often encounter code comments and the meaning of the code itself is completely different. So it’s highly recommended that you stick with comments. When code changes, regardless of whether the previous code was written or not, this change should be modified as much as possible. Otherwise, the maintenance of future generations is very unfavorable.
In addition, you should not write the corresponding function or class badly just because you have written a comment. I find that many people have an idea that I have written a comment, so this function no matter how complex it is, it is reasonable. This idea is wrong.
Keep the DTO clean
As many of you already know, dtos should not contain any business logic.
Do not return null
At no time should we write a function that returns a null value, as this increases the probability of a crash. Especially in the case of returning lists, if no data is found, return a list with no data rather than returning null.
Time checks whether the function’s input parameter is null
When writing a public function, always check that the function argument is null, because you can’t be sure how someone will call your function. However, it is recommended that you do not pass NULL as an argument unless necessary.
Masking timing coupling
This principle was only recently understood after an online glitch was triggered. Sometimes we do things with timing, like cooking. He always followed the five basic steps of buying, washing, cutting, firing and frying.
Suppose your function is written like this:
This is actually very difficult to see they are dependent on the relationship between superiors and subordinates, maintenance in case of breaking this relationship is easy to malfunction. For this strongly dependent order, we can actually rely on the return value to concatenate them.
Such as:
So that each step depends on the return value of the previous step can explicitly bind the dependency.