The basic principle

Basic principles

Separation of structure, style, and behavior

Try to ensure that documents and templates only contain HTML structures, and styles are placed in styles Tables, internals, and behaviors are all put into scripts.

Indentation

UnifyTwo spacesIndentation (in short, the indentation can be unified), do not use Tab or Tab, space mix and match.

File encoding

Use UTF-8 encoding without BOM.

• Specify encoding in HTML <meta charset="utf-8">;
• No need to use @charset Specify the encoding of the style sheet, which defaults to UTF-8 (refer to @charset);

Always use lowercase letters

<!-- Recommended --><img src="google.png" alt="Google"><!-- Not recommended --><A HREF="/">Home</A>

/* Recommended */color: #e5e5e5;/* Not recommended */color: #E5E5E5;

Omit the protocol part of the external link resource URL

Omit the http / https protocol in the URL of the external link resource (pictures and other media resources) to make the URL relative Address, avoid Mixed Content problems, and reduce the number of bytes in the file.

URLs of other protocols (ftp, etc.) are not omitted.

<!-- Recommended --><script src="//www.w3cschool.cn/statics/js/autotrack.js"></script><!-- Not recommended --><script src="http://www.w3cschool.cn/statics/js/autotrack.js"></script>

/* Recommended */.example {  background: url(//www.google.com/images/example);
}/* Not recommended */.example {  background: url(http://www.google.com/images/example);
}

Unified Annotation

By configuring the editor, shortcut keys can be provided to output a unanimously recognized annotation mode.

HTML Comments

• Module Comments

  <!-- 文章列表列表模块 --><div class="article-list">...</div>

• Block Comments

  <!--
  @name: Drop Down Menu
  @description: Style of top bar drop down menu.
  @author: Ashu(Aaaaaashu@gmail.com)
  -->

CSS Comments

Use one blank line to separate component blocks, sub-component blocks and declaration blocks, and three blank lines to separate sub-component blocks;

/* ==========================================================================
   组件块
 ============================================================================ *//* 子组件块
 ============================================================================ */.selector {  padding: 15px;  margin-bottom: 15px;
}/* 子组件块
 ============================================================================ */.selector-secondary {  display: block; /* 注释*/}.selector-three {  display: span;
}

JavaScript Comments

• Single-line comments

must occupy one line. // is followed by a space, and the indentation is consistent with the commented code on the next line.

• Multi-line comments

Avoid using multi-line comments like /*...*/. When there are multiple lines of comment content, use multiple single-line comments.

• Function/method comments
• Function/method comments must contain function descriptions, and comment identifiers must be used when there are parameters and return values. ;
• Parameter and return value annotations must contain type information and description;
• When the function is an internal function and is not accessible from the outside, the @inner identifier can be used;

/**
 * 函数描述
 *
 * @param {string} p1 参数1的说明
 * @param {string} p2 参数2的说明，比较长
 *     那就换行了.
 * @param {number=} p3 参数3的说明（可选）
 * @return {Object} 返回值描述
 */function foo(p1, p2, p3) {    var p3 = p3 || 10;    return {
        p1: p1,
        p2: p2,
        p3: p3
    };
}

• File comments

File comments are used to tell readers who are not familiar with this code what is contained in this file. The general contents of the file, its author, dependencies and compatibility information should be provided. as follows:

/**
 * @fileoverview Description of file, its uses and information
 * about its dependencies.
 * @author user@meizu.com (Firstname Lastname)
 * Copyright 2015 Meizu Inc. All Rights Reserved.
 */

Code verification

• Use W3C HTML Validator to verify the validity of your HTML code;
• Use W3C CSS Validator To verify the validity of your CSS code;

Code verification is not the ultimate goal. The real purpose is to allow developers to deeply understand what kind of syntax or syntax after going through this verification process many times. The writing method is non-standard and not recommended. Even if you are forced to use non-standard writing method in some scenarios, you can still be aware of it.