May 30, 2021 Article blog
JavaScript is flexible, easy to understand, and has relatively loose formatting requirements for code for engineers familiar with the C/C?or Java language. I t's easy to learn and apply to your own code. B ecause of this, JavaScript's coding specifications are often downplayed, patched up during development, and eventually turned into a nightmare for subsequent maintenance personnel. T he long-term value of software existence is directly proportional to the quality of coding. C oding specifications can help us reduce unnecessary hassles in programming. JavaScript code is sent directly to the customer's browser, directly meet with the customer, the quality of the code should be more attention.
This paper briefly discusses the coding specification in JavaScript programming and analyzes the reasons for it. I hope to draw more attention from Web developers to JavaScript coding specification issues and to software product quality issues.
When it comes to C/C++ and Java coding specifications, I'm sure many engineers aren't unfamiliar. B ut when it comes to coding specifications for the JavaScript language, you might be fed up. I sn't JavaScript syntax flexible? V ariables can be declared at any time; statement endings can be avoided; strings and numbers can be added together; and one less argument is not wrong. Y es, when you move from the strict syntax rules of C/C and Java to the JavaScript language, you feel a lot more free and relaxed. L oose syntax is an important feature of JavaScript. It's flexible and easy to understand, making it a lot easier for developers, but if you don't pay attention during writing, the debugging and maintenance costs of your code can increase invisibly.
JavaScript encoding is sent directly to the client's browser, and the code specification is not only a guarantee of code quality, but also affects the long-term reputation of the product. It is hoped that the specification of the JavaScript programming language will also attract more attention from friends.
In this paper, according to the summary of individual learning work, according to the use of layout, naming, declaration, scope, and some special symbols involved in the JavaScript coding process, give some suggestions of their own, and analyze the reasons for reference.
JavaScript programs should be placed as much as possible in files .js and included in HTML as <script src""filename .js" > when called. J avaScript code should avoid writing JavaScript code directly in html files if it is not intended for this HTML file. Because this can greatly increase the size of HTML files, it is not conducive to code compression and caching use.
In addition, <script src""filename.js" > label should be placed as far as possible behind the file. This reduces load times for other components on the page that are affected by loading JavaScript code.
Each line of code should be less than 80 characters. I f the code is long, try to wrap, and the next line of code should indent 8 spaces. T his allows the code to be organized neatly and reduces the fatigue of reading the code. Line breaks indent 8 spaces can be distinguished from the indentation of 4 spaces in the snippet to enhance the readability of the code.
The JavaScript statement should end with a semicolon. H owever, most browsers allow semicolons to be not written, as long as there is a line break where it should have been. B ut what are some considerations when long lines of code need to be wrapped? Line breaks should be selected after operators and punctuation, preferably after commas', 'after' and not after variable names, strings, numbers, or ''
This effectively prevents errors caused by copying and pasting, and effectively enhances the readability of the code. T he output of the code meets our expectations. H owever, as far as writing is concerned, the assignment statement to valueB is a line break after the variable valueA, which can easily be misinterpreted as valueB-ValueA, causing dyslexia for reading. T he copy statement for valueC is much easier to understand when the line break is made after the 'plus'. This is also the way this article advocates line breaks.