MaintainableJavaScript

MaintainableJavaScript

Taking notes while reading books, this warehouse mainly refers to the book "Writing Maintainable JavaScript" to summarize its own study notes. It’s just your own summary, which is different from the book. If you think it’s good, you can buy this book and study it yourself. The book also involves the difference in JSLint, JSHint. Where to get the code from, the code styles of various organizations or companies, and compare and summarize. The views on certain writing styles are sometimes ambiguous. My own summary does not have these things, and I prefer how to write them myself.

Finally, it is not easy for me to write this article. If it feels good, please click Star , thank you everyone.

Programming style

1. Basic formatting

   • Indent level
   • End of statement
   • The length of the row
   • Line break
   • Empty line
   • name
     • Variables and functions
     • constant
     • Constructor
   • Direct quantity
     • String
     • number
     • null
     • undefined
     • Direct Object Count
     • Direct array quantity

2. Comments

   • Single line comments
   • Multi-line comments
   • Use Comments
     • Difficult code
     • Code that may be mistaken for error
     • Browser Features Hack
   • Document Comments

3. Statements and expressions

   • Braces aligned
   • The interval of block statements
   • Switch statement
     • indentation
     • "Continuous Execution" of a case statement
     • default
   • with statement
   • for loop
   • for-in loop

4. Variables, functions, and operators

   • Variable declaration
   • Function declaration
   • Function call interval
   • Functions called immediately
   • Strict mode
   • equal

Indent level

• Indentation level is very important. If done poorly, it can easily cause many misunderstandings. The following code (for demonstration, here is deliberately modified the indentation of the sample code].

 if ( wl && wl . length ) {
            for ( i = 0 , 1 = wl . length ; i < 1 ; ++ i ) {
        p = wl [ i ] ;
        type = Y . Lang . type ( r [ p ] ) ;
        if ( s . hasOwnProperty ( p ) ) { if ( merge && type == 'object' ) {

    Y . mix ( r ( p ] , s { p ] ) ;
} else if ( ov || ! ( p in r ) ) {
                    r [ p ] = s [ p ] ;
            }
        }
    }
}    

• It is not easy to read this code quickly. The indentation here is not uniform. At first glance, else is the if statement corresponding to line 1. But in fact, this else corresponds to the if statement on line 5 of the code.

 if ( wl && wl . length ) {
    for ( i = 0 , 1 = wl . length ; i < 1 ; ++ i ) {
        p = wl [ i ] ;
        type = Y . Lang . type ( r [ p ] ) ;

        if ( s . hasOwnProperty ( p ) ) {
            if ( merge && type == 'object' ) {
                Y . mix ( r [ p ] , s [ p ] ) ;
            } else if ( ov || ! ( p in r ) ) {
                r [ p ] = s [ p ] ;
            }
        }
    }
}

• There are two opinions

  • Indentation using tabs
    • It is to indent it
  • Use spaces for indentation
    • Generally, it is indented with 4 spaces

• Both of the above methods are OK, but do not use the two methods in a mixed manner.

Back to top

End of statement

• In JavaScript, you can not end with a semicolon. The analyzer will automatically add a semicolon to the end.
• But this approach is not recommended.

 // 原始代码
function getData ( ) {
    return
    {
        title : "Maintainable JavaScript" ,
        author : "Nicholas C. Zakas"
    }
}

// 分析器会将它理解成
function getData ( ) {
    return ;
    {
        title : "Maintainable JavaScript" ,
        author : "Nicholas C. Zakas"
    } ;
}

• In the above example, the function will return an undefined, which is not the result we want. Although { can be put after return , the analysis's judgment is relatively complicated and cannot guarantee that we can take into account all the situations.

• All we should be more inclined to use them than to omit them.

• The above is the view of the author of the book. I do see a style that no semicolon is added at the end. This writing method requires that the semicolon be added in front of the sentence when it starts with [ , ( , `.

• Moreover, those who recommend this practice believe that it is not easy to make mistakes without adding a semicolon. Errors like the above will not be ignored until the online stage. When you create a method and do not get the results you want, they should be discovered immediately during development.

• Even if the specification with a semicolon is used, it will sometimes be missed due to accidental care (there is no problem with the detection tool)

• Finally, the third-party code used is not necessarily a semicolon-plus style. It is possible that you still have to add a semicolon in the first position.

 // 这些语句与上一句没有分号的语句连接的话会直接报错，所以必须加分号

; [ 1 , 2 , 3 ] . foreach ( function ( ) {
    // 处理内容
} )

; `shenxf ${ nickname } ` . length

// 很多代码都习惯于在圆括号之前加一个分号，这是由于之前引入的代码可能有漏了分号的情况，
// 为了以防万一，都会有类似于下面的代码。
; ( function ( ) {
    // 处理内容。
} ) ( )

• I prefer not to omit semicolons. If you want to use the specification of omitting semicolons, remember to add semicolons before [ , ( ,`.

Back to top

The length of the row

• If the content of a line is too long, a scroll bar will appear in the editing window. This is not conducive to our viewing of the code and is also more twisted. We should specify that the length of our line should not exceed 80 characters. More than 80 characters should be folded. This is because many editors have scrollbars after 80 characters

Back to top

Line break

• When the length of a row is too long, we will fold it. Usually, line breaks are required after the operator, because the analyzer will no longer automatically add a semicolon to the operator. Not easy to make mistakes.

 // 好的做法：在运算符后面换行。 第二行追加二个缩进
callAFunction ( document , element , window , "some string value" , true , 123 ,
        navigator ) ;

// 不好的做法第二行只有一个缩进
callAFunction ( document , element , window , "some string value" , true , 123 ,
    navigator ) ;

// 不好的做法运算符之前换行了
callAFunction ( document , element , window , "some string value" , true , 123
    , navigator ) ;

• Why two indents

    if ( isLeapYear && isFebruary && day && day == 29 && itsYourBirthdady &&
            noPlans ) {
        
        waitAnotherFourYears ( ) ;
    }

• From the above code, we can see that the two indentations are exactly staggered with one of the indentations of the internal statements of the condition, which makes it easier to read.
• But there is one exception. The second line after the assignment statement should be aligned

    var result = something + anotherThing + yetAnotherThing + someThingElse +
                 anotherSomethingElse ;

Back to top

Empty line

• Blank lines are often ignored, and the code should look like a piece of readable code, rather than being all mixed together. Take the example of indentation level

 if ( wl && wl . length ) {
    for ( i = 0 , 1 = wl . length ; i < 1 ; ++ i ) {
        p = wl [ i ] ;
        type = Y . Lang . type ( r [ p ] ) ;
        if ( s . hasOwnProperty ( p ) ) {
            if ( merge && type == 'object' ) {
                Y . mix ( r [ p ] , s [ p ] ) ;
            } else if ( ov || ! ( p in r ) ) {
                r [ p ] = s [ p ] ;
            }
        }
    }
}

• Add empty lines to this code

 if ( wl && wl . length ) {

    for ( i = 0 , 1 = wl . length ; i < 1 ; ++ i ) {
        p = wl [ i ] ;
        type = Y . Lang . type ( r [ p ] ) ;

        if ( s . hasOwnProperty ( p ) ) {

            if ( merge && type == 'object' ) {
                Y . mix ( r [ p ] , s [ p ] ) ;
            } else if ( ov || ! ( p in r ) ) {
                r [ p ] = s [ p ] ;
            }
        }
    }
}

• This will make you read more smoothly. Generally speaking, it is good to add empty lines to the following scene.
  • Between methods.
  • Between the local variable in the method and the first statement.
  • Before multiple lines or single lines comments.
  • Insert blank lines between logical segments of the method to improve readability.

Back to top

name

• The core of JavaScript is ECMAScript, which follows the camel case nomenclature (I won't explain this if it's too famous)
• Generally, it follows the naming specifications adopted by the language core, so most JavaScript programmers use camel nomenclature to name variables and functions.

Back to top

Variables and functions

• The naming prefix of a variable should be a noun, which can be distinguished from the naming rules of the function. The function should be prefixed with a verb.

 // 好的写法
var count = 10 ;
var myName = "shenxf" ;
var found = true ;

// 不好的写法: 变量看起来像函数
var getCount = 10 ;
var isFound = true ;

// 好的写法
function getName ( ) {
    return myName ;
}

// 不好的写法
function theName ( ) {
    return myName ;
}

• The naming should be as short and refined as possible. For example, count, length and size can be seen as numeric types, name, title, and message can be seen as string types.

• i, j, k are usually used in loop processing.

• Avoid writing meaningless naming.

• For the naming of the method, the first word should be a verb. Here are some common conventions

verb	meaning
can	The function returns a boolean value
has	The function returns a boolean value
is	The function returns a boolean value
get	The function returns a non-boolean value
set	Functions are used to save a value

• According to the above writing method, readability will be very good

 if ( isEnabled ( ) ) {
    setName ( "shenxf" ) ;
}

if ( getName ( ) === "shenxf" ) {
    doSomething ( ) ;
}

Back to top

constant

• Before ECMAScript6, JavaScript did not have the concept of real normal quantity. In order to distinguish between ordinary variables and constants, they are named with methods similar to C, and are named with capital letters and underscores, which are used to separate words.

 var MAX_COUNT = 10 ;
var URL = "http://shenxf.top" ;

• Take a look at the code

 if ( count < MAX_COUNT ) {
    doSomething ( ) ;
}

Back to top

Constructor

• The constructor follows the nomenclature of the big camel. It is mainly to distinguish from the nomenclature of functions and variables.

 // 好的做法
function Person ( name ) {
    this . name = name ;
}

Person . prototype . sayName = function ( ) {
    alert ( this . name ) ;
}

var me = new Person ( "shenxf" ) ;

• This way you can quickly find problems. Check out the following code

 var me = Person ( "shenxf" ) ; // 这里缺少了new
var you = getPerson ( "xx" ) ;

Back to top

Direct quantity

• The original values ​​in JavaScript include: strings, numbers, booleans, null and undefined. Also contains direct quantities of objects and arrays.
• Among them, only the Boolean values ​​are self-interpreted, and the rest should be considered how to accurately express the meaning.

Back to top

String

• Here, the author of the original book proposes that double and single quotes can be used.

 // 下面都是合法的javascript代码
var name = "shenxf says, "Hi."" ;
var name = 'shenxf says, "Hi."' ;

• The authors of the book often use Java, which uses double quotes to represent strings. Therefore, the author recommends using double quotes because it can be consistent with the Java language.

• I personally recommend using single quotes. Many of the encoding specification plugins I have used before declare variables in single quotes. I'm used to it, so I recommend using single quotes. No matter which one is used, I think it's enough to keep your code style consistent.

• When strings are broken, operators should be used to connect.

 // 不好的写法
var longString = "Here's the story, of a man 
named Brady." ;

// 好的写法
var longString = "Here's the story, of a man" +
                 "named Brady." ;

Back to top

number

• Give it to Liezi directly

 // 整数
var count = 10 ;

// 小数
var price = 10.0 ;
var price = 10.00 ;

// 不推荐小数的写法：没有小数部分
var pricee = 10. ;

// 不推荐小数的写法：没有整数部分
var price = .1 ;

// 不推荐的写法：八进制写法已经被弃用
var num = 010 ;

// 十六进制写法
var num = 0xA2 ;

// 科学计数法
var num = 1e23 ;

• The first two not recommended writing styles feel particularly twisted. I don’t know if they were written deliberately or missed. To avoid ambiguity, it is not recommended.
• The writing of octal system is also easy to cause ambiguity, and it is very likely to be considered as an integer of 10 , but it is actually 8 , so it is not recommended.

Back to top

null

• null is more special and often confused with undefined.

• Scenarios where null should be used

  • Used to initialize a variable, which may be assigned to an object
  • Used to compare with an initialized variable, which can be or is not an object
  • When the parameter of a function is expected to be an object, it is passed in as a parameter
  • When the return value of the function is expected to be an object, it is passed out as the return value

• Scenarios where null should not be used

  • Do not use null to detect whether a parameter has been passed in
  • Do not use null to detect an uninitialized variable

• example

 // 好的用法
var person = null ;

// 好的用法
function getPerson ( ) {
    if ( condition ) {
        return new Person ( "shenxf" ) ;
    } else {
        return null ;
    }
}

// 好的用法
var person = getPerson ( ) ;
if ( person !== null ) {
    doSomething ( ) ;
}

// 不好的写法：用来和未初始化的变量进行比较
var person ;
if ( person != null ) {
    doSomething ( ) ;
}

// 不好的写法：检测是否传入了参数
function doSomething ( arg1 , arg2 , arg3 , arg4 ) {
    if ( arg4 != null ) {
        doSomethingElse ( ) ;
    }
}

• The best way to understand null is to understand it as a placeholder

Back to top

undefined

• The most confusing thing is that the result of null == undefined is true , however, the usage of these 2 values ​​varies.
• Those variables that are not initialized have an initial value, that is, undefined , indicating that the variable is waiting to be assigned.

 // 不好的写法
var person ;
console . log ( person === undefined ) ; //true

• Although this is normal code, we should avoid undefined .
• Because undefined has many confusing things, such as typeof

 // foo未被声明
var person ;
console . log ( typeof person ) ; // "undefined"
console . log ( typeof foo ) ;    // "undefined"

• This code seems nothing, but there is a huge difference in some scenarios (foo will report an error in the statement, while person will not)
• By prohibiting the use of special value undefined , the result of typeof can be undefined . That is when the variable is not declared.

 // 好的做法
var person = null ;
console . log ( person === null ) ; // true

• typeof null value returns Object , which can avoid undefined and distinguish it.

Back to top

Direct Object Count

• If there is something that is directly measured, it is best not to create it first and then assign values.

 // 不好的写法
var book = new Object ( ) ;
book . title = "shenxfsbook" ;
book . author = "shenxf" ;

• Direct quantity can efficiently complete tasks with the same amount of indirect quantity.
• When defining a direct quantity, the first line contains the left curly braces, each attribute's name value pair takes one line, and keeps an indentation, and the last curly braces also take one line.

 // 好的写法
var book = {
    title : "shenxfsbook" ,
    author : "shenxf"
} ;

Back to top

Direct array quantity

• Similar to the direct quantity of the object, it is not recommended to use non-direct quantity.

 // 不好的写法
var colors = new Array ( "red" , "green" , "blue" ) ;
var numbers = new Array ( 1 , 2 , 3 , 4 ) ;

// 好的写法
var colors = [ "red" , "green" , "blue" ] ;
var numbers = [ 1 , 2 , 3 , 4 ] ;

Back to top

Single line comments

 // 这是一句单行注释

• It is best to reserve a space behind the double slashes.

• There are 3 ways to use single line comments

  • Exclusive one line of comments to explain the next line of code. There is always a blank line before this line of comments, and the indentation level is consistent with the next line of code.
  • Comments at the end of the line of code. There is at least one indent between the end of the code and the comment. Comments (including the previous code part) should not exceed the maximum number of characters in a single line. If it is exceeded, this line of comments should be placed above the code line.
  • Commented large pieces of code (multi-line code that comes with the compiler)

• Single-line comments should not be used for multiple lines unless they are large pieces of code that are commented.

 // 好的写法
if ( condition ) {

    // 如果代码执行到这里，则表示通过了左右的安全性检查
    allowed ( ) ;
}

// 不好的写法：注释之前没有空行
if ( condition ) {
    // 如果代码执行到这里，则表示通过了左右的安全性检查
    allowed ( ) ;
}

// 不好的写法：错误的缩进
if ( condition ) {
// 如果代码执行到这里，则表示通过了左右的安全性检查
    allowed ( ) ;
}

// 好的写法
var result = something + somethingElse ; // somethingElse不应当取值为null

// 不好的写法：代码和注释之间没有间隔
var result = something + somethingElse ; // somethingElse不应当取值为null

// 好的写法
// if (condition) {
//     dosomething();
//     thenDoSomethingElse();
// }

// 不好的写法:这里应当用多行注释
// 接下来的这段代码非常难，那么，让我详细的解释下
// 这段代码首先判断条件是否为真
// 。。。。。。。
if ( condition ) {
    // 如果代码执行到这里，则表示通过了左右的安全性检查
    allowed ( ) ;
}

Back to top

Multi-line comments

• Legal multi-line comments

 /* 我的注释 */
/* 另一段注释
这个注释包含2行 */
/*
又是一段注释
这段注释同样包含2行
*/

• These annotations are legal but not clear. It is recommended to use annotation method similar to java
• The first is /* , and the last line is */ , and each line starts with * and opens a space

 /*
 * 另一段注释
 * 这个注释包含2行
 */

• Multi-line comments should have blank lines before commenting the same as single-line comments. Comments are used to illustrate the code of the following line and keep the same indentation as the next line.

 // 好的写法
if ( condition ) {

    /*
     * 如果代码执行到这里
     * 说明通过了所有安全性检查
     */
    allowed ( ) ;
}

// 不好的写法：注释之前无空行
if ( condition ) {
    /*
     * 如果代码执行到这里
     * 说明通过了所有安全性检查
     */
    allowed ( ) ;
}

// 不好的写法：星号之后没有空格
if ( condition ) {
    /*
     *如果代码执行到这里
     *说明通过了所有安全性检查
     */
    allowed ( ) ;
}

// 不好的写法：错误的缩进
if ( condition ) {
/*
 * 如果代码执行到这里
 * 说明通过了所有安全性检查
 */
    allowed ( ) ;
}

// 不好的写法：代码尾部不要用多行注释
var result = something + somethingElse ; /*somethingElse不应当取值为null*/

Back to top

Use Comments

• Comments should be added when the code is not clear enough, and comments should not be added when the code is very clear, which is a bit extravagant.

 // 不好的写法：注释并没有提供有价值的信息

// 初始化count
var count = 10 ;

// 好的写法

// 改变这个值可能会使它变成青蛙
var count = 10 ;

• Therefore, the principle of adding comments is when the code needs to be clearer.

Back to top

Difficult code

• Annotations should be added to the difficult code

 // 好的写法

if ( mode ) {

    /*
     * 当 mode 为2时
     * 用来执行原型合并的操作。。。。
     * 。。。。
     */
    if ( mode === 2 ) {
        Y . mix ( receiver . prototype , supplier . prototype , overwrite ,
                whitelis , 0 , merge ) ;
    }

     /*
      * 根据模式的类型。。。
      * 。。。。
      */
    from = mode === 1 || mode === 3 ? supplier . prototype : supperlier ;
    to   = mode === 1 || mode === 4 ? receiver . prototype : receiver ;

    /*
     * .......
     * ......
     */
    if ( ! from || ! to ) {
        from = supperlier ;
        to   = receiver ;
    }
} else {
    from = supplier ;
    to = receiver ;
}

Back to top

Code that may be mistaken for error

• There will be some kind-hearted people in the team who will automatically correct a seemingly wrong code, but this error is often not the source of the error.
• Modifying this code will cause other bugs

 while ( element && ( element = element [ asix ] ) ) { // 赋值操作
    if ( ( all || element [ TAG_NAME ] ) &&
        ( ! fn || fn ( element ) ) ) {
        
        return element ;
    }
}

• In this example, the author stated that he is an assignment operation. Although this is not a standard usage, the detection tool may detect problems.
• It is easy to be misunderstood as a mistake. This kind of comment shows that the author did it intentionally. This avoids unnecessary misunderstandings.

Back to top

Browser Features Hack

• To be compatible with lower versions of the browser, JavaScript programmers tend to write "code that may be mistaken for error".

 var ret = false ;

if ( ! needle || ! element || ! needle [ NODE_TYPE ] || ! element [ NODE_TYPE ] ) {
    ret = false ;
} else if ( element [ CONTAINS ] ) {
    // 如果needle不是ELEMENT_NODE时，IE和Safari下会有错误
    if ( Y . UA . opera || needle [ NODE_TYPE ] === 1 ) {
        ret = element [ CONTAINS ] ( needle ) ;
    } else {
        ret = Y_DOM . _bruteContains ( element , needle ) ;
    }
} else if ( element [ COMPARE_DOCUMENT_POSITION ] ) { // gecko
    if ( element === needle || ! ! ( element [ COMPARE_DOCUMENT_POSITION ] ( needle ) & 16 ) ) {
        ret = true
    }
}

• There is an important comment on the sixth line. Although both IE and Safari have built-in methods contains(), but the needle is not an element, this method will report an error.
• So this method can only be used when the browser is Opera. Here is why you need an if statement. This will not be mistaken by others, and the browser will quickly locate this code if it needs to make corresponding compatibility changes in the future, which is also beneficial to its own maintenance.

Back to top

Document Comments

• Although it is not a component of JavaScript, it is widely used now. Generally, document annotations have many formats. The most popular one is derived from the JavaDoc document format:
  • Multiline comments start with a single-slash double asterisk /** , followed by description information, where the @ symbol represents one or more properties.

 /**
返回一个对象，这个对象包含被提供对象的所有属性。
后一个对象的属性会覆盖前一个对象的属性。
传入一个单独对象。。。。
@method merge
@param {Object} 被合并的一个或多个对象
@param {Object} 一个新的合并后的对象
**/
Y . merge = function ( ) {
    var args    = arguments ,
        i       = 0 ,
        len     = args . length ,
        result  = { } ;
    
    for ( ; i < len ; ++ i ) {
        Y . mix ( result , args [ i ] , true ) ;
    }

    return result ;
} ;

• You should make sure to add comments to the following
  • All methods
    • Annotation description should be added to the method, desired parameters, and possible return values.
  • All constructors
    • A comment description should be added to the custom type and the desired parameters.
  • All objects containing documented methods
    • If an object contains one or more methods with document comments, the object should also appropriately add document comments to the document generation tool.
    • Of course, the detailed format and usage of comments are ultimately determined by the document generation tool you choose.

Back to top

Braces aligned

• There are 2 styles

  • The first style is to place the left bracket at the end of the first sentence code
    • This style comes from java

   if ( condition ) {
      doSomething ( ) ;
  } else {
      doSomethingElse ( ) ;
  }

  • The second style is to place the left bracket on the next line of the first line of the block statement.

   if ( condition )
  {
      doSomething ( ) ;
  }
  else
  {
      doSomethingElse ( ) ;
  }

  • This style is C# style, and this writing method will cause errors in automatically inserting semicolon positions, so this style is not recommended in JavaScript.

Back to top

The interval of block statements

• There are three main styles

  • The first style has no space space between the statement name, parentheses and the left curly braces.
    • This style is not readable.

   if ( condition ) {
      doSomething ( ) ;
  }

  • The second style, add a space before the left bracket and after the right bracket
    • This style is the most popular.

   if ( condition ) {
      doSomething ( ) ;
  }

  • The third style, add a space after the left bracket and before the right bracket
    • This writing method is the most readable.

   if ( condition ) {
      doSomething ( ) ;
  }

  • Like the author of the book, I recommend the second style.

Back to top

Switch statement

• The behavior of switch statements in JavaScript is different from that in other languages: switch statements can use any type of value, and any expression can be legally used in case clauses. But in other languages, raw values ​​and constants must be used.

Back to top

indentation

• Many people use Java style

    switch ( condition ) {
        case "first" :
            // 代码
            break ;

        case "second" :
            // 代码
            break ;

        case "third" :
            // 代码
            break ;
        
        default :
            // 代码
    }

• What's unique

  • Each case statement is indented to a level relative to the switch keyword.
  • Starting from the second Henan Opera, there is a blank line before and after each case statement.

• Another style

    switch ( condition ) {
    case "first" :
        // 代码
        break ;
    case "second" :
        // 代码
        break ;
    case "third" :
        // 代码
        break ;
    default :
        // 代码
    }

• The difference is that case keyword remains left-aligned with switch .

• Both the author and I like the Java style.

Back to top

"Continuous Execution" of a case statement

• If you do not add break after case , the following conditions will be executed continuously, which will become the original sin of many system bugs.
• But there are still many people who accept this continuous execution programming method. But the logic must be written clearly.

    switch ( condition ) {

        // 明显的依次执行
        case "first" :
        case "second" :
            // 代码
            break ;

        case "third" :
            // 代码
            
            /* fall through */
        default :
            // 代码
    }

• The first 2 lines of code are obvious continuous execution, which is reasonable.
• Since there are comments added in third , it means that this is intentional. This is also reasonable.

Back to top

default

• The more controversial issue is whether default is needed, and many people never omit default , even though it does nothing.

    switch ( condition ) {
        case "first" :
            // 代码
            break ;

        case "second" :
            // 代码
            break ;

        default :
            // default中没有逻辑
    }

• The author prefers that there is no default behavior and can be omitted if the comment is written.

    switch ( condition ) {
        case "first" :
            // 代码
            break ;

        case "second" :
            // 代码
            break ;

        // 没有 default
    }

• This indicates that there is no default behavior and saves bytes.

• I prefer the first one, you can just write default: no comments. This also clearly knows that there is no default behavior. When adding default behavior in the future, you can write one less line of code. Actually, both methods are OK, it depends on which one you like.

Back to top

with statement

• Before I read this book, I didn’t know about this thing. If you are like me, please skip this chapter (if you don’t know, you won’t use it). This is not a good thing.

 var book = {
    title : "shenxf javascrpt" ,
    author : "shenxf"
} ;

var message = " The book is " ;

with ( book ) {
    message += title ;
    message += " by " + author ;
}

• Although it allows us to omit some bytes in writing, this thing has its disadvantages. It is difficult for us to distinguish where title and author appear, and it is also difficult to distinguish whether message is a local variable or a property of book . Programmatically speaking, JavaScript engines and compression tools cannot optimize this code, so they cannot guess the true meaning of the code.

Back to top

for loop

• There are two types of for loops, one is the traditional for loop, and the other is the for-in loop

    var values = [ 1 , 2 , 3 , 4 , 5 , 6 , 7 ] ,
        i , len ;
    for ( i = 0 , len = values . length ; i < len ; i ++ ) {
        process ( values [ i ] ) ;
    }

• You can use break and continue statements in the for loop, and I believe everyone knows how to use them.
• There is a style that says not to use continue . It is better to use conditional statements than to use continue , and the logic is clearer.

    var values = [ 1 , 2 , 3 , 4 , 5 , 6 , 7 ] ,
        i , len ;
    for ( i = 0 , len = values . length ; i < len ; i ++ ) {
        if ( i !== 2 ) {
            process ( values [ i ] ) ;
        }
    }

• The author of the book did not make a clear statement. I don’t think this is enough, and I can still use it if I want to use it. There is no problem with this statement itself.

Back to top

for-in loop

• I believe everyone will use it. The for-in loop not only traverses the instance properties of the object, but also traverses the properties inherited from the prototype chain. When iterating over the properties of a custom object, it often terminates with unexpected results. Therefore, it is best to use hasOwnProperty() method to filter out instance properties for the for-in loop.

 var prop ;

for ( prop in object ) {
    if ( object . hasOwnProperty ( prop ) ) {
        console . log ( "Property name is " + prop ) ;
        console . log ( "Property value is " + object [ prop ] ) ;
    }
}

• Generally, hasOwnProperty is added, but if you just want to find the prototype chain, please add comments.

 var prop ;

for ( prop in object ) { // 包含对原型链的遍历
    console . log ( "Property name is " + prop ) ;
    console . log ( "Property value is " + object [ prop ] ) ;
}

• The for-in loop is used to traverse objects, please do not use it to traverse arrays.

 // 不好的用法
var values = [ 1 , 2 , 3 , 4 , 5 ] ,
    i ;

for ( i in values ) {
    process ( item [ i ] ) ;
}

Back to top

Variable declaration

• The declaration will be promoted to the top of the current scope.

 function doSomething ( ) {
    
    var result = 10 + value ;
    var value = 10 ;
    return result ;
}

• Understanding of the above code

 function doSomething ( ) {
    var result ;
    var value

    result = 10 + value ;
    value = 10 ;

    return result ;
}

• The result of this function is the NaN value.

• The author tends to style, put all definitions in the beginning of the scope, separated by commas, which can save the bytes written in var .

    function doSomethingWithItems ( items ) {

        var value = 10 ,
            result = value + 10 ,
            i ,
            len ;
        
        for ( i = 0 , len = items . length ; i < len ; i ++ ) {
            doSomething ( items [ i ] ) ;
        }
    }

Back to top

Function declaration

• Function declarations will also be advanced by the javaScript engine.

    // 不好的写法
    doSomething ( ) ;

    function doSomething ( ) {
        alert ( 'Hello world!' ) ;
    }

• JavaScript will interpret the code as

    function doSomething ( ) {
        alert ( 'Hello world!' ) ;
    }

    doSomething ( ) ;

• We should declare the function first and then use it

    function doSomethingWithItems ( items ) {

        var i , len ,
            value = 10 ,
            result = value + 10 ;
        
        function doSomething ( item ) {
            // 代码逻辑
        }

        for ( i = 0 , len = items . length ; i < len ; i ++ ) {
            doSomething ( items [ i ] ) ;
        }
    }

• In addition, functions should not appear in statement blocks.

    // 不好的写法
    if ( condition ) {
        function doSomething ( ) {
            alert ( 'hi' ) ;
        }
    } else {
        function doSomething ( ) {
            alert ( 'Yo' ) ;
        }
    }

• Because the declaration of the function will be advanced, regardless of whether the conditions here are satisfied or not, the second function with the same name will overwrite the first function. So the above code will not be executed as we intend.

Back to top

Function call interval

    // 好的写法
    doSomething ( item ) ;

    // 不好的写法：看起来像一个语句块
    doSomething ( item ) ;

    // 用来做对比的块语句
    while ( item ) {
        // 代码逻辑
    }

Back to top

Functions called immediately

    // 一般的写法
    var doSomething = function ( ) {
        // 函数体
    } ;

    // 不好的写法 : 被误解为函数的赋值，其实是被赋值为一个对象
    var value = function ( ) {

        // 函数体

        return {
            message : "Hi"
        }
    } ( ) ;

    // 好的写法
    var value = ( function ( ) {

        // 函数体
        
        return {
            message : "Hi"
        }
    } ( ) ) ;

Back to top

Strict mode

• use strict

    // 不好的写法 - 全局严格模式
    "use strict"
    function doSomething ( ) {
        // 代码
    }

    // 好的写法
    function doSomething ( ) {
        "use strict"
        // 代码
    }

• If you want to apply strict patterns in multiple functions without having to thank many lines, you can use the function to execute immediately

    // 好的写法
    ( function ( ) {
        "use strict"
        function doSomething ( ) {
            // 代码
        }
        function doSomethingElse ( ) {
            // 代码
        }
    } ) ( ) ;

• Why not use strict mode globally?
  • When using strict mode globally, the code in other files (in non-strict mode) may report an error.

Back to top

equal

• Type conversion will be performed when equal

    // 比较数字5和字符串5
    console . log ( 5 == "5" ) ; // true

    // 比较数字25和十六进制的字符串25
    console . log ( 25 == "0x19" ) ; // true

• When a cast occurs, the string will be converted to a number, similar to using Number() conversion function. It converts hexadecimal numbers correctly. So the second expression is equal.

• Comparison of boolean values ​​and numbers

    // 数字 1 和 true
    console . log ( 1 == true ) ; // true

    // 数字 0 和 false
    console . log ( 0 == false ) ; // true

    // 数字 2 和 true
    console . log ( 2 == true ) ; // false

• If one of them is an object and the other is not, valueOf() method will be called first to get the original type and then compared. If there is no valueOf() , toString() will be called.

    var object = {
        toString : function ( ) {
            return "0x19" ;
        }
    } ;

    console . log ( object == 25 ) ; // true

• According to the description of the ECMAScript standard specification, null and undefined are equal.

    console . log ( null == undefined ) ; // true

• Due to the above cast type conversion, it is recommended not to use == and != . You should use === and !== . They will not convert type conversion and return false as long as the types are different.

    // 比较数字5和字符串5
    console . log ( 5 == "5" ) ; // true
    console . log ( 5 === "5" ) ; // false

    // 比较数字25和十六进制的字符串25
    console . log ( 25 == "0x19" ) ; // true
    console . log ( 25 === "0x19" ) ; // false

    // 数字 1 和 true
    console . log ( 1 == true ) ; // true
    console . log ( 1 === true ) ; // false

    // 数字 0 和 false
    console . log ( 0 == false ) ; // true
    console . log ( 0 === false ) ; // false

    // 数字 2 和 true
    console . log ( 2 == true ) ; // false
    console . log ( 2 === true ) ; // false

    var object = {
        toString : function ( ) {
            return "0x19" ;
        }
    } ;

    // 一个对象和25
    console . log ( object == 25 ) ; // true
    console . log ( object === 25 ) ; // false

    // null和undefined
    console . log ( null == undefined ) ; // true
    console . log ( null === undefined ) ; // false

Back to top

Make up for it

Image recognition

ocr windows installation

You can also convert pdf to png file directly and then use ocr to grab text.

Crawl English tesseract xxx.png output_1 -l eng

Crawl Chinese tesseract xxx.png output_1 -l chi_sim