文共5024字，預計學習時長15分鐘

今天，小芯給大家分享一些提高JavaScript編碼能力的應用方法，學習并運用到實踐中，你也可以成為編碼熟練工喲~

編輯器

目前，編輯器種類繁多，人們不知道選擇哪種編輯器來提高工作效率。

于我而言，除了使用Android Studio或使用Xcode的iOS所需的Android代碼外，我大多只使用Visual Studio Code。

這是由Microsoft開發的編輯器。這是Microsoft開發的，聽起來不錯！！！幾乎支持所有語言，無數附加插件，AI代碼建議，漂亮的界面和淺色調（不是Sublime Text，但…仍然是淺色）

過去，我只使用Sublime Text（當時不流行VSCode）。大量的插件（將在下文討論）為我節省了很多時間，例如自動檢測并修復錯誤，格式代碼，git鏡頭，終端等……，因為不再需要解決編碼時常見的小錯誤。

如果編寫PHP，一定會喜歡PHPStorm。如果編寫Python，則一定會喜歡PyCharm。毋庸置疑，這些編輯器功能強大，但是，只支持一種語言。本人是一個全棧開發人員，具有JavaScript、HTML、PHP、NodeJS和React Docker的經驗...我使用的是VSCode，因為它功能非常強大，支持很多插件，尤其是自動完成功能非常不錯。

對ESLint一見鐘情

在語法錯誤上，我花費了最多時間，同時也最讓我沮喪，諸如未聲明變量/函數，空指針，缺少重音符號之類的錯誤……隨著代碼越來越多，一次必須讀取數十個文件，這很容易讓眼睛疲倦，頭腦一團亂，手也開始顫抖地鍵入每一行代碼，從而容易粗心大意并犯錯。

在使用 ESLint時，這個插件可以幫助找出錯誤，檢查語法和格式代碼，因此能夠降低編碼時出現的漏洞，以及根據現行標準格式化時，能讓代碼看上去更好看。ESLint還支持其他許多老大哥：JavaScript，React，Vue等

尤其是結合使用ESLint和VSCode，這搭配簡直完美。可以立刻檢查代碼鍵入，查看是否存在錯誤或語法問題，并提供有關如何使用函數和變量以實現最佳效果的建議。還有自動格式的代碼，你一定會喜歡上它。

除了ESLint，還可以使用Prettier來格式化代碼，但是本人更喜歡ESLint，因為可支持錯誤檢測和提供最佳代碼建議。

最佳目錄結構

我最近開始“接受”并告訴自己一件事：

不要從一開始就嘗試優化項目結構

過去，開始著手一個項目時，不論項目或大或小，我總是會花很多時間選擇最佳的項目結構。我在谷歌上看了各種“ NodeJS文件夾結構的最佳實踐”，“ ReactJS代碼結構……”，但仍然想知道這個結構是否是最佳的，我應該選擇這個編碼框架嗎？這非常耗時。

而且我還意識到，盡管起初我嘗試使用一種本來很好的結構，但是幾天后，代碼卻變得一團糟。因為我的系統思維不好，所以起初代碼寫得有多么漂亮并不重要，最后還是出問題了。

不要過多地考慮選擇哪種架構，以及從一開始要如何去組織。選擇一個方向或一個庫、一個框架，并開始進行研究，一邊進行一邊改進，這樣更好也更實用。

如果對結構良好的項目感興趣，我會分享一個名為NestJS的NodeJS框架，我閱讀了許多相關文檔，發現它們的體系結構非常好（非常類似于AngularJS，盡管我不太喜歡Angular）

覺得代碼“壞掉”時，使用Console.log

我很確定，console.log是我在編寫JavaScript時使用最多的。這一主要目的是查看感興趣的數據是否真實。

我個人認為，無論使用哪種語言，編程都離不開數據，因此如果看到任何令人不安的代碼，該代碼也許不正確，就應使用console.log進行確認。

也有很多人認為調試器應該看起來更專業。谷歌還支持將Debug放在代碼行中，以獲得更好的了解。實際上，這對我個人而言不是必需的，console.log還會注意到代碼中的哪一行，使用console.log越快，就會更加方便。我還發現在臉書上的一些世界著名編碼專家，他們仍然使用console .log

還應該注意到，console.log完成后，請檢查所有內容，然后再將其刪除，不要放在git上。這會讓人沮喪，看了眼睛疼（像我一樣）

點評

在編碼過程中，很多時候都需要冗長而復雜的代碼。人們擔心，經過很長一段時間再次閱讀這些代碼時，就可能不知道這段代碼是做什么的。或者懷著人道主義的心，希望以后閱讀這個代碼的人，可以明白代碼的作用。

就個人而言，我發現寫評論真的很有用，尤其是該項目有很多人參與的時候。而且，我們不想每次不懂時，都跑去問寫這個代碼的朋友，而這個朋友也忙于修復測試人員布置的大量錯誤。而如果代碼本身可以解釋，那么之后看到該代碼的人就可以馬上就搞清楚，還能節省時間。

但是評論也必須看起來合理舒適。不必評論所有內容。這有時會讓代碼難以閱讀，還讓人的眼睛很不舒服。

在編寫代碼時，我會選擇變量/函數的名稱，便于理解，不要讓長的類/函數處理過多內容。相反，我會拆分成較小的類/函數（但不要拆分太多，拆分必須合理，不要再次讓人看著眼睛痛）。在需要時發表評論，練習編寫代碼，以便進行“自我解釋”。只需讀一讀，知道其中的作用即可。

使用ES6、7、8、9標準

JavaScript是一門快速發展的語言，另外還添加了許多強大的功能/庫。據我所知，每年人們都會發布名為ECMAScript或ES的JavaScript標準。這些標準中的每一個都包含著JavaScript內置的新功能。

· 2015 ECMAScript 6（ES6）

· 2016 ECMAScript 7（ES7）

· 2015 ECMAScript 8（ES8）

· 2015 ECMAScript 9（ES9）

· 2015 ECMAScript 10（ES10）

· ….

因此，如果利用ECMA的強大功能，代碼將比僅使用傳統的for和if，while循環看起來更好，更加優化并且看上去更酷（就像本文的作者這般可愛）

以下是我在編碼時最常用的一些函數/運算符：

跳過 Promise / Callback，直接了解Async / Await

Promise / CallbackWhile

編碼的缺點是，我們必須大量使用API。從后端或第三方調用API以獲取數據和顯示時，需要執行以下操作：

如果只想在成功檢索用戶列表之后才調用另一個API，那么通常需要執行以下操作：

想按順序調用一系列API時，壞事就來了。當項目規模擴大，處理的請求越來越復雜時，這就是所看到的：

Async / await 是救星

自ES6（2015）起，async/await作為Promise/callbacks替代方法引入，用于處理異步操作。async / await的好處就在于有助于編寫看起來像同步的異步代碼，這些代碼逐行運行，看起來非常整潔。

可以使用async / await重寫上面的代碼：

有一些注意事項：

· await總出現在async之后

· 使用try / catch來捕獲異步函數中的錯誤處理操作

· await的本質是等待Promise返回值，因此使用太多await有時會使應用變慢。

使用async / await而不使用常規Promise / Callback的另一個好處是，使用try / catch可以發現async / await錯誤。還會發現try / catchblock中的所有其他錯誤，而不僅僅是async/await

使用Typescript提高代碼質量

故事開始了……

我第一次進行編程用的是C語言，然后是Java。這些語言功能強大，需要極其嚴格的代碼，需要對數據類型（字符串，布爾值，…）或訪問規范（公共，私有，受保護的…）進行清晰完整的定義。那天我非常厭倦運行代碼，因為我不知道它是公共的還是私有的，數據類型是什么，于是就一直運行到報告錯誤為止。

之后，開始使用JavaScript（或PHP，Python），無論數據類型如何，它都被大大簡化。只需聲明變量就可以使用：

令x =

1const test ='This is a test'

const arr = [1,2,3,4,5]

這也是我從一開始就喜歡JS的一個原因，因為語法非常“自由”，不那么混亂，代碼看起來干凈漂亮。但是生活并不像夢想。漸漸地，我意識到，當項目有很多人編寫代碼之后，就會重新閱讀代碼。真的很糾結。因為我不知道這個變量是什么，該函數將返回什么類型的數據？ …

const var1 = db.column1

const var2 = db.column2

const var3 = db.column3

const var4 = db.column4

那現在怎么辦？？當然是使用 console.log

const var1 = db.column1

console.log（var1）//->string

const var2 = db.column2

console.log（var2）//->boolean（true / false）

const var3 = db.column3

console.log（var3）//- > number

const var4 = db.column4

console.log（var4）//->array

這只會浪費時間，未來我不太可能再來閱讀代碼，而且新的代碼讀者也不會理解。然后，我或是其他讀者必須做幾十個console.log語句才能理解，該代碼是用來做什么的？

Typescript解決了這個問題

在我看來，TypeScript是JavaScript的“升級版本”。現在，JavaScript代碼將具有明確定義的類型（字符串，布爾值，數字等），可訪問的訪問函數（公共，私有），……以及許多其他東西。Typescript編寫的代碼將被編譯成普通的JavaScript，因此可以照常運行，不需要專門的Typescript腳本或其他的東西。看一些例子：

兩年前我聽說過TypeScript，但仍然不喜歡它，也不想使用，因為我只喜歡JavaScript的自由性。有時我想嘗試一下，但是我的眼睛很敏感，每次看到凌亂的東西時，眼睛就會更加敏感

但是不久前，我決定改用TypeScript，因為我在閱讀舊代碼或其他人的代碼時，會遇到我提到的這一頭痛問題。而且，開發人員社區傾向于使用TypeScript，并進行很好地審查。

當前，TypeScript在JavaScript開發人員中流行起來。庫或者框架（Angular，React或Vue）注重對TypeScript的支持。對于不知道的人：Vue 3絕對百分百是Typescript的重寫。同時，對于Microsoft開發的TypeScript，可以不用擔心質量和支持問題。

CI / CD-代碼->測試->部署

自動化測試

請聽我說，您正在從事的項目遲早會崩潰的。最好的處理方法就是一邊做一邊改進，始終花20％的時間用于改進。并且唯一可以確保的方法就是在進行改進時，不會產生錯誤（或產生最少的錯誤），或編寫測試。

要知道，甚至可以在編碼之前就編寫測試（Head First Java建議采用這種方式）

CI / CD —持續測試和部署

CI / CD（持續集成/持續集成），這是現在的趨勢，這種方法有助于自動連續地編寫代碼，進行測試和部署。

實際上，幾乎所有CI / CD工具都已集成到Github，GitLab，BitBucket中。因此無需擔心，需要做的是設置然后推送代碼。DevOps平臺（Github，gitlab，存儲桶）會負責其余的工作。

希望大家閱讀完本文后可以學習并找到方法提高JavaScript編碼能力。

同樣，如果你有什么提高JavaScript編碼能力的“妙招”，歡迎在評論區留言分享喲~

留言點贊關注

我們一起分享AI學習與發展的干貨

如轉載，請后臺留言，遵守轉載規范

文共5024字，預計學習時長15分鐘

今天，小芯給大家分享一些提高JavaScript編碼能力的應用方法，學習并運用到實踐中，你也可以成為編碼熟練工喲~

編輯器

目前，編輯器種類繁多，人們不知道選擇哪種編輯器來提高工作效率。

于我而言，除了使用Android Studio或使用Xcode的iOS所需的Android代碼外，我大多只使用Visual Studio Code。

這是由Microsoft開發的編輯器。這是Microsoft開發的，聽起來不錯！！！幾乎支持所有語言，無數附加插件，AI代碼建議，漂亮的界面和淺色調（不是Sublime Text，但…仍然是淺色）

過去，我只使用Sublime Text（當時不流行VSCode）。大量的插件（將在下文討論）為我節省了很多時間，例如自動檢測并修復錯誤，格式代碼，git鏡頭，終端等……，因為不再需要解決編碼時常見的小錯誤。

如果編寫PHP，一定會喜歡PHPStorm。如果編寫Python，則一定會喜歡PyCharm。毋庸置疑，這些編輯器功能強大，但是，只支持一種語言。本人是一個全棧開發人員，具有JavaScript、HTML、PHP、NodeJS和React Docker的經驗...我使用的是VSCode，因為它功能非常強大，支持很多插件，尤其是自動完成功能非常不錯。

對ESLint一見鐘情

在語法錯誤上，我花費了最多時間，同時也最讓我沮喪，諸如未聲明變量/函數，空指針，缺少重音符號之類的錯誤……隨著代碼越來越多，一次必須讀取數十個文件，這很容易讓眼睛疲倦，頭腦一團亂，手也開始顫抖地鍵入每一行代碼，從而容易粗心大意并犯錯。

在使用 ESLint時，這個插件可以幫助找出錯誤，檢查語法和格式代碼，因此能夠降低編碼時出現的漏洞，以及根據現行標準格式化時，能讓代碼看上去更好看。ESLint還支持其他許多老大哥：JavaScript，React，Vue等

尤其是結合使用ESLint和VSCode，這搭配簡直完美。可以立刻檢查代碼鍵入，查看是否存在錯誤或語法問題，并提供有關如何使用函數和變量以實現最佳效果的建議。還有自動格式的代碼，你一定會喜歡上它。

除了ESLint，還可以使用Prettier來格式化代碼，但是本人更喜歡ESLint，因為可支持錯誤檢測和提供最佳代碼建議。

最佳目錄結構

我最近開始“接受”并告訴自己一件事：

不要從一開始就嘗試優化項目結構

過去，開始著手一個項目時，不論項目或大或小，我總是會花很多時間選擇最佳的項目結構。我在谷歌上看了各種“ NodeJS文件夾結構的最佳實踐”，“ ReactJS代碼結構……”，但仍然想知道這個結構是否是最佳的，我應該選擇這個編碼框架嗎？這非常耗時。

而且我還意識到，盡管起初我嘗試使用一種本來很好的結構，但是幾天后，代碼卻變得一團糟。因為我的系統思維不好，所以起初代碼寫得有多么漂亮并不重要，最后還是出問題了。

不要過多地考慮選擇哪種架構，以及從一開始要如何去組織。選擇一個方向或一個庫、一個框架，并開始進行研究，一邊進行一邊改進，這樣更好也更實用。

如果對結構良好的項目感興趣，我會分享一個名為NestJS的NodeJS框架，我閱讀了許多相關文檔，發現它們的體系結構非常好（非常類似于AngularJS，盡管我不太喜歡Angular）

覺得代碼“壞掉”時，使用Console.log

我很確定，console.log是我在編寫JavaScript時使用最多的。這一主要目的是查看感興趣的數據是否真實。

我個人認為，無論使用哪種語言，編程都離不開數據，因此如果看到任何令人不安的代碼，該代碼也許不正確，就應使用console.log進行確認。

也有很多人認為調試器應該看起來更專業。谷歌還支持將Debug放在代碼行中，以獲得更好的了解。實際上，這對我個人而言不是必需的，console.log還會注意到代碼中的哪一行，使用console.log越快，就會更加方便。我還發現在臉書上的一些世界著名編碼專家，他們仍然使用console .log

還應該注意到，console.log完成后，請檢查所有內容，然后再將其刪除，不要放在git上。這會讓人沮喪，看了眼睛疼（像我一樣）

點評

在編碼過程中，很多時候都需要冗長而復雜的代碼。人們擔心，經過很長一段時間再次閱讀這些代碼時，就可能不知道這段代碼是做什么的。或者懷著人道主義的心，希望以后閱讀這個代碼的人，可以明白代碼的作用。

就個人而言，我發現寫評論真的很有用，尤其是該項目有很多人參與的時候。而且，我們不想每次不懂時，都跑去問寫這個代碼的朋友，而這個朋友也忙于修復測試人員布置的大量錯誤。而如果代碼本身可以解釋，那么之后看到該代碼的人就可以馬上就搞清楚，還能節省時間。

但是評論也必須看起來合理舒適。不必評論所有內容。這有時會讓代碼難以閱讀，還讓人的眼睛很不舒服。

在編寫代碼時，我會選擇變量/函數的名稱，便于理解，不要讓長的類/函數處理過多內容。相反，我會拆分成較小的類/函數（但不要拆分太多，拆分必須合理，不要再次讓人看著眼睛痛）。在需要時發表評論，練習編寫代碼，以便進行“自我解釋”。只需讀一讀，知道其中的作用即可。

使用ES6、7、8、9標準

JavaScript是一門快速發展的語言，另外還添加了許多強大的功能/庫。據我所知，每年人們都會發布名為ECMAScript或ES的JavaScript標準。這些標準中的每一個都包含著JavaScript內置的新功能。

· 2015 ECMAScript 6（ES6）

· 2016 ECMAScript 7（ES7）

· 2015 ECMAScript 8（ES8）

· 2015 ECMAScript 9（ES9）

· 2015 ECMAScript 10（ES10）

· ….

因此，如果利用ECMA的強大功能，代碼將比僅使用傳統的for和if，while循環看起來更好，更加優化并且看上去更酷（就像本文的作者這般可愛）

以下是我在編碼時最常用的一些函數/運算符：

跳過 Promise / Callback，直接了解Async / Await

Promise / CallbackWhile

編碼的缺點是，我們必須大量使用API。從后端或第三方調用API以獲取數據和顯示時，需要執行以下操作：

如果只想在成功檢索用戶列表之后才調用另一個API，那么通常需要執行以下操作：

想按順序調用一系列API時，壞事就來了。當項目規模擴大，處理的請求越來越復雜時，這就是所看到的：

Async / await 是救星

自ES6（2015）起，async/await作為Promise/callbacks替代方法引入，用于處理異步操作。async / await的好處就在于有助于編寫看起來像同步的異步代碼，這些代碼逐行運行，看起來非常整潔。

可以使用async / await重寫上面的代碼：

有一些注意事項：

· await總出現在async之后

· 使用try / catch來捕獲異步函數中的錯誤處理操作

· await的本質是等待Promise返回值，因此使用太多await有時會使應用變慢。

使用async / await而不使用常規Promise / Callback的另一個好處是，使用try / catch可以發現async / await錯誤。還會發現try / catchblock中的所有其他錯誤，而不僅僅是async/await

使用Typescript提高代碼質量

故事開始了……

我第一次進行編程用的是C語言，然后是Java。這些語言功能強大，需要極其嚴格的代碼，需要對數據類型（字符串，布爾值，…）或訪問規范（公共，私有，受保護的…）進行清晰完整的定義。那天我非常厭倦運行代碼，因為我不知道它是公共的還是私有的，數據類型是什么，于是就一直運行到報告錯誤為止。

之后，開始使用JavaScript（或PHP，Python），無論數據類型如何，它都被大大簡化。只需聲明變量就可以使用：

令x =

1const test ='This is a test'

const arr = [1,2,3,4,5]

這也是我從一開始就喜歡JS的一個原因，因為語法非常“自由”，不那么混亂，代碼看起來干凈漂亮。但是生活并不像夢想。漸漸地，我意識到，當項目有很多人編寫代碼之后，就會重新閱讀代碼。真的很糾結。因為我不知道這個變量是什么，該函數將返回什么類型的數據？ …

const var1 = db.column1

const var2 = db.column2

const var3 = db.column3

const var4 = db.column4

那現在怎么辦？？當然是使用 console.log

const var1 = db.column1

console.log（var1）//->string

const var2 = db.column2

console.log（var2）//->boolean（true / false）

const var3 = db.column3

console.log（var3）//- > number

const var4 = db.column4

console.log（var4）//->array

這只會浪費時間，未來我不太可能再來閱讀代碼，而且新的代碼讀者也不會理解。然后，我或是其他讀者必須做幾十個console.log語句才能理解，該代碼是用來做什么的？

Typescript解決了這個問題

在我看來，TypeScript是JavaScript的“升級版本”。現在，JavaScript代碼將具有明確定義的類型（字符串，布爾值，數字等），可訪問的訪問函數（公共，私有），……以及許多其他東西。Typescript編寫的代碼將被編譯成普通的JavaScript，因此可以照常運行，不需要專門的Typescript腳本或其他的東西。看一些例子：

兩年前我聽說過TypeScript，但仍然不喜歡它，也不想使用，因為我只喜歡JavaScript的自由性。有時我想嘗試一下，但是我的眼睛很敏感，每次看到凌亂的東西時，眼睛就會更加敏感

但是不久前，我決定改用TypeScript，因為我在閱讀舊代碼或其他人的代碼時，會遇到我提到的這一頭痛問題。而且，開發人員社區傾向于使用TypeScript，并進行很好地審查。

當前，TypeScript在JavaScript開發人員中流行起來。庫或者框架（Angular，React或Vue）注重對TypeScript的支持。對于不知道的人：Vue 3絕對百分百是Typescript的重寫。同時，對于Microsoft開發的TypeScript，可以不用擔心質量和支持問題。

CI / CD-代碼->測試->部署

自動化測試

請聽我說，您正在從事的項目遲早會崩潰的。最好的處理方法就是一邊做一邊改進，始終花20％的時間用于改進。并且唯一可以確保的方法就是在進行改進時，不會產生錯誤（或產生最少的錯誤），或編寫測試。

要知道，甚至可以在編碼之前就編寫測試（Head First Java建議采用這種方式）

CI / CD —持續測試和部署

CI / CD（持續集成/持續集成），這是現在的趨勢，這種方法有助于自動連續地編寫代碼，進行測試和部署。

實際上，幾乎所有CI / CD工具都已集成到Github，GitLab，BitBucket中。因此無需擔心，需要做的是設置然后推送代碼。DevOps平臺（Github，gitlab，存儲桶）會負責其余的工作。

希望大家閱讀完本文后可以學習并找到方法提高JavaScript編碼能力。

同樣，如果你有什么提高JavaScript編碼能力的“妙招”，歡迎在評論區留言分享喲~

留言點贊關注

我們一起分享AI學習與發展的干貨

如轉載，請后臺留言，遵守轉載規范

版規則

縮進

使用2個空格縮進

<ul>
  <li>Fantastic</li>
  <li>Great</li>
</ul>

.example {
  color: blue;
}

大小寫

只允許使用小寫。

所有的代碼都用小寫字母：適用于元素名，屬性，屬性值（除了文本和CDATA）， 選擇器，特性，特性值（除了字符串）。

<!-- 不推薦 -->
<A HREF="/">Home</A>

<!-- 推薦 -->
<img src="google.png"
alt="Google">

行為空格

建議刪除行尾白空格。

<!-- 不推薦 -->
<p>What?  </p>

<!-- 推薦 -->
<p>Yes please.</p>

常規Meta規則

編碼

如果沒有特殊需求，一般采用utf-8編碼。如果是cms站點，則遵守該站點的編碼規則。

<!-- 網頁編碼 -->
<meta charset="utf-8">

注釋

盡可能的去解釋你寫的代碼。說明該代碼包括什么、目的是什么、能做什么、為什么使用它等。

注釋是否需要詳盡，取決于項目的復雜程度。

一般單行注釋：

<!-- col -->

模塊間注釋：

<!-- news -->
<div class="news">
  <h2>News</h2>
  <p>...</p>
</div>
<!--/ news -->

循環注釋：

<ul>
  <!-- loop: new list -->
  <li>new's title 1</li>
  <li>new's title 2</li>
  <li>new's title 3</li>
  <li>new's title 4</li>
  <li>new's title 5</li>
  <!-- /loop: new list -->
</ul>

cms輸出注釋：

<!-- cms: news list -->
<ul>
  <li>new's title 1</li>
  <li>new's title 2</li>
  <li>new's title 3</li>
  <li>new's title 4</li>
  <li>new's title 5</li>
</ul>
<!-- /cms: news list -->

Tab選項卡內容注釋：

<!-- tab: news list -->
<div class="tab"></div>
<!-- /tab: news list -->

常規HTML設計規則

文檔類型

使用html5文檔聲明，不再使用XHTML（application/xhtml+xml）。

HTML5是目前所有HTML文檔類型中的首選：

<!DOCTYPE html>

HTML 的正確性

編寫有效、正確的HTML代碼，否則很難達到性能上的提升。

可以使用一些工具驗證你的代碼，如 W3C HTML validator

HTML 的語義性

根據HTML各個元素的用途而去使用它們。

<!-- 不推薦 -->
<div class="col">
  <div class="title">
news</div>
  <p>list1</p>
  <p>list2</p>
  <p>list3</p>
</div>

<!-- 推薦 -->
<div class="col">
  <h2 class="title">
news</h2>
  <p>list1</p>
  <p>list2</p>
  <p>list3</p>
</div>

部分標簽說明：

• div 主要用于布局，分割頁面的結構;
• ul/ol 主要用于無序/有序列表;
• dl/dt/dd 當頁面中出現第一行為類似標題/簡述，然后下面為詳細描述的內容時應該使用該標簽;
• span 沒有特殊的意義，可以用作排版的輔助，然后在css中定義span;
• h1-h6 標題, 根據重要性依次遞減;
• h1 最重要的標題;
• label 使表單更有親和力而且能輔助表單排版;

不推薦使用的標簽：

• font 文字的外觀，大小和顏色;
• u 文本下劃線;
• center 居中對齊;
• s 刪除線;
• strike 刪除線;
• noframes 無視框時的內容;
• iframe 定義嵌入視圖;
• isindex 不建議使用（可搜尋，使用input代替）;
• dir 目錄式列舉;
• menu 菜單列表;
• basefont 定義基本字體;
• applet 定義java程序;
• frame 定義個別視框;
• frameset 視框格式總定義;

多媒體元素降級處理

給多媒體元素，比如canvas、videos、 images增加alt屬性，提高可用性（特別是常用的img標簽，盡可量得加上alt屬性，提供圖片的描述信息）。

<!-- 不推薦 -->
<img src="world.jpg">

<!-- 推薦 -->
<img src="world.jpg"
alt="our world images">

type屬性

在樣式表和腳本的標簽中忽略type屬性。

HTML5默認type為text/css和text/javascript類型，所以沒必要指定。即便是老瀏覽器也是支持的。

<!-- 不推薦 -->
<link rel="stylesheet"
 href="//www.google.com/css/maia.css"
 type="text/css">
<script src="
 //www.google.com/
 js/gweb/analytics/autotrack.js"
 type="text/javascript">
 </script>

<!-- 推薦 -->
<link rel="stylesheet"
 href="//www.google.com/css/maia.css">
<script src="
 //www.google.com/
 js/gweb/analytics/autotrack.js">
 </script>

HTML代碼格式規則

每個塊元素、列表元素或表格元素都獨占一行，每個子元素都相對于父元素進行縮進。按設計稿劃分模塊，盡量使頁面模塊化，模塊與模塊之前要有清晰的注釋。

如上面頁面框架，推薦寫法：

<!-- hader -->
<div class="header">header</div>
<!-- /hader -->
<!-- nav -->
<div class="nav">nav</div>
<!-- /nav -->
<!-- main -->
<div class="main">
  <!-- container -->
  <div class="container">
    <!--news-->
    <div class="news">
      <h2>news<h2>
      <p>...</p>
    </div>
    <!--news-->
  </div>
  <!--/container-->
  <!--sidebar-->
  <div class="sidebar">
sidebar</div>
  <!--sidebar-->
</div>
<!--/main-->
<!--footer-->
<div class="footer">
footer</div>
<!--/footer-->

HTML與SEO

頁面良好層次

保證整個頁面在未加載樣式表時仍有較好的層次清晰的頁面結構。

<!-- 不推薦 -->
<div class="logo">My Site</div>
<div class="nav">
  <a href="#">Home</a>
  <a href="#">News</a>
  <a href="#">Mobile</a>
</div>
<div class="news">
  <div>News</div>
  <a href="#">
news list 1</a>
  <a href="#">
news list 2</a>
  <a href="#">
news list 3</a>
</div>

<!-- 推薦 -->
<h1 class="logo">My Site</h1>
<ul class="nav">
  <li><a href="#">
Home</a></li>
  <li><a href="#">
News</a></li>
  <li><a href="#">
Mobile</a></li>
</ul>
<div class="news">
  <h2>News</h2>
  <ul>
    <li><a href="#">
news list 1</a>
</li>
    <li><a href="#">
news list 2</a>
</li>
    <li><a href="#">
news list 3</a>
</li>
  </ul>
</div>

權重標簽使用

H標簽使用

• h1 權重高，體現當前網頁中相對比較重要的信息，但不宜過多，建議一個頁面只放一個;
• h2 可以做副標題;
• h3 可以做新聞列表;
• h4-h6 可做相關新聞的列表標簽屬性完整;

strong、b使用

將需要加粗的文字使用b標簽來顯示。

將需要強調的文字（主要指包含關鍵詞的信息）使用strong標簽來強調主要內容。

注：b是粗體標簽，屬于實體標簽，它所包圍的字符將被設為bold（粗體）；strong 是加重語氣標簽，屬于邏輯標簽，它的作用是加強字符語氣。

標簽屬性使用

在很多情況下，a都要使用title來說明該鏈接的相關說明或目的意義。

例如：當使用overflow隱藏掉a中的溢出文字時，該a中的title是必不可少的，它可以告訴用戶被隱藏掉的文字內容是什么；又或者當一個圖片型鏈接出現時，該a中的title同樣是必不可少的，它可以告訴用戶這個圖片鏈接是做什么用的。

注：僅在img里添加alt標簽在火狐提示文字是出不來的，alt是圖片加載失敗或未加載完全時顯示出來的提示文字，要想鼠標移上去顯示提示信息應該用title，嚴謹的寫法是img里加入alt和title這兩個標簽。

精簡代碼

代碼保持精簡，最優化，這樣搜索引擎才更喜歡。