寫好你的JavaScript

tuniutech 發布于2019-08-20 14:48 / 2254人閱讀

摘要：關于微信公眾號前端呼啦圈我的博客勞卜的博客知乎專欄前端呼啦圈前言在實際工作中，我們應該經常會看到一些功能上沒有問題，但編碼風格和規范卻十分糟糕的代碼，這往往會讓人不敢再往下閱讀，甚至會影響閱讀者一天的心情。本文內容參考自編寫可維護的一書。

關于

微信公眾號：前端呼啦圈（Love-FED）

我的博客：勞卜的博客

知乎專欄：前端呼啦圈

前言

在實際工作中，我們應該經常會看到一些功能上沒有問題，但編碼風格和規范卻十分糟糕的代碼，這往往會讓人不敢再往下閱讀，甚至會影響閱讀者一天的心情。這些代碼不僅不易閱讀，而且難以維護，它們一般會出自剛入門的編程新手，也會出自工作了好幾年的老程序員手下。因此本文的目的在于幫助那些沒有養成良好的編碼風格，缺乏相應編碼規范意識的JavaScript學習者們改善他們的編碼形象。

編碼形象

以上我提出了編碼形象的概念，我個人認為：

編碼形象 = 編碼風格 +　編碼規范

一個良好的編碼形象就等于一個穿著得體的青年，對于程序員來說這是同行了解你優秀能力的最直接最簡單的方式。

我們來看一下一段糟糕的編碼形象：

//打個招呼
function func(){
    var age=18,sex="man";
    var greeting="hello";
    if(age<=18&&sex=="man"){
        console.log(greeting+"little boy")
    }
    
    ...
}
func()

上方代碼整體縮在了一起，缺乏規范意識，閱讀體驗很差，不忍直視。

再來看一段良好的代碼形象：

// 打個招呼
function greetFn() {
    var age = 18,
        sex = "man",
        greeting = "hello";
        
    if (age <= 18 && sex === "man") {
        console.log(greeting + "little boy");
    }
    
    ...
};

greetFn();

上方的代碼是不是感覺舒服多了？

由此可見養成一個良好的編碼形象是至關重要的，而本文主要講解的是基于JavaScript的編碼形象，即基于JavaScript的編碼風格和編碼規范。

那么什么是編碼風格，什么是編碼規范，兩者的區別又是什么？

編碼風格

首先編碼風格既然是風格，就沒有對錯之分。就好比每個人的穿著打扮不同，有的人穿的比較得體，有的人穿的比較隨意而已。

而在JavaScript編碼風格中，也有一套比較得體的風格，尤其在團隊開發中，我們不能隨意的書寫屬于自己的風格。

下面就列舉幾種隨意的編碼風格，并將其與良好的編碼風格進行對比。

1.合理注釋

// 不推薦的寫法
var name = "勞卜";//代碼和注釋之間沒有間隔

if (name) {
    /*
     *注釋之前無空行
     *星號后面無空格
     */
}

// 推薦的寫法
var name = "勞卜"; // 代碼和注釋之間有間隔

if (name) {

    /*
     * 注釋之前有空行
     * 星號后面有空格
     */
}

2.合理間隔

// 不推薦的寫法
var name="勞卜"; // 等號和兩側之間沒有間隔

// if塊級語句間沒有間隔
if(name){
    console.log("hello");
}

// 推薦的寫法
var name = "勞卜"; // 等號和兩側之間有間隔

// if塊級語句間有間隔
if (name) {
    console.log("hello");
}

3.合理縮進

// 不推薦的寫法：沒有合理縮進
function getName() {
console.log("勞卜"); 
}

// 推薦的寫法：合理縮進
function getName() {
    console.log("勞卜");
}

4.合理空行

// 不推薦的寫法: 代碼功能塊之間沒有空行
function getName() {
    var name = "勞卜";
    if (name) {
        console.log("hello");
    }
}

// 推薦的寫法：代碼功能塊之間有空行
function getName() {
    var name = "勞卜";
    
    if (name) {
        console.log("hello");
    }
}

5.合理命名

// 不推薦的寫法
var getName = "勞卜"; // 變量命名前綴為動詞

// 函數命名前綴為名詞
function name() {
   console.log("hello");
}

// 推薦的寫法
var name = "勞卜"; // 變量命名前綴為名詞

// 函數命名前綴為動詞
function getName() {
   console.log("hello");
}

6.合理聲明

// 不推薦的寫法：函數在聲明之前使用
getName(); 

function getName() {
    console.log("hello");
}

// 推薦的寫法：函數在聲明之后使用
function getName() {
    console.log("hello");
}

getName();

7.合理結尾

// 不推薦的寫法：沒有使用分號結尾
var name = "勞卜" 

var getName = function() {
    console.log("hello")
}

// 推薦的寫法：使用分號結尾
var name = "勞卜"; 

var getName = function() {
    console.log("hello");
};

以上主要列舉了7個比較常見的編碼風格的例子進行了比較，在推薦的寫法和不推薦的寫法中兩者并沒有對錯之分，只是推薦的寫法相比較而言更容易閱讀和維護，更適用于團隊開發，也是良好編碼形象的體現。

編碼規范

對于編碼規范，既然是規范，那我們就應該按照一定的規則來編寫。隨意編寫違反編碼規范的代碼，可能會導致程序的出錯和潛在的bug，因此其相對于編碼風格來說應該更加嚴謹，也有人會把編碼風格包含在編碼規范之中。

下面就列舉幾個常見的實例代碼：

1.比較參數

// 不推薦的寫法：==和!=比較時會進行類型轉換，應盡量避免使用
var num = 123;

if (num == "123") {
    console.log(num);
} else if (num != "321") {
    console.log("321");
}

// 推薦的寫法：使用===和!==來進行比較
var num = 123;

if (num === "123") {
    console.log(num);
} else if (num !== "321") {
    console.log("321");
}

2.包裹if語句

// 不推薦的寫法：if語句不用大話號包裹會出現潛在bug
var num = 123;

if (num === "123")
    console.log(num);

// 推薦的寫法：if語句用大話號包裹
var num = 123;

if (num === "123") {
    console.log(num);
}

3.慎用eval

// 不推薦的寫法：應避免使用eval，不安全，非常耗性能（一次解析成js語句，一次執行）
var json = "{"name": "勞卜", "func": alert("hello")}";

eval("(" + json + ")"); // 彈出“hello”

// 推薦的寫法
var json = "{"name": "勞卜", "func": alert("hello")}";

JSON.parse(json); // 校驗報錯

4.判斷類型

// 不推薦的寫法：用typeof來判斷構造函數創建的對象
var str = new String("勞卜"); 

console.log(typeof str); // "object"

// 推薦的寫法：用instanceof來判斷構造函數創建的對象
var str = new String("勞卜"); 

console.log(str instanceof String); // true

5.檢測屬性

// 不推薦的寫法：使用undefined和null來檢測一個屬性是否存在
if (obj["name"] !== undefined) {
    console.log("name屬性存在"); // 若obj.name為undefined時則會導致判斷出錯
}

if (obj["name"] !== null) {
    console.log("name屬性存在"); // 若obj.name為null時則會導致判斷出錯
}

// 推薦的寫法：使用in運算符來檢測對象屬性是否存在，使用hasOwnProperty方法來檢測不包含原型鏈上的對象屬性是否存在
if ("name" in obj) {
    console.log("name屬性存在");
}

if (obj.hasOwnProperty("name")) {
    console.log("name屬性存在");
}

以上主要列舉了5個常見的編碼規范的例子，合理地規范自己的代碼能夠很大程度上減少不必要的維護成本和潛在的bug風險，對于JavaScript學習者來說應該銘記于心。

結語

“程序是寫給人讀的，只是偶爾讓計算機執行一下。”我們不能為了貪圖一時的方便而親手毀了自己的代碼形象，這會給他人和整個項目帶來不必要的麻煩。

本文內容參考自《編寫可維護的JavaScript》一書。

如果覺得本文對你有幫助，可以關注我的微信公眾號，來這里聊點關于前端的事情。

云服務器 GPU云服務器如何寫好python 萬你的擴展你的你的看法

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/81926.html

React

摘要：而我只知道有自己的虛擬，它會對比虛擬和真實的差別，然后在適當的時機更新頁面。函數的第一個參數只能是一個標簽，不能是并列的兩個標簽。第一個添加了的屬性，該屬性值指向，意思是該組件名為的靜態屬性。網頁總是一個鏈接著另一個的，React一大優勢在于每次鏈接到另一個頁面上去的時候，不需要向傳統頁面一樣，得銷毀所有代碼，重新渲染新頁面的代碼，而只在一個頁面上展現新的內容——單頁頁面。 Reac...

ningwang 2019-08-23 15:15 評論0 收藏0
React

摘要：而我只知道有自己的虛擬，它會對比虛擬和真實的差別，然后在適當的時機更新頁面。函數的第一個參數只能是一個標簽，不能是并列的兩個標簽。第一個添加了的屬性，該屬性值指向，意思是該組件名為的靜態屬性。網頁總是一個鏈接著另一個的，React一大優勢在于每次鏈接到另一個頁面上去的時候，不需要向傳統頁面一樣，得銷毀所有代碼，重新渲染新頁面的代碼，而只在一個頁面上展現新的內容——單頁頁面。 Reac...

tain335 2019-08-02 14:17 評論0 收藏0
談談JavaScript異步代碼優化

摘要：異步問題回調地獄首先，我們來看下異步編程中最常見的一種問題，便是回調地獄。同時使用也是異步編程最基礎和核心的一種解決思路。基于，目前也被廣泛運用，其是異步編程的一種解決方案，比傳統的回調函數解決方案更合理和強大。關于微信公眾號：前端呼啦圈（Love-FED）我的博客：勞卜的博客知乎專欄：前端呼啦圈前言在實際編碼中，我們經常會遇到Javascript代碼異步執行的場景...

chnmagnus 2019-08-22 17:08 評論0 收藏0
前端開發收集 - 收藏集 - 掘金

摘要：責編現代化的方式開發一個圖片上傳工具前端掘金對于圖片上傳，大家一定不陌生。之深入事件機制前端掘金事件綁定的方式原生的事件綁定方式有幾種想必有很多朋友說種目前，在本人目前的研究中，只有兩種半兩種半還有半種的且聽我道來。 Ajax 與數據傳輸 - 前端 - 掘金背景在沒有ajax之前，前端與后臺傳數據都是靠表單傳輸，使用表單的方法傳輸數據有一個比較大的問題就是每次提交數據都會刷新頁面，用...

ygyooo 2019-08-20 17:15 評論0 收藏0
Prettier+VScode 治好你的代碼潔癖

摘要：忍無可忍只能拔槍相見了。而只關心格式化文件最大長度混合標簽和空格引用樣式等。可見，代碼格式統一的問題，交給再合適不過了。和配合使用，風味更佳。我的配置文件如下到此，安裝完畢，使用就可格式化代碼。兩者配合才能使項目代碼優雅健壯試想一個多人開發的項目，每次同步代碼，看到各個風格迥異，換行空格混亂，4格，2格縮進交替上演的代碼文件，分分鐘逼死強迫癥啊。忍無可忍只能拔槍相見了~~。統一的代碼...

qc1iu 2019-08-23 12:13 評論0 收藏0