named
Take descriptive names
Naming needs to be descriptive, and descriptive information needs to be overlaid into the code. The reader will be able to see the name of the function and infer the general behavior of the function so that it’s a descriptive name.
Names should match the level of abstraction
The name needs to reflect the abstraction hierarchy of the class or function.
For example, if you have a function that connects to a modem, which is mostly dial-up connections, you might call it getConnectedPhoneNumber(). This may seem fine at first glance but in fact there are cases where the cable value is connected. The level of functionality is connected to the modem, and the choice of connection mode is a matter at the next level. So the more appropriate name is getConnectedLocator()
Use standard nomenclature whenever possible
It is easier to understand if there is an established convention or usage, such as a pattern, or a naming standard within a team that is part of a standard
Unambiguous name
Use unambiguous names. For example, the doRename function also has renamePage(), which is hard to know if you don’t know the business, So, in order to eliminate the ambiguity If not much this function is called Can be optimized by the method of a longer name Such as the doRename renamePageAndOptionallyAllReferences instead.
Choose a longer name for a larger scope
The length of the name should be related to the breadth of the role. You can use short names for smaller scopes and long names for larger scopes.
Variable names such as I are used for up to five lines, but if the function is long, a more meaningful name is preferred. Let’s say rollCount or something.
(I think the author here is mainly for the variable name, if it is the function name should be in accordance with the unambiguous name principle, theoretically should be the scope of the smaller the longer the name)
The name should indicate the side effect
Side effects refer to other logical effects of functions, such as the author’s getOos () example. This function does a non-null check, returns the value if it gets it, and creates an empty object if it doesn’t. The side effect here is to create a new empty object. The function name should be createOrReturnOos().
test
Lack of test
Tests should cover all areas, and all code and situations should be covered.
Using coverage Tools
Coverage tools can report gaps in your testing strategy. Coverage tools can be used to quickly find if or catch statements that have not been tested.
(Try Jtest for the front end)
Don’t skip the quiz
Small tests are simple and provide documentation value
A neglected test is a question about something that is uncertain
If the details of a requirement are uncertain, you can comment the test code to remind us that this part is uncertain.
Test boundary condition
Don’t forget to test for boundary conditions
Fully test for similar defects
If a function detects a bug, it is best to test the function thoroughly. Probably more than one. (Haha, this one is.)
The pattern of test failures is instructive
If you look at test failure cases, you may find some patterns, which can be instructive for locating and solving problems, so we need to write comprehensive test cases.
Tests should be fast
If the test is slow, it will not be easy to run and will be discarded over time. So you need to make test cases run faster.
(This is really important when testing the overall process. And you can only test some main processes for speed.)