This is the last article in the code specification series. The first two articles talked about some points of attention, and the last article will add it again. Start.
Parameter verification
I think everyone is familiar with parameter verification. React and Vue can verify the parameters passed in by the parent component, and the parameters passed in can usually be performed in the function. Verification, of course, without verification, as long as the parameters are correct, there is no problem, but suppose we want to limit the types of parameters passed in, we still need to add parameter verification, at least it can make our program write more standardized, and Iterative development among colleagues can also get started faster.
Proactively throw errors
< span style="font-size: 18px;"> What does it mean to actively throw a mistake? Does it mean the same thing as active acknowledgment of the mistake? If you do something wrong, quickly admit it, in the code We can actively throw errors through throw. Some students here may ask, when the code makes a mistake, will the browser automatically throw an error? Why take off your pants and fart so much? Actually, the error of the browser may not be as detailed as our own definition. After all, you throw the error yourself, and throw whatever you want, so that once an error is thrown in the later code , You can quickly locate the cause of the problem.
we often use throw and try catch to throw Errors, and the common types of errors are nothing more than the following seven types
Error: the basic types of all errors
ReferenceError: Occurs when the expected object does not exist, such as when the variable is not defined and used directly
TypeError: thrown when the variable is not of the expected type, for example, a is a string, call a()
EvalError: thrown when an error occurs in the execution of the eval function, it is now very discouraged to use eval
SyntaxError: thrown when there is a syntax error in the code passed to eval
RangeError: thrown when the number exceeds its bounds. For example, creating an array with a length of -10 will throw this error, which is also very common in normal code. Rare
URIError: An error is thrown when an illegally formatted URI string is passed to functions such as encodeURI(), encodeURIComponent(), decodeURI() or decodeURIComponent()
The most common ones are ReferenceError and TypeError.
Separate configuration data
What is configuration data? In layman’s terms, is it the data you have hard-coded in the code, such as URL, reread value Wait, these values that we may change during the later maintenance and upgrade are all extracted and placed separately in an object or a unified file. When the later changes are made, there is no need to change in the code logic. You need to change the corresponding configuration items.
Self-cleansing
What is self-cleaning? Just take care of yourself, don’t mess with other people’s objects, and be the order It’s okay when people are developing, because all functions are well known, and it’s more troublesome when developing collaboratively. Why do we have to keep ourselves clean in collaborative development, because casual modification or overwriting methods can easily affect others, so we must be cautious when modifying or overwriting functions to prevent colleague’s part from falling apart. It’s really broken. You see if your colleague doesn’t stick it, and you’re done. When our own object does not want to be modified by others, we can use the following three schemes to protect him
Prevent extension: Object.preventExtension(object name) It is forbidden to add property methods to objects, but existing properties can be deleted or modified p>
Seal: Object.seal (object name) Similar to prevent expansion, but only attributes can be modified. Can’t delete
Freeze: Object.freeze( Object name) Similar to sealing, but it is forbidden to modify existing attributes and methods. Adding, deleting, and changing nothing
Notes
Comments are essential, of course if you The standard level of the code has reached a level that people can understand at a glance, and there is no need to write comments. Otherwise, please write the comment, and write the comment as much as possible in the key place. It is not necessary to have a comment on every line. You only need to indicate the operation of the function at the beginning of the function, or make a comment in a place that is not easy to understand.
The last big move, take my ESlint
This is really a big trick. Open ESLint and configure what space indentation, line break, etc. , As long as your writing does not conform to the specification, it will give you a warning. Good news, there are so many online tutorials on the specific configuration plan, just grab one and refer to it. After using it, you will find a beautiful code!
Dangdangdang , OK, I think about this for the time being about the knowledge of the code specification. If I find other things later, I will come back and continue to add it.