Preface
In actual work, we should often see some codes that have no functional problems but have very bad coding style and specifications, which often make people dare not read further and may even affect the readers' mood for the whole day. These codes are not only difficult to read, but also difficult to maintain. They usually come from new programming newcomers and from old programmers who have worked for several years. Therefore, the purpose of this article is to help JavaScript learners who do not develop a good coding style and lack the corresponding coding norm awareness to improve their coding image.
Encoding image
I have proposed the concept of coding images above, and I personally believe:
Coding image = Coding style + Coding specifications
A good coding image is equivalent to a well-dressed young man. For programmers, this is the most direct and easiest way for peers to understand your excellent abilities.
Let's take a look at a bad coding image:
// Say hellofunction func(){
var age=18,sex='man';
var greeting='hello';
if(age<=18&&sex=='man'){
(greeting+'little boy')
}
...
}
func()
The above codes are all huddled together, lacking standard awareness, and the reading experience is very poor, so I can't bear to look at them directly.
Let’s take a look at a good code image:
// Say hellofunction greetFn() {
var age = 18,
sex = 'man',
greeting = 'hello';
if (age <= 18 && sex === 'man') {
(greeting + 'little boy');
}
...
};
greetFn();
Does the code above feel much more comfortable?
It can be seen that it is crucial to develop a good coding image, and this article mainly explains the encoding image based on JavaScript, that is, the encoding style and coding specifications based on JavaScript.
So what is the encoding style, what is the encoding specification, and what is the difference between the two?
Coding style
First of all, since the coding style is style, there is no right or wrong. It’s like everyone’s dresses differently. Some people wear more appropriately, while others wear more casually.
In the JavaScript coding style, there is also a more appropriate style, especially in team development, we cannot write our own style at will.
Below are a few random coding styles and compare them with good coding styles.
1. Reasonable comments
// Not recommended writingvar name = 'Laobu';//There is no interval between the code and the comment
if (name) {
/*
*No empty lines before comment
*No space behind the asterisk
*/
}
// Recommended writingvar name = 'Laobu'; // There is a spacing between code and comments
if (name) {
/*
* There are empty lines before comments
* There is a space behind the asterisk
*/
}
2. Rational intervals
// Not recommended writingvar name='Laobu'; // There is no space between the equal sign and the sides
// There is no interval between block-level statementsif(name){
('hello');
}
// Recommended writingvar name = 'Laobu'; // There is a spacing between the equal sign and the sides
// There are intervals between block-level statementsif (name) {
('hello');
}
3. Reasonable indentation
// Not recommended writing: no reasonable indentationfunction getName() {
('Laobu');
}
// Recommended writing method: reasonably indentfunction getName() {
('Laobu');
}
4. Reasonable empty lines
// Deprecated writing method: There are no blank lines between the code function blocksfunction getName() {
var name = 'Laobu';
if (name) {
('hello');
}
}
// Recommended writing method: There are empty lines between the code function blocksfunction getName() {
var name = 'Laobu';
if (name) {
('hello');
}
}
5. Reasonable naming
// Not recommended writingvar getName = 'Laobu'; // Variable naming prefix is verb
// Function naming prefix is nounfunction name() {
('hello');
}
// Recommended writingvar name = 'Laobu'; // Variable naming prefix is noun
// Function name prefix is verbfunction getName() {
('hello');
}
6. Reasonable statement
// Deprecated writing method: Use function before declarationgetName();
function getName() {
('hello');
}
// Recommended writing method: Use the function after declarationfunction getName() {
('hello');
}
getName();
7. A reasonable ending
// Not recommended writing: no semicolon endingvar name = 'Laobu'
var getName = function() {
('hello')
}
// Recommended writing method: end with a semicolonvar name = 'Laobu';
var getName = function() {
('hello');
};
The above mainly lists 7 more common coding style examples for comparison. There is no right or wrong between the recommended writing method and the unrecommended writing method. However, the recommended writing method is easier to read and maintain, more suitable for team development, and is also a reflection of a good coding image.
Coding specifications
Since the coding specification is a specification, we should write it according to certain rules. Writing code that violates the encoding specifications at will may lead to program errors and potential bugs, so it should be more rigorous compared to the encoding style. Some people will include the encoding style in the encoding specifications.
Here are a few common example codes:
1. Compare parameters
// Not recommended writing method: Type conversion will be performed when comparing == and !=, so try to avoid using itvar num = 123;
if (num == '123') {
(num);
} else if (num != '321') {
('321');
}
// Recommended writing method: use === and !== for comparisonvar num = 123;
if (num === '123') {
(num);
} else if (num !== '321') {
('321');
}
2. Package if statement
// Not recommended writing method: If statements do not use big numbers to wrap them, there will be potential bugsvar num = 123; if (num === '123') (num);
// Recommended writing method: if statement is wrapped in a big numbervar num = 123;
if (num === '123') {
(num);
}
3. Use eval with caution
// Deprecated writing method: Eval should be avoided, which is unsafe and very performance-consuming (submitted to JS statements at one time, executed at one time)var json = '{"name": "Laobu", "func": alert("hello")}';
eval('(' + json + ')'); // pop up“hello”
// Recommended writingvar json = '{"name": "Laobu", "func": alert("hello")}';
(json); // Verification error
4. Judge Type
// Deprecated writing method: Use typeof to judge the object created by the constructorvar str = new String('Laobu');
(typeof str); // 'object'
// Recommended writing method: use instanceof to judge the object created by the constructorvar str = new String('Laobu');
(str instanceof String); // true
5. Detect properties
// Deprecated writing method: use undefined and null to detect whether a property existsif (obj['name'] !== undefined) {
('name attribute exists'); // If undefined, it will cause errors in judgment}
if (obj['name'] !== null) {
('name attribute exists'); // If null, it will cause errors in judgment}
// Recommended writing method: Use the in operator to detect whether the object properties exist, and use the hasOwnProperty method to detect whether the object properties on the chain that does not contain the existence of the object properties on the prototype chainif ('name' in obj) {
('name attribute exists');
}
if (('name')) {
('name attribute exists');
}
The above mainly lists 5 common coding specification examples. Reasonable standardization of your own code can greatly reduce unnecessary maintenance costs and potential bug risks, which should be kept in mind for JavaScript learners.
Conclusion
"Programs are written for people to read, but they are just allowed to be executed occasionally." We cannot destroy our own code image in order to seek temporary convenience, which will cause unnecessary trouble to others and the entire project.
The above is all the content of this article. I hope that the content of this article will help you study or work. I also hope to support me more!