怎么避免寫出爛代碼

yuanxin 發布于2019-08-26 13:40 / 3302人閱讀

摘要：例外回調函數生命周期函數框架級別函數說明函數的命名需要體現內部工作值變量以動詞命名容易讓人誤解為是一個匿名函數以名詞開頭，看不明白什么有什么功能時態不對規則避免使用拼音或者縮寫命名。前端代碼處理錯誤的方式一般為提示用戶有異常發生。

命名 規則：除非在小于 5 行的函數里，否則不要使用單字命名變量

說明：含義不清晰，不能做到「望文生義」

BadCode

var l = data.length;

GoodCode

// 閉包只有一行代碼，可以使用單字變量
data.map(d => d.length)

規則：不要使用名詞加數字的命名方法

說明：含義不清晰，不能做到「望文生義」

BadCode

var obj = {};
var obj2 = {...obj, key: 1};

GoodCode

var obj = {};
var objWithKey = {...obj, key: 1};

規則：應該且只有方法和函數以動詞開頭

此處動詞沒有包含時態
變量名應該是名詞或者名詞短語。

例外：

回調函數

生命周期函數

框架級別函數

getter/setter

說明：

函數的命名需要體現內部工作

值變量以動詞命名容易讓人誤解為是一個匿名函數

BadCode

// 以名詞開頭，看不明白什么有什么功能
function option() {}

// 時態不對
function updatedTime() {}

GoodCode

function selectOption() {}
function updateTime() {}

規則：避免使用拼音或者縮寫命名。

例外：

專有名詞：weixin/POI

傳統約定：i/j/k 表示循環索引

說明：含義不清晰，不能做到「望文生義」

BadCode

var uo = function updateOrder(){}
var as = [].slice;
var ex = Object.extends;
var nu = number

GoodCode

// weixin/wx 是專有名詞
var weixinUser = {};
var wx = weixin;
// POI 是專有名詞
var poi = {};

規則：名稱長短應與其作用域大小相對應。

例外：專有 API，如 alert
說明：在上層作用域下的代碼，會被更多函數使用到。其名稱應該盡量長或者通用，以保證能夠搜索到。

BadCode

// 在全局變量上定義了一個 item 變量，但是很難從命名上理解其作用是什么。
window.item = {}

GoodCode

window.primaryProductItem = {};

不要在變量/函數尾部加符號、數字

說明：變量中加符號，往往是為了約定其優先級或者作用域。符號應該在變量名前面。

BadCode

function getDot_(){}
function privateFn$$ (){}

GoodCode

function _getDot() {}
function $$privateFn() {}

規則：實例名稱要和類名相關

說明：類作為實例的所屬，其名稱表達的含義要一脈相承

BadCode

class Person() {}
var dog = new Person(); // dog is a Person ?

GoodCode

class Person() {}
var jack = new Person();

規則：避免直白的中英文翻譯

說明：粗暴的翻譯，更容易造成誤解，還不如寫拼音

BadCode

// 渲染「頁面頂部的執行人」
// 還是渲染「執行砍頭的人」？
function renderHeadExecutantPeople(){}

GoodCode

function renderHeader() {}

規則：概念的命名要一以貫之

說明：避免通一個概念在不同的代碼用多種不同的單詞描述。

BadCode

// 遠程請求這個概念，先后用了 get/fetch/query
// 三個名詞去描述
function getUserInfo() {}
function fetchProductInfo() {}
function queryPayment() {}

GoodCode

// 統一用 get 描述
// 閱讀代碼的人能體會到其中的共性
function getUserInfo() {}
function getProductInfo() {}
function getPayment() {}

規則：別用雙關語

例外：專有詞
說明：雙關語容易引起歧義

BadCode

// 訂單類型，還是排序類型？
var orderType

GoodCode

var sortType

規則：命名需要和實現一致

說明：命名往往是實現的隱喻，如果存在差異則會讓閱讀者看不懂代碼。

BadCode

// empty 的命名含義和實現截然相反
// （我真的見過這種代碼）
function getProduct(id) {
    axios.delete("/product", {id}); 
}

GoodCode

function deleteProduct(id) {
    axios.delete("/product", {id}); 
}

規則：對于布爾值的命名，需要默認其為「真」

說明：布爾變量的名稱中，如果加上「not」之類的否定詞，則相當于做了一次了邏輯判斷。

BadCode

const notEmpty = !!array.length;

GoodCode

const empty = !array.length;

函數 規則：長度不能超過 20 行

說明：代碼太長說明做的事情不夠專一，同時也會讓閱讀變得很困難。

規則：Don"t repeat yourself

說明：同樣功能的代碼不要重復三次

規則：每個函數只做一件事情，并做好這件事

說明：代碼里的邏輯分支要盡量少，只做一件事情，并且要處理好邊界和異常情況。

規則：盡量減少函數的參數，包括 opitons、config 等參數

說明：函數的輸入越多，往往就代表功能約復雜

規則：注釋出來項目/業務的坑

說明：對于比較奇怪的業務邏輯，或者因為系統、接口原因而寫的比較奇怪的邏輯。要通過注釋標注出來

BadCode

framework.doSomeThing();
framework.reset(); // 閱讀者內心 OS：這里為啥要做一次 reset？
framework.continueSomeThing();

GoodCode

framework.doSomeThing();
// framework 有個 bug，這里必須要做一次 rest 附鏈接: http://github.com/issuse/***
framework.reset(); 
framework.continueSomeThing();

規則：函數要盡量「純」沒有副作用

說明：純函數比較好測試，邏輯也比較清晰，可以放心的引入和刪除。

BadCode

let status;
function method() {
  if (status) { ... } 
}

GoodCode

function method(status) {
  if (status) { ... } 
}

規則：函數最好不要修改參數內的數據

說明：修改參數會導致函數的作用變得不可預測

BadCode

function updateObj(obj, value) {
  obj.key = value;
  return obj;
}

GoodCode

function updateObj(obj, value) {
  return {...obj, key: value};
}

規則：除非是 class 的方法，否則不要訪問 this

說明：this 的指向經常不固定，會導致代碼難以理解。如果調用方不熟悉的話，很容易引起 Bug。

BadCode

function method() {
    console.log(this.value); 
}

method() // 報錯
var obj = { method, value: 1}
obj.method() // 輸出 1

GoodCode

function method(value) {
    console.log(value); 
}

規則：處理錯誤

說明：錯誤也是一種邏輯分支，如果不處理的話，代碼就不夠健壯。前端代碼處理錯誤的方式一般為提示用戶有異常發生。如果錯誤不影響業務流程，則寫入日志里并上報。

BadCode

function method(data) {
    try { return JSON.parse(data) }
  catch (e) {}
}

GoodCode

function method(data) {
    try { return JSON.parse(data) }
  catch (e) {
      alert("數據處理失敗")
  }
}

數據 規則：不要有 Magic Number

說明：magic number 是指直接在代碼中硬編碼的數字，往往具有一些業務含義。

這樣會導致：

數字的意義難以理解

數值要改動時，要改很多地方

BadCode

if (status === 1) {
    ...
} else if (type === 4) {
  ...
}

GoodCode

enum Status {
    Closed 
}
enum Type {
    Array 
}

if (status === Status.Closed) {
    ...
} else if (type === Type.Array) {
  ...
}

規則：不管是 react state 還是 vue data 存放的業務數據都要具備原子性。

說明：原子性意味著獨立，且不可分割。其它屬性都由原子業務屬性推導、計算而來，這樣能保證狀態的一致。

BadCode

// 當 status 為 open 的時候展示彈窗
// 其它狀態則隱藏彈窗
{
    data() {
    return {
        showAlert: false,
      status: "closed",
    }
  },
  onStatusChange() {
      if (status === "open") {
        this.showAlert = true;
    } else {
        this.showAlert = false; 
    }
  }
}

GoodCode

// showAlert 為非原子的狀態
// 其狀態可以由 status 推導而來
{
    data() {
    return {
      status: "closed",
    }
  },
  computed: {
      showAlert() {
        return this.status === "open";
    }
  }
}

規則：對于 react state 和 vue data，應當區分業務狀態和 UI 狀態

說明：

狀態和 UI 存儲在一起，有時候傳給后端的數據里會夾雜著沒有必要的 UI 狀態。

業務代碼和 UI 代碼耦合在一起，業務代碼沒法復用。

BadCode

// 在一個列表中，用戶可以對數據做多選
// 然后刪除他們
class extends React.Component {
     async componentDidMount() {
      const listData = getData();
    this.setState({ listData })
  }
  
  check = (item) => {
    const listData = this.state.listData.map(i => {
        if (i === item) {
        return {...item, checked: true}
      }
      return i;
    });
    
    this.setState({ listData });
  }
  
  delete() {
    // 返回給后端的數據結構，會多出一個 checked 字段
    deleteItems(this.state.listData.filter(i => i.checked));
  }
  
    render() {
    const list = this.state.listData.map(item => {
      const className = ["item"];
      if (item.checked) className.push("active");
        return  this.check(item)}
      >{item.naem};
    });
    
    return <>
      {list}
        
    
  }
}

GoodCode

// 在一個列表中，用戶可以對數據做多選
// 然后刪除他們
class extends React.Component {
     async componentDidMount() {
      const listData = getData();
    // 使用獨立的 selected 來保存 UI 狀態
    this.setState({ listData, selected: [] })
  }
  
  check = (item) => {
    let { selected } = this.state;
    selected = selected.findOrInsert(s => s.id, item);
    this.setState({ selected });
  }
  
  delete() {
    const { selected, listData } = this.state;
    deleteItems(listData.filter(i => selected.includes(i.id))));
  }
  
    render() {
       const { selected, listData } = this.state;
    const list = listData.map(item => {
      const className = ["item"];
      if (selected.includes(item.id)) className.push("active");
        return  this.check(item)}
      >{item.naem};
    });
    
    return <>
      {list}
        
    
  }
}

規則：對于 react 應用，避免在 render 的時候修改狀態

說明：react 的 render 應該是純函數，在 render 里運行 setState 會導致重復渲染，或者死循環。

BadCode

// 如果 type 為 http 的話，則自動轉換為 https
class extends React.Component {
  render() {
      const { type } = this.state;
    if (type === "http") {
        this.setState({ type: "https"}) 
    }
    return {type};
  }
}

GoodCode

// 如果 type 為 http 的話，則自動轉換為 https
class extends React.Component {
  get type() {
    const { type } = this.state;
    if (type === "http") return "https";
    return type;
  }
  render() {
      const type = this.type;
    return {type};
  }
}

規則：對于雙向綁定應用，避免數據循環依賴。

說明：

循環依賴輕則導致頁面相應慢，重則導致出現臟數據。

避免循環依賴的前提是理清業務邏輯，搞清楚數據之間的依賴關系。

循環依賴也是雙向綁定技術的詬病之一。

BadCode

// foo 和 bar 互相依賴，導致了死循環
{
    data() {
      return {
        foo: 1,
    }; 
  },
  computed: {
    bar() {
        return this.foo + 1;
    }
  },
  watch() {
    bar() {
        this.foo = this.bar + 1;
    },
  }
}

規則：訪問數據時，需要考慮邊界情況和 JS 弱類型的特性。

說明：比如用雙等號做判斷

BadCode

const foo = "0";
const bar = 0

// 做數據判斷時不能用雙等號
foo == bar // true
foo ? 1 : 2 // 1
bar ? 1 : 2 // 2

// 僅通過變量有沒有 length 來判斷是否為數組
if（obj.length) {
    obj.forEach(...) 
}

GoodCode

const foo = "0";
const bar = 0

foo === bar // false

if (Array.isArray(obj)) {
     obj.forEach(...) 
}

規則：不要在遍歷數組的同時，改變數組數據

說明：這樣做會導致數據的異常。如果需要做這種操作，最好使用數組函數，或者操作拷貝數據。

BadCode

const array = [1,2,3,4,5,6,7,8,9,10];

// 刪除數組中的偶數
for (var i = 0; i < array.length; i++) {
    if (array[i] % 2 == 0) array.splice(i);
}
// array 變成了 [1]

GoodCode

const array = [1,2,3,4,5,6,7,8,9,10];
array.filter(a => !(a % 2))

API 規則：對 setTimeout 調用時，傳遞的時間參數必須有意義。

說明：
大多數場景下，setTimeout 后面傳遞一個時間是為了先執行后續的 A 代碼，再延后執行代碼閉包里的 B 代碼，如右邊示例代碼。

但如果隨著業務迭代，A 被改成異步，或者執行時間很長的話。之前做的延遲執行的防御措施就時效了，也許反而 B 會比 A 先執行。

BadCode

// 代碼的本來意圖是讓 B 延后執行
setTimeout(() => {
  B();
}, 1000);
A();

// 代碼的意圖是讓 render 在下一幀執行
// 但是不同設備，一幀時間是不固定的
setTimeout(() => {
  render()
}, 16);

GoodCode

// A 函數內要想辦法使用 Promise 串接起來
await A();
b();

// 使用系統提供的 API 執行動畫幀
requestAnimationFrame(() => {
 render(); 
});

規則：不要使用陳舊的 API

說明：陳舊的 API 往往有很多問題，比如安全、性能、不易讀等。

BadCode

// 判斷是否為數組
Object.prototype.toString.call(array) === "[object Array]" 
// 查找數組里第一個偶數
for (var i = 0; i < array.length; i++) {
    if (array[i] % 2 === 0) return array[i]; 
}
// 遍歷對象的 key
for (var key in obj) {
    console.log(key); 
}
// 判斷字符串/數組是否包含
"some text".indexOf("some") >= 0
// 去除首位空格
" some text ".replace(/(^s+|s+$)/g, "")
// 新建對象/數組
const array = new Array();
const obj = new Object();

GoodCode

Array.isArray(array)

array.find(a => a % 2 === 0);

Object.keys(obj).forEach(console.log)

"some text".includes("some")

" some text ".trim()
const array = [];
const obj = {};

規則：對于 99.9% 的場景，你都不需要使用 React ref

說明：
React Ref 一般是用來處理和原生 DOM 交互的場景，比如 canvas。

大部分對于 React ref 的使用都是錯誤的，大多都拿來用來控制子元素。這種場景我們更推薦用數據流（redux，mobx）或者用狀態提升去做。

React 官方有對「狀態提升」的描述 https://react.docschina.org/d...

BadCode

class List extends React.Component {
    async refresh() {
      this.setState({
      items: getItems(),
    });
  }
  
  render() {
      return this.state.items.map(i => {i}); 
  }
}
class extends React.Component {
  onRefresh = () => {
    // 用 ref 去調用子元素的方法
    this.list.refresh();
  }
    render() {
    return <>
       this.list = l}>

GoodCode

class List extends React.Component {
  render() {
      return this.props.items.map(i => {i}); 
  }
}
class extends React.Component {
 // 把數據狀態提升到父組件做操作                              
  refresh = async () => {
      this.setState({
      items: getItems(),
    });
  }

    render() {
    return <>

規則：不要用字符串拼接 url

說明：
字符串拼接 url 需要處理 encode 或者 decode 的情況，還有對于？和 # 的判斷不對的話，很容易造成漏洞或者 Bug。

目前瀏覽器和 Node 都已經提供了標準的 URL 解析方法。

https://developer.mozilla.org...

BadCode

// 這段代碼既沒有對 key、value 做 encode
// 也沒有考慮 url 中 # 出現的情況
const url = location.href;
if (url.indexOf("?") >= 0) {
    return  url + key + "=" + value;
} else {
  return  url + "?" + key + "=" + value;
}

GoodCode

// 使用標準的 URL 解析，風險會降低很多
const url = new URL(urlStr);
url.searchParams.set(key, value);
return url.toString();

邏輯 規則：判真不判假

說明：
我們應該期望 if 條件內是個「真」值，而不是一個「假」值。

第二種情況會導致代碼不易理解。

解決辦法參考布爾邏輯

BadCode

// if 條件內期望的是一個「假」值
if (!(status !== Closed) { ... }
if (!(status !== Closed || type !== Array)) { ...}

GoodCode

if (status === Closed) { ... }
if (status === Closed && type === Array) { ... }

規則：if 條件中，不易出現超過 3 個邏輯操作符。

例外：if 條件里可以被「且」（&&）邏輯拆分成多個子條件
說明：復雜的條件判斷會讓代碼不易理解，邏輯上有漏洞的話容易引起 Bug。
解決辦法：聲明中間變量

BadCode

if (srcElem != dropElem && (srcElem.nextSibling || srcElem.nextElementSibling) != dropElem) {...}
if (selectedItem || (selectedEmployee && selectedEmployee.empId && selectedEmployee) || employee) { ... }

GoodCode

const nextSibling = srcElem.nextSibling || srcElem.nextElementSibling
if (srcElem != dropElem &&  nextSibling != dropElem ) {
  ...
}
  
// 復雜的邏輯判斷可以通過 && 做拆分
if (
     !Array.isArray(cur)
  && cur != null
  && typeof src[key] === "object"
  && typeof cur === "object"
) { ... }

規則：不要用嵌套的三元表達式

說明：
人們閱讀嵌套三元表達式時，容易混淆語法的優先級，進而導致理解錯代碼的含義。

對于這種情況，建議改成 if else。

如果是在 react render 里，則建議獨立成函數。

BadCode

function render(props) {
  const value = props.value;
    return <>
    {value < 10 ? value > 0 ? value : 200 - value : 100 - value}
    ;
}

GoodCode

function getValue(value) {
  if (value < 10) {
    if (value > 0) return value;
    return 200 - value;
  }
  return 100 - value;
}

function render(props) {
  const value = props.value;
    return <>
    {getValue(value)}
    ;
}

規則：if 條件邏輯嵌套不要超過三層

說明：過深的嵌套會導致理解困難。
解決辦法：合并判斷條件，或者獨立成函數。

BadCode

if (status = Opened) {
    if (type = "array") {
            if (code = Success) {
            doSomething();
        }
    }
}

GoodCode

if (status = Opened && type = "array" &&code = Success) {
    doSomething();
}

云服務器 GPU云服務器代碼html寫出鍵盤 php寫出來怎么預覽云主機怎么避免被攻擊 web系統怎么避免ddos

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

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

設計模式之代理模式

摘要：虛擬代理虛擬代理把一些開銷很大的對象，延遲到真正需要它的時候才去創建。主要參考設計模式與開發實踐設計模式在面向對象軟件設計過程中針對特定問題的簡潔而優雅的解決方案。這是在《設計模式》一書中對設計模式的定義。在軟件開發過程中，我們可能會遇到過這樣的情況，我們現在發現一個問題，和以前的某個問題很相似，幾乎可以用統一套解決方案，而且我們還發現，在某個條件下，這個解決方案幾乎就是通用的，...

Gilbertat 2019-08-19 18:10 評論0 收藏0
代碼質量把控和項目進度之間的平衡

摘要：所以這中間需要一個取舍，哪些是要嚴格要求的，哪些是可以不管的。首先，好代碼可能是聊出來的。比如需求確認這一塊，多問多畫流程圖少動手。在這個過程中不斷整理和梳理原有的概念。代碼的直接修改。最后，好代碼是改出來的。作為前端負責人，很多時候發愁的不是寫好代碼，而是怎么讓身邊水平較差的小伙伴能寫出好的代碼另外，你還要保證項目的進度，所以代碼質量和項目進度之間有著天然的矛盾，怎么去平衡值得我...

gplane 2019-08-02 15:34 評論0 收藏0
代碼質量把控和項目進度之間的平衡

摘要：所以這中間需要一個取舍，哪些是要嚴格要求的，哪些是可以不管的。首先，好代碼可能是聊出來的。比如需求確認這一塊，多問多畫流程圖少動手。在這個過程中不斷整理和梳理原有的概念。代碼的直接修改。最后，好代碼是改出來的。作為前端負責人，很多時候發愁的不是寫好代碼，而是怎么讓身邊水平較差的小伙伴能寫出好的代碼另外，你還要保證項目的進度，所以代碼質量和項目進度之間有著天然的矛盾，怎么去平衡值得我...

guyan0319 2019-08-30 11:26 評論0 收藏0
代碼質量把控和項目進度之間的平衡

摘要：所以這中間需要一個取舍，哪些是要嚴格要求的，哪些是可以不管的。首先，好代碼可能是聊出來的。比如需求確認這一塊，多問多畫流程圖少動手。在這個過程中不斷整理和梳理原有的概念。代碼的直接修改。最后，好代碼是改出來的。作為前端負責人，很多時候發愁的不是寫好代碼，而是怎么讓身邊水平較差的小伙伴能寫出好的代碼另外，你還要保證項目的進度，所以代碼質量和項目進度之間有著天然的矛盾，怎么去平衡值得我...

imccl 2019-08-26 18:37 評論0 收藏0

發表評論

登陸后可評論

0條評論

yuanxin

男|高級講師

我要關注我要私信

TA的文章

#11.11#hostEONS：美國VPS年付$21起，100G高防，雙倍硬盤+流量

閱讀 2322·2021-11-08 13:13
RestCloud平臺，API自動化測試

閱讀 1253·2021-10-09 09:41
畢業設計之 -- 基于單片機的智能水箱

閱讀 1696·2021-09-02 15:40
A400互聯：36元/季/1核/1GB內存/1TB流量/30Mbps端口/KVM/洛杉磯CN2 GI

閱讀 3194·2021-08-17 10:13
javascript調試接口

閱讀 2553·2019-08-29 16:33
解決inline-block元素的3個 bug

閱讀 3129·2019-08-29 13:17
[譯] 學習 CSS clip-path 屬性

閱讀 3140·2019-08-29 11:00
怎么避免寫出爛代碼

閱讀 3303·2019-08-26 13:40

国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

怎么避免寫出爛代碼

相關文章

設計模式之代理模式

代碼質量把控和項目進度之間的平衡

代碼質量把控和項目進度之間的平衡

代碼質量把控和項目進度之間的平衡

發表評論

0條評論

yuanxin

男|高級講師

TA的文章

#11.11#hostEONS：美國VPS年付$21起，100G高防，雙倍硬盤+流量

RestCloud平臺，API自動化測試

畢業設計之 -- 基于單片機的智能水箱

A400互聯：36元/季/1核/1GB內存/1TB流量/30Mbps端口/KVM/洛杉磯CN2 GI

javascript調試接口

解決inline-block元素的3個 bug

[譯] 學習 CSS clip-path 屬性