JavaScript coding rules

No rules, no rules. JavaScript brings flexibility and uncontrolled variables and access, so it must be restricted with rules. Whether a mature team or a fresh team, the rules should be different. I just listed some common or effective methods to restrain developers who jump. Thinking can make any leap, but the code must continue to be controlled. . Of course, any rules are based on a certain cognitive basis, and the foundation of object-oriented JavaScript is essential, otherwise nothing can be discussed.

Variable and method control:
Module development does not allow the storage of independent global variables and global methods. Only variables and methods are allowed to be placed in the "namespace" of the corresponding module. For an explanation of this, please see this article. It’s really annoying, so how about using anonymous functions?
Java code
(function() {
var value = 'xxx';
var func = function() {...};
})();

Modularization requires strict control of the culture of the code. This It is not only an aspect of code maintainability and customizability, but also allows the JavaScript engine to recycle properties and methods in a timely manner after use.
Polluting native objects in module code is not allowed, such as
Js code
String.prototype.func = new function(){...};

Such code must be controlled centrally, for example, placed uniformly in common.js, Protect it strictly.

Data storage constraints:
Divide and conquer ordinary variables, prototype variables and function variables. Method names must all start with a capital letter. Variable names should still follow the camel nomenclature:
Java code
function T(name){
T.prototype._instance_number++;
this.name = name;
this.showName=function(){
alert(this.name);
}
};
T.prototype = {
_instance_number:0,
getInstanceNum: function(){
  return T. prototype._instance_number;
}
};

var t = new T("PortalONE");
t.showName();
new T("Again");
alert(t.getInstanceNum()); // Print: 2

One thing is done intentionally here. The properties and private methods inside T start with an underscore, which implements encapsulation well (if t.instanceNum is used in the above code, this value cannot be accessed), If you don’t understand this code, quickly brush up on the object-oriented nature of JavaScript :). JavaScript provides two methods, closure and prototype, to achieve inheritance and polymorphism. Regarding the application of this in refactoring, I will discuss this in subsequent chapters. In addition, give priority to using JavaScript’s native objects and containers. , such as Array, Ajax data types are unified to JSON, try not to use hidden fields; in addition, it is usually not allowed to expand DOM objects at will.
As for communication between modules: Communication between modules means coupling between modules, which needs to be strictly avoided; communication methods usually use method-level attributes or module-level prototype variables.

DOM manipulation rules:
In module code, it is usually required to separate the manipulation of DOM into module js. You should avoid explicitly writing time-triggered functions on the DOM model, for example:

With the help of JQuery’s series of methods based on bind, after the behavioral logic is separated, you can completely see the refreshing HTML tags.
DOM objects are usually accessed by id, and occasionally by name. Traversing the DOM tree too many times and unreasonably is a taboo in maintaining front-end performance.

CSS style control:
(1) Try to reject the writing style="xxx". The main purpose is to unify the style into the theme style form. Of course, the theme style form is also stored according to modules. For different customizations and differences in different languages Switching styles brings convenience.
(2) Standardize JavaScript’s manipulation of styles. Ideally, a well-encapsulated UI can freely replace its style collection.

The above can only be regarded as the tip of the iceberg. In actual projects, it needs to be gradually refined and improved during the development process.