前端開發規范：命名規范、html規范、css規范、js規范

作者：Echa攻城獅 2020-04-16 21:02:35

一個好的程序員肯定是要能書寫可維護的代碼，而不是一次性的代碼，怎么能讓團隊當中其他人甚至一段時間時候你再看你某個時候寫的代碼也能看懂呢，這就需要規范你的代碼了。

一個好的程序員肯定是要能書寫可維護的代碼，而不是一次性的代碼，怎么能讓團隊當中其他人甚至一段時間時候你再看你某個時候寫的代碼也能看懂呢，這就需要規范你的代碼了。我是有一點強迫癥的人，上周我們后端給我了一個CanUsename的接口（該接口的目的是判斷輸入的目的地是否是4級目的地），我真的是崩潰的。我只是覺得這個名字不夠語義化，但是讓我自己想一個名字我又想不出來，于是我就在想，如果有一套命名規范的話，那么以后起名字就不用發愁了，直接按照規范來就好了

命名

駝峰式命名法介紹

Pascal Case 大駝峰式命名法：首字母大寫。eg：StudentInfo、UserInfo、ProductInfo
Camel Case 小駝峰式命名法：首字母小寫。eg：studentInfo、userInfo、productInfo文件資源命名
文件名不得含有空格
文件名建議只使用小寫字母，不使用大寫字母。( 為了醒目，某些說明文件的文件名，可以使用大寫字母，比如README、LICENSE。 )
文件名包含多個單詞時，單詞之間建議使用半角的連詞線 ( - ) 分隔。
引入資源使用相對路徑，不要指定資源所帶的具體協議 ( http:,https: ) ，除非這兩者協議都不可用。

不推薦：

<script src="http://cdn.com/foundation.min.js"></script>

推薦

<script src="//cdn.com/foundation.min.js"></script>

變量命名

命名方式 : 小駝峰式命名方法命名規范 : 類型+對象描述的方式，如果沒有明確的類型，就可以使前綴為名詞

推薦

var tableTitle = "LoginTable"

不推薦

var getTitle = "LoginTable"

函數

命名方式 : 小駝峰方式 ( 構造函數使用大駝峰命名法 )命名規則 : 前綴為動詞

前端開發規范：命名規范、html規范、css規范、js規范

推薦：

//是否可閱讀 
function canRead(){ 
    return true; 
} 
 
//獲取姓名 
function getName{ 
    return this.name 
}

常量

命名方法 : 全部大寫命名規范 : 使用大寫字母和下劃線來組合命名，下劃線用以分割單詞。推薦：

var MAX_COUNT = 10; 
 var URL = 'http://www.baidu.com';

類的成員

公共屬性和方法 : 同變量命名方式
私有屬性和方法 : 前綴為下劃線(_)后面跟公共屬性和方法一樣的命名方式

推薦(將name換成this是不是更熟悉了呢)

function Student(name) { 
    var _name = name; // 私有成員 
 
    // 公共方法 
    this.getName = function () { 
        return _name; 
    } 
 
    // 公共方式 
    this.setName = function (value) { 
        _name = value; 
    } 
} 
var st = new Student('tom'); 
st.setName('jerry'); 
console.log(st.getName()); // => jerry：輸出_name私有變量的值

注釋規范

單行注釋 ( // )

單獨一行：//(雙斜線)與注釋文字之間保留一個空格
在代碼后面添加注釋：//(雙斜線)與代碼之間保留一個空格，并且//(雙斜線)與注釋文字之間保留一個空格。
注釋代碼：//(雙斜線)與代碼之間保留一個空格。

多行注釋 ( / 注釋說明 / )

若開始(/*和結束(*/)都在一行，推薦采用單行注釋
若至少三行注釋時，第一行為/*，最后行為*/，其他行以*開始，并且注釋文字與*保留一個空格。
推薦 : /* * 代碼執行到這里后會調用setTitle()函數 * setTitle()：設置title的值 */ setTitle();復制代碼

函數 ( 方法 ) 注釋

函數(方法)注釋也是多行注釋的一種，但是包含了特殊的注釋要求，參照 javadoc(百度百科)語法：

/**  
* 函數說明  
* @關鍵字  
*/復制代碼

常用注釋關鍵字

前端開發規范：命名規范、html規范、css規范、js規范

HTML規范

文檔規范

使用 HTML5 的文檔聲明類型 : <!DOCTYPE html>

DOCTYPE標簽是一種標準通用標記語言的文檔類型聲明，它的目的是要告訴標準通用標記語言解析器，它應該使用什么樣的文檔類型定義（DTD）來解析文檔。
使用文檔聲明類型的作用是為了防止開啟瀏覽器的怪異模式。
沒有DOCTYPE文檔類型聲明會開啟瀏覽器的怪異模式，瀏覽器會按照自己的解析方式渲染頁面，在不同的瀏覽器下面會有不同的樣式。
如果你的頁面添加了<!DOCTYP>那么，那么就等同于開啟了標準模式。瀏覽器會按照W3C標準解析渲染頁面。

腳本加載

說到js和css的位置，大家應該都知道js放在下面，css放在上面。但是，如果你的項目只需要兼容ie10+或者只是在移動端訪問，那么可以使用HTML5的新屬性async，將腳本文件放在<head>內兼容老舊瀏覽器(IE9-)時：腳本引用寫在 body 結束標簽之前，并帶上 async 屬性。這雖然在老舊瀏覽器中不會異步加載腳本，但它只阻塞了 body 結束標簽之前的 DOM 解析，這就大大降低了其阻塞影響。而在現代瀏覽器中：腳本將在 DOM 解析器發現 body 尾部的 script 標簽才進行加載，此時加載屬于異步加載，不會阻塞 CSSOM（但其執行仍發生在 CSSOM 之后）。綜上所述，所有瀏覽器中推薦:

<html> 
  <head> 
    <link rel="stylesheet" href="main.css"> 
  </head> 
  <body> 
    <!-- body goes here --> 
 
    <script src="main.js" async></script> 
  </body> 
</html>

只兼容現代瀏覽器推薦:

<html> 
  <head> 
    <link rel="stylesheet" href="main.css"> 
    <script src="main.js" async></script> 
  </head> 
  <body> 
    <!-- body goes here --> 
  </body> 
</html>

語義化

我們一直都在說語義化編程，語義化編程，但是在代碼中很少有人完全使用正確的元素。使用語義化標簽也是有理由SEO的。

語義化是指：根據元素其被創造出來時的初始意義來使用它。意思就是用正確的標簽干正確的事，而不是只有div和span。

不推薦：

<b>My page title</b> 
<div class="top-navigation"> 
  <div class="nav-item"><a href="#home">Home</a></div> 
  <div class="nav-item"><a href="#news">News</a></div> 
  <div class="nav-item"><a href="#about">About</a></div> 
</div> 
 
<div class="news-page"> 
  <div class="page-section news"> 
    <div class="title">All news articles</div> 
    <div class="news-article"> 
      <h2>Bad article</h2> 
      <div class="intro">Introduction sub-title</div> 
      <div class="content">This is a very bad example for HTML semantics</div> 
      <div class="article-side-notes">I think I'm more on the side and should not receive the main credits</div> 
      <div class="article-foot-notes"> 
        This article was created by David <div class="time">2014-01-01 00:00</div> 
      </div> 
    </div> 
 
    <div class="section-footer"> 
      Related sections: Events, Public holidays 
    </div> 
  </div> 
</div> 
 
<div class="page-footer"> 
  Copyright 2014 
</div>

推薦

html 代碼: 
<!-- The page header should go into a header element --> 
<header> 
  <!-- As this title belongs to the page structure it's a heading and h1 should be used --> 
  <h1>My page title</h1> 
</header> 
 
<!-- All navigation should go into a nav element --> 
<nav class="top-navigation"> 
  <!-- A listing of elements should always go to UL (OL for ordered listings) --> 
  <ul> 
    <li class="nav-item"><a href="#home">Home</a></li> 
    <li class="nav-item"><a href="#news">News</a></li> 
    <li class="nav-item"><a href="#about">About</a></li> 
  </ul> 
</nav> 
 
<!-- The main part of the page should go into a main element (also use role="main" for accessibility) --> 
<main class="news-page" role="main"> 
  <!-- A section of a page should go into a section element. Divide a page into sections with semantic elements. --> 
  <section class="page-section news"> 
    <!-- A section header should go into a section element --> 
    <header> 
      <!-- As a page section belongs to the page structure heading elements should be used (in this case h2) --> 
      <h2 class="title">All news articles</h2> 
    </header> 
 
    <!-- If a section / module can be seen as an article (news article, blog entry, products teaser, any other 
     re-usable module / section that can occur multiple times on a page) a article element should be used --> 
    <article class="news-article"> 
      <!-- An article can contain a header that contains the summary / introduction information of the article --> 
      <header> 
        <!-- As a article title does not belong to the overall page structure there should not be any heading tag! --> 
        <div class="article-title">Good article</div> 
        <!-- Small can optionally be used to reduce importance --> 
        <small class="intro">Introduction sub-title</small> 
      </header> 
 
      <!-- For the main content in a section or article there is no semantic element --> 
      <div class="content"> 
        <p>This is a good example for HTML semantics</p> 
      </div> 
      <!-- For content that is represented as side note or less important information in a given context use aside --> 
      <aside class="article-side-notes"> 
        <p>I think I'm more on the side and should not receive the main credits</p> 
      </aside> 
      <!-- Articles can also contain footers. If you have footnotes for an article place them into a footer element --> 
      <footer class="article-foot-notes"> 
        <!-- The time element can be used to annotate a timestamp. Use the datetime attribute to specify ISO time 
         while the actual text in the time element can also be more human readable / relative --> 
        <p>This article was created by David <time datetime="2014-01-01 00:00" class="time">1 month ago</time></p> 
      </footer> 
    </article> 
 
    <!-- In a section, footnotes or similar information can also go into a footer element --> 
    <footer class="section-footer"> 
      <p>Related sections: Events, Public holidays</p> 
    </footer> 
  </section> 
</main> 
 
<!-- Your page footer should go into a global footer element --> 
<footer class="page-footer"> 
  Copyright 2014 
</footer>

alt標簽不為空

<img>標簽的 alt 屬性指定了替代文本，用于在圖像無法顯示或者用戶禁用圖像顯示時，代替圖像顯示在瀏覽器中的內容。假設由于下列原因用戶無法查看圖像，alt 屬性可以為圖像提供替代的信息：

網速太慢
src 屬性中的錯誤
瀏覽器禁用圖像
用戶使用的是屏幕閱讀器

從SEO角度考慮，瀏覽器的爬蟲爬不到圖片的內容，所以我們要有文字告訴爬蟲圖片的內容

結構、表現、行為三者分離

盡量在文檔和模板中只包含結構性的 HTML；而將所有表現代碼，移入樣式表中；將所有動作行為，移入腳本之中。在此之外，為使得它們之間的聯系盡可能的小，在文檔和模板中也盡量少地引入樣式和腳本文件。建議：

不使用超過一到兩張樣式表
不使用超過一到兩個腳本（學會用合并腳本）
不使用行內樣式（<style>.no-good {}</style>）
不在元素上使用 style 屬性（<hr style="border-top: 5px solid black">）
不使用行內腳本（<script>alert('no good')</script>）
不使用表象元素（i.e. <b>, <u>, <center>, <font>, <b>）
不使用表象 class 名（i.e. red, left, center）

HTML只關注內容

HTML只顯示展示內容信息
不要引入一些特定的 HTML 結構來解決一些視覺設計問題
不要將img元素當做專門用來做視覺設計的元素
樣式上的問題應該使用css解決

不推薦：

<!-- We should not introduce an additional element just to solve a design problem  --> 
<span class="text-box"> 
  <span class="square"></span> 
  See the square next to me? 
</span> 
css 代碼: 
.text-box > .square { 
  display: inline-block; 
  width: 1rem; 
  height: 1rem; 
  background-color: red; 
}

推薦

html 代碼: 
<!-- That's clean markup! --> 
<span class="text-box"> 
  See the square next to me? 
</span> 
css 代碼: 
/* We use a :before pseudo element to solve the design problem of placing a colored square in front of the text content */ 
.text-box:before { 
  content: ""; 
  display: inline-block; 
  width: 1rem; 
  height: 1rem; 
  background-color: red; 
}

圖片和 SVG 圖形能被引入到 HTML 中的唯一理由是它們呈現出了與內容相關的一些信息。

不推薦

html 代碼: 
<!-- Content images should never be used for design elements!  --> 
<span class="text-box"> 
  <img src="square.svg" alt="Square" /> 
  See the square next to me? 
</span>

推薦

html 代碼: 
<!-- That's clean markup! --> 
<span class="text-box"> 
  See the square next to me? 
</span> 
css 代碼: 
/* We use a :before pseudo element with a background image to solve the problem */ 
.text-box:before { 
  content: ""; 
  display: inline-block; 
  width: 1rem; 
  height: 1rem; 
  background: url(square.svg) no-repeat; 
  background-size: 100%; 
}

js規范

避免全局命名空間污染

防止全局命名空間被污染，我們通常的做法是將代碼包裹成一個 IIFE(Immediately-Invoked Function Expression)，創建獨立隔絕的定義域。也使得內存在執行完后立即釋放。

IIFE 還可確保你的代碼不會輕易被其它全局命名空間里的代碼所修改（i.e. 第三方庫，window 引用，被覆蓋的未定義的關鍵字等等）。不推薦:

var x = 10, 
    y = 100; 
 
// Declaring variables in the global scope is resulting in global scope pollution. All variables declared like this 
// will be stored in the window object. This is very unclean and needs to be avoided. 
console.log(window.x + ' ' + window.y);

推薦

// We declare a IIFE and pass parameters into the function that we will use from the global space 
(function(log, w, undefined){ 
  'use strict'; 
 
  var x = 10, 
      y = 100; 
 
  // Will output 'true true' 
  log((w.x === undefined) + ' ' + (w.y === undefined)); 
 
}(window.console.log, window));

推薦的IIFE寫法:

(function(){ 
  'use strict'; 
 
  // Code goes here 
 
}());

如果你想引用全局變量或者是外層 IIFE 的變量，可以通過下列方式傳參：

(function($, w, d){ 
  'use strict'; 
 
  $(function() { 
    w.alert(d.querySelectorAll('div').length); 
  }); 
}(jQuery, window, document));復制代碼

嚴格模式

ECMAScript 5 嚴格模式可在整個腳本或獨個方法內被激活。它對應不同的 javascript 語境會做更加嚴格的錯誤檢查。嚴格模式也確保了 javascript 代碼更加的健壯，運行的也更加快速。

嚴格模式會阻止使用在未來很可能被引入的預留關鍵字。

你應該在你的腳本中啟用嚴格模式，最好是在獨立的 IIFE 中應用它。避免在你的腳本第一行使用它而導致你的所有腳本都啟動了嚴格模式，這有可能會引發一些第三方類庫的問題。

變量聲明

總是使用 var 來聲明變量。如不指定 var，變量將被隱式地聲明為全局變量，例如

var a = b = 0; //b會被隱式的創建為全局變量復制代碼

所以，請總是使用 var 來聲明變量，并且使用單var模式（將所有的變量在函數最前面只使用一個var定義）。例如：

(function (){ 
  'use strict' 
  var a = 0, 
      b = 0, 
      c = 0, 
      i, 
      j, 
      myObject(); 
}())

采用嚴格模式帶來的好處是，當你手誤輸入錯誤的變量名時，它可以通過報錯信息來幫助你定位錯誤出處。

js聲明提前

javascript會自動將函數作用域內的變量和方法的定義提前（只是提前聲明，賦值還是在原處）例如：

(function(log){ 
  'use strict'; 
 
  var a = 10; 
 
  for(var i = 0; i < a; i++) { 
    var b = i * i; 
    log(b); 
  } 
 
  if(a === 10) { 
    var f = function() { 
      log(a); 
    }; 
    f(); 
  } 
 
  function x() { 
    log('Mr. X!'); 
  } 
  x(); 
 
}(window.console.log));

提升后的js

(function(log){ 
  'use strict'; 
  // All variables used in the closure will be hoisted to the top of the function 
  var a, 
      i, 
      b, 
      f; 
  // All functions in the closure will be hoisted to the top 
  function x() { 
    log('Mr. X!'); 
  } 
 
  a = 10; 
 
  for(i = 0; i < a; i++) { 
    b = i * i; 
    log(b); 
  } 
 
  if(a === 10) { 
    // Function assignments will only result in hoisted variables but the function body will not be hoisted 
    // Only by using a real function declaration the whole function will be hoisted with its body 
    f = function() { 
      log(a); 
    }; 
    f(); 
  } 
 
  x(); 
 
}(window.console.log));

使用嚴格等

總是使用 === 精確的比較操作符，避免在判斷的過程中，由 JavaScript 的強制類型轉換所造成的困擾。例如：

(function(log){ 
  'use strict'; 
 
  log('0' == 0); // true 
  log('' == false); // true 
  log('1' == true); // true 
  log(null == undefined); // true 
 
  var x = { 
    valueOf: function() { 
      return 'X'; 
    } 
  }; 
 
  log(x == 'X'); 
 
}(window.console.log));

等同== 和嚴格等===的區別

==，兩邊值類型不同的時候，要先進行類型轉換，再比較。
===，不做類型轉換，類型不同的一定不等。

==等同操作符

如果兩個值具有相同類型，會進行===比較，返回===的比較值
如果兩個值不具有相同類型，也有可能返回true
如果一個值是null另一個值是undefined，返回true
如果一個值是string另個是number，會把string轉換成number再進行比較
如果一個值是true，會把它轉成1再比較，false會轉成0

console.log( false == null )      // false 
console.log( false == undefined ) // false 
console.log( false == 0 )         // true 
console.log( false == '' )        // true 
console.log( false == NaN )       // false 
 
console.log( null == undefined ) // true 
console.log( null == 0 )         // false 
console.log( null == '' )        // false 
console.log( null == NaN )       // false 
 
console.log( undefined == 0)   // false 
console.log( undefined == '')  // false 
console.log( undefined == NaN) // false 
 
console.log( 0 == '' )  // true 
console.log( 0 == NaN ) // false

總結一下==

false 除了和自身比較為 true 外，和 0，"" 比較也為 true
null 只和 undefined 比較時為 true，反過來 undefined 也僅和 null 比較為 true，沒有第二個
0 除了和 false 比較為 true，還有空字符串 ''" 和空數組 []
空字符串 '' 除了和 false 比較為 true，還有一個數字 0

==, >, <, +, -, ... 這些操作符所造成的隱式類型轉換都是無副作用的，它不會改變變量本身保存的值。，但是，如果你覆寫某個對象的 valueOf/toString的話，==就會產生副作用.

例如：

Array.prototype.valueOf = function() { 
  this[0]++; 
  return this; 
} 
var x = [1, 2, 3]; 
x == 0; 
console.log(x);   // [2, 2, 3]復制代碼

===操作符：

要是兩個值類型不同，返回false
要是兩個值都是number類型，并且數值相同，返回true
要是兩個值都是stirng，并且兩個值的String內容相同，返回true
要是兩個值都是true或者都是false，返回true
要是兩個值都是指向相同的Object，Arraya或者function，返回true
要是兩個值都是null或者都是undefined，返回true

真假判斷

js中以下內容為假：
false
null
undefined
0
'' (空字符串)
NaN

設置默認參數

輯操作符 || 和 && 也可被用來返回布爾值。如果操作對象為非布爾對象，那每個表達式將會被自左向右地做真假判斷。基于此操作，最終總有一個表達式被返回回來。這在變量賦值時，是可以用來簡化你的代碼的。例如:如果x不存在且y不存在，x=1；如果x存在y存在，x = y

if(!x) { 
  if(!y) { 
    x = 1; 
  } else { 
    x = y; 
  } 
}

等同于：

 x = x || y || 1;復制代碼

這一小技巧經常用來給方法設定默認的參數。

(function(log){ 
  'use strict'; 
 
  function multiply(a, b) { 
    a = a || 1; 
    b = b || 1; 
 
    log('Result ' + a * b); 
  } 
 
  multiply(); // Result 1 
  multiply(10); // Result 10 
  multiply(3, NaN); // Result 3 
  multiply(9, 5); // Result 45 
 
}(window.console.log));

不使用eval()函數

就如eval的字面意思來說，惡魔，使用eval()函數會帶來安全隱患。eval()函數的作用是返回任意字符串，當作js代碼來處理。

this關鍵字

只在對象構造器、方法和在設定的閉包中使用 this 關鍵字。this 的語義在此有些誤導。它時而指向全局對象（大多數時），時而指向調用者的定義域（在 eval 中），時而指向 DOM 樹中的某一節點（當用事件處理綁定到 HTML 屬性上時），時而指向一個新創建的對象（在構造器中），還時而指向其它的一些對象（如果函數被 call() 和 apply() 執行和調用時）。

正因為它是如此容易地被搞錯，請限制它的使用場景：

在構造函數中
在對象的方法中（包括由此創建出的閉包內）

首選函數式風格

函數式編程讓你可以簡化代碼并縮減維護成本，因為它容易復用，又適當地解耦和更少的依賴。

接下來的例子中，在一組數字求和的同一問題上，比較了兩種解決方案。第一個例子是經典的程序處理，而第二個例子則是采用了函數式編程和 ECMA Script 5.1 的數組方法。不推薦

(function(log){ 
  'use strict'; 
 
  var arr = [10, 3, 7, 9, 100, 20], 
      sum = 0, 
      i; 
 
 
  for(i = 0; i < arr.length; i++) { 
    sum += arr[i]; 
  } 
 
  log('The sum of array ' + arr + ' is: ' + sum) 
 
}(window.console.log));

修改內建對象的原型鏈

修改內建的諸如 Object.prototype 和 Array.prototype 是被嚴厲禁止的。修改其它的內建對象比如 Function.prototype，雖危害沒那么大，但始終還是會導致在開發過程中難以 debug 的問題，應當也要避免。

三元條件判斷（if 的快捷方法）

用三元操作符分配或返回語句。在比較簡單的情況下使用，避免在復雜的情況下使用。沒人愿意用 10 行三元操作符把自己的腦子繞暈。不推薦：

if(x === 10) { 
  return 'valid'; 
} else { 
  return 'invalid'; 
}

推薦：

return x === 10 ? 'valid' : 'invalid'

JSHint

在js規范中，有很多規范都是樣式上的規范而不是邏輯上的規范，比如盡量使用===而不是==，我們可以使用JSHint或者JSLint，Javascript代碼驗證工具，這種工具可以檢查你的代碼并提供相關的代碼改進意見。我個人使用的是JSHint，所以就以這個為例

webstorm內置JSHint

對于ws愛好者來說，我沒有用過其他的編譯器，ws基本上能滿足你的所有需求（最新的ws集成了vue）。在Settings => language & frameworks => JavaScript => Code Quality Tolls => JSHint

前端開發規范：命名規范、html規范、css規范、js規范

webstorm中的jshint

這些規范都是什么意思呢，這里列出一些常用的，剩下的大家可以參考官方文檔

前端開發規范：命名規范、html規范、css規范、js規范

css規范

id和class的命名

ID和class的名稱總是使用可以反應元素目的和用途的名稱，或其他通用的名稱，代替表象和晦澀難懂的名稱不推薦 :

.fw-800 { 
  font-weight: 800; 
} 
 
.red { 
  color: red; 
}

合理的使用ID

一般情況下ID不應該被用于樣式，并且ID的權重很高，所以不使用ID解決樣式的問題，而是使用class不推薦：

#content .title { 
  font-size: 2em; 
}

推薦：

.content .title { 
  font-size: 2em; 
}

css選擇器中避免使用標簽名

從結構、表現、行為分離的原則來看，應該盡量避免css中出現HTML標簽，并且在css選擇器中出現標簽名會存在潛在的問題。

使用子選擇器

很多前端開發人員寫選擇器鏈的時候不使用直接子選擇器（注：直接子選擇器和后代選擇器的區別）。有時，這可能會導致疼痛的設計問題并且有時候可能會很耗性能。然而，在任何情況下，這是一個非常不好的做法。如果你不寫很通用的，需要匹配到DOM末端的選擇器，你應該總是考慮直接子選擇器。不推薦:

.content .title { 
  font-size: 2rem; 
}

推薦

.content > .title { 
  font-size: 2rem; 
}

盡量使用縮寫屬性

盡量使用縮寫屬性對于代碼效率和可讀性是很有用的，比如font屬性。不推薦：

border-top-style: none; 
font-family: palatino, georgia, serif; 
font-size: 100%; 
line-height: 1.6; 
padding-bottom: 2em; 
padding-left: 1em; 
padding-right: 1em; 
padding-top: 0;

推薦：

border-top: 0; 
font: 100%/1.6 palatino, georgia, serif; 
padding: 0 1em 2em;

0后面不帶單位

省略0后面的單位，不推薦：

padding-bottom: 0px; 
margin: 0em;

推薦：

padding-bottom: 0; 
margin: 0;

屬性格式

為了保證一致性和可擴展性，每個聲明應該用分號結束，每個聲明換行。
屬性名的冒號后使用一個空格。出于一致性的原因，
屬性和值（但屬性和冒號之間沒有空格）的之間始終使用一個空格。
每個選擇器和屬性聲明總是使用新的一行。
屬性選擇器或屬性值用雙引號（””），而不是單引號（”）括起來。
URI值（url()）不要使用引號。

作為最佳實踐，我們應該遵循以下順序（應該按照下表的順序）：

結構性屬性：

display
position, left, top, right etc.
overflow, float, clear etc.
margin, padding

表現性屬性：

background, border etc.
font, text

不推薦：

.box { 
 font-family: 'Arial', sans-serif; 
 border: 3px solid #ddd; 
 left: 30%; 
 position: absolute; 
 text-transform: uppercase; 
 background-color: #eee; 
 right: 30%; 
 isplay: block; 
 font-size: 1.5rem; 
 overflow: hidden; 
 padding: 1em; 
 margin: 1em;

推薦：

.box { 
  display: block; 
  position: absolute; 
  left: 30%; 
  right: 30%; 
  overflow: hidden; 
  margin: 1em; 
  padding: 1em; 
  background-color: #eee; 
  border: 3px solid #ddd; 
  font-family: 'Arial', sans-serif; 
  font-size: 1.5rem; 
  text-transform: uppercase; 
}

責任編輯：龐桂玉來源：今日頭條

前端命名規范 html規范

成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

前端開發規范：命名規范、html規范、css規范、js規范

命名

駝峰式命名法介紹

變量命名

函數

常量

類的成員

注釋規范

單行注釋 ( // )

多行注釋 ( / 注釋說明 / )

函數 ( 方法 ) 注釋

HTML規范

文檔規范

腳本加載

語義化

alt標簽不為空

結構、表現、行為三者分離

HTML只關注內容

js規范

避免全局命名空間污染

嚴格模式

變量聲明

js聲明提前

使用嚴格等

等同== 和嚴格等===的區別

真假判斷

設置默認參數

不使用eval()函數

this關鍵字

首選函數式風格

修改內建對象的原型鏈

三元條件判斷（if 的快捷方法）

JSHint

webstorm內置JSHint

css規范

id和class的命名

合理的使用ID

css選擇器中避免使用標簽名

使用子選擇器

盡量使用縮寫屬性

0后面不帶單位

屬性格式