當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

写出整洁的高效的js代码

發(fā)布時(shí)間：2023/12/9 编程问答 22 豆豆

生活随笔收集整理的這篇文章主要介紹了写出整洁的高效的js代码小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

Variables:變量

使用有意義的可發(fā)音的變量名

Bad:

var yyyymmdstr = moment().format('YYYY/MM/DD');

Good:

var yearMonthDay = moment().format('YYYY/MM/DD');

使用可搜索的命名

在開發(fā)過程中，我們閱讀代碼的時(shí)間會(huì)遠(yuǎn)遠(yuǎn)超過編寫代碼的時(shí)間，因此保證代碼的可讀性與可搜索會(huì)非常重要。切記，沒事不要坑自己。

Bad:

//525600到底啥意思？ for (var i = 0; i < 525600; i++) {runCronJob(); }

Good:

// 聲明為全局變量 var MINUTES_IN_A_YEAR = 525600; for (var i = 0; i < MINUTES_IN_A_YEAR; i++) {runCronJob(); }

使用說明性質(zhì)的臨時(shí)變量

Bad:

let cityStateRegex = /^(.+)[,\\s]+(.+?)\s*(\d{5})?$/; saveCityState(cityStateRegex.match(cityStateRegex)[1], cityStateRegex.match(cityStateRegex)[2]);

Good:

let cityStateRegex = /^(.+)[,\\s]+(.+?)\s*(\d{5})?$/; let match = cityStateRegex.match(cityStateRegex) let city = match[1]; let state = match[2]; saveCityState(city, state);

避免摸不著頭腦的臨時(shí)變量

在遍歷或者mapping過程中，需要避免短小無意義的變量命名。

Bad:

var locations = ['Austin', 'New York', 'San Francisco']; locations.forEach((l) => {doStuff();doSomeOtherStuff();.........// Wait, what is `l` for again?dispatch(l); });

Good:

var locations = ['Austin', 'New York', 'San Francisco']; locations.forEach((location) => {doStuff();doSomeOtherStuff();.........dispatch(location); });

避免添加不需要的內(nèi)容

如果你的類名/實(shí)例名已經(jīng)能夠表述某些信息，那么在類/實(shí)例的屬性中就不需要重復(fù)命名。

Bad:

var Car = {carMake: 'Honda',carModel: 'Accord',carColor: 'Blue' };function paintCar(car) {car.carColor = 'Red'; }

Good:

var Car = {make: 'Honda',model: 'Accord',color: 'Blue' };function paintCar(car) {car.color = 'Red'; }

Short-circuiting 優(yōu)于條件選擇

Bad:

function createMicrobrewery(name) {var breweryName;if (name) {breweryName = name;} else {breweryName = 'Hipster Brew Co.';} }

Good:

function createMicrobrewery(name) {var breweryName = name || 'Hipster Brew Co.' }

函數(shù)

函數(shù)參數(shù)最好不超過兩個(gè)

限制函數(shù)的參數(shù)數(shù)目還是比較重要的，它能夠方便對于函數(shù)的測試，避免需要進(jìn)行不同的Case測試時(shí)把代碼變得一團(tuán)糟。我們應(yīng)該盡可能地控制參數(shù)數(shù)目小于或等于兩個(gè)，如果你的參數(shù)數(shù)目多于兩個(gè)，那么建議使用高階對象進(jìn)行適當(dāng)封裝。

Bad:

function createMenu(title, body, buttonText, cancellable) {... }

Good:

var menuConfig = {title: 'Foo',body: 'Bar',buttonText: 'Baz',cancellable: true }function createMenu(menuConfig) {... }

函數(shù)應(yīng)當(dāng)遵循單一職責(zé)原則

這一條算是迄今為止軟件工程中最重要的原則之一了。如果我們給單一函數(shù)賦予了過多的職責(zé)，那么其很難被用于組合、測試等。而如果你保證函數(shù)的單一職責(zé)性質(zhì)，那么相對其重構(gòu)難度、代碼可讀性也會(huì)更好。

Bad:

function emailClients(clients) {clients.forEach(client => {let clientRecord = database.lookup(client);if (clientRecord.isActive()) {email(client);}}); }

Good:

函數(shù)命名應(yīng)該反映其功能

Bad:

function dateAdd(date, month) {// ... }let date = new Date();// 很難從函數(shù)名中獲知該函數(shù)到底是誰加上誰 dateAdd(date, 1);

Good:

function dateAddMonth(date, month) {// ... }let date = new Date(); dateAddMonth(date, 1);

函數(shù)應(yīng)當(dāng)只是一層抽象

這一條類似于單一職責(zé)原則，不過更傾向于關(guān)注函數(shù)的抽象程度，如果我們在單一函數(shù)中添加了過多的抽象層，同樣會(huì)降低的函數(shù)可讀性、增加重構(gòu)難度。

Bad:

Good:

移除重復(fù)代碼

在任何情況下都不要去容許重復(fù)代碼的存在。重復(fù)代碼指那些修改單一邏輯時(shí)需要修改多個(gè)代碼片的代碼交集，JavaScript本身是弱類型語言，相對而言編寫泛型函數(shù)會(huì)更加容易。

Bad:

Good:

使用默認(rèn)參數(shù)代替或運(yùn)算

Bad:

function writeForumComment(subject, body) {subject = subject || 'No Subject';body = body || 'No text'; }

Good:

function writeForumComment(subject = 'No subject', body = 'No text') {... }

使用 Object.assign 設(shè)置默認(rèn)值

Bad:

var menuConfig = {title: null,body: 'Bar',buttonText: null,cancellable: true }function createMenu(config) {config.title = config.title || 'Foo'config.body = config.body || 'Bar'config.buttonText = config.buttonText || 'Baz'config.cancellable = config.cancellable === undefined ? config.cancellable : true;}createMenu(menuConfig);

Good:

var menuConfig = {title: null,body: 'Bar',buttonText: null,cancellable: true }function createMenu(config) {Object.assign(config, {title: 'Foo',body: 'Bar',buttonText: 'Baz',cancellable: true}); }createMenu(menuConfig);

避免在參數(shù)中使用Flags

有的開發(fā)者會(huì)使用Flags來控制函數(shù)執(zhí)行不同的邏輯流，不過就如我們在上文中提及的單一職責(zé)原則，我們應(yīng)當(dāng)將函數(shù)拆分為不同的部分，然后在外層調(diào)用上根據(jù)Flags調(diào)用不同的函數(shù)。

Bad:

function createFile(name, temp) {if (temp) {fs.create('./temp/' + name);} else {fs.create(name);} }

Good:

function createTempFile(name) {fs.create('./temp/' + name); }function createFile(name) {fs.create(name); }

避免冗余副作用

如果某個(gè)函數(shù)除了接收輸入值與返回值之外還做了其他事，那么就稱其具有副作用。典型的副作用譬如寫文件、修改某些全局變量、修改內(nèi)存參數(shù)等等。在編程中我們不可避免的需要產(chǎn)生副作用，譬如上面例子中我們需要寫入到某個(gè)外部文件。而你應(yīng)當(dāng)做的就是將所有的寫文件操作由某個(gè)服務(wù)統(tǒng)一處理，而不應(yīng)該將寫文件的操作分散到數(shù)個(gè)類或者函數(shù)中。這一點(diǎn)最大的優(yōu)勢在于避免了不同對象之間共享狀態(tài)，共享的可變狀態(tài)可是萬惡之源啊。

Bad:

// 定義全局變量 // 如果我們有其他的函數(shù)引用了該變量，那么我們就無法預(yù)測該變量類型 var name = 'Ryan McDermott';function splitIntoFirstAndLastName() {name = name.split(' '); }splitIntoFirstAndLastName();console.log(name); // ['Ryan', 'McDermott'];

Good:

function splitIntoFirstAndLastName(name) {return name.split(' '); }var name = 'Ryan McDermott' var newName = splitIntoFirstAndLastName(name);console.log(name); // 'Ryan McDermott'; console.log(newName); // ['Ryan', 'McDermott'];

避免污染全局函數(shù)

JavaScript中有個(gè)不太好的實(shí)踐就是修改某個(gè)全局函數(shù)，將其指向其他的庫或者自定義函數(shù)，不過這個(gè)會(huì)對某個(gè)懵懂的用戶造成困惱。如果你想給JavaScript原生的Array添加一個(gè)diff函數(shù)支持，來展示兩個(gè)數(shù)組的差異。你可以選擇將函數(shù)掛載到Array.prototype，不過很有可能跟其他打算占用這個(gè)位置的庫起沖突。我們更建議使用ES6的classes，并且使用繼承方式去添加新的功能函數(shù)。

Bad:

Array.prototype.diff = function(comparisonArray) {var values = [];var hash = {};for (var i of comparisonArray) {hash[i] = true;}for (var i of this) {if (!hash[i]) {values.push(i);}}return values; }

Good:

class SuperArray extends Array {constructor(...args) {super(...args);}diff(comparisonArray) {var values = [];var hash = {};for (var i of comparisonArray) {hash[i] = true;}for (var i of this) {if (!hash[i]) {values.push(i);}}return values;} }

優(yōu)先選擇函數(shù)式編程而不是命令式編程

JavaScript并不像Haskell這樣純粹的函數(shù)式編程語言，不過其對于實(shí)踐函數(shù)式編程的理念還是很推崇的。函數(shù)式編程可讀性更好，也更易于測試。

Bad:

Good:

const programmerOutput = [{name: 'Uncle Bobby',linesOfCode: 500}, {name: 'Suzie Q',linesOfCode: 1500}, {name: 'Jimmy Gosling',linesOfCode: 150}, {name: 'Gracie Hopper',linesOfCode: 1000} ];var totalOutput = programmerOutput.map((programmer) => programmer.linesOfCode).reduce((acc, linesOfCode) => acc + linesOfCode, 0);

封裝條件選擇

Bad:

if (fsm.state === 'fetching' && isEmpty(listNode)) {/// ... }

Good:

function shouldShowSpinner(fsm, listNode) {return fsm.state === 'fetching' && isEmpty(listNode); }if (shouldShowSpinner(fsmInstance, listNodeInstance)) {// ... }

避免負(fù)類條件

Bad:

function isDOMNodeNotPresent(node) {// ... }if (!isDOMNodeNotPresent(node)) {// ... }

Good:

function isDOMNodePresent(node) {// ... }if (isDOMNodePresent(node)) {// ... }

避免使用條件選擇

很多人第一次聽到這個(gè)概念都會(huì)覺得不可思議，沒有if條件選擇語句的話又該如何編程呢？在這里我們推薦使用多態(tài)性來達(dá)成這一目標(biāo)，因?yàn)槿绻诤瘮?shù)或類中嵌入過多的if語句，會(huì)導(dǎo)致該函數(shù)或者類破壞單一職責(zé)原則。

Bad:

class Airplane {//...getCruisingAltitude() {switch (this.type) {case '777':return getMaxAltitude() - getPassengerCount();case 'Air Force One':return getMaxAltitude();case 'Cesna':return getMaxAltitude() - getFuelExpenditure();}} }

Good:

class Airplane {//... }class Boeing777 extends Airplane {//...getCruisingAltitude() {return getMaxAltitude() - getPassengerCount();} }class AirForceOne extends Airplane {//...getCruisingAltitude() {return getMaxAltitude();} }class Cesna extends Airplane {//...getCruisingAltitude() {return getMaxAltitude() - getFuelExpenditure();} }

避免依賴于類型檢測

很多時(shí)候我們會(huì)依賴于JavaScript輸入的參數(shù)類型來進(jìn)入不同的控制流，不過鑒于JavaScript本身是弱類型語言，我們還是應(yīng)該避免這種實(shí)踐。第一個(gè)方法就是使用較為一致性的接口。

Bad:

function travelToTexas(vehicle) {if (vehicle instanceof Bicycle) {vehicle.peddle(this.currentLocation, new Location('texas'));} else if (vehicle instanceof Car) {vehicle.drive(this.currentLocation, new Location('texas'));} }

Good:

function travelToTexas(vehicle) {vehicle.move(this.currentLocation, new Location('texas')); }

避免依賴于類型檢測

如果你需要操作像字符串、數(shù)值、列表這樣的基礎(chǔ)數(shù)據(jù)類型，你就無法依賴于多態(tài)性來實(shí)現(xiàn)類型檢測。那么建議是使用TypeScript，它為普通的JavaScript添加了靜態(tài)類型支持。

Bad:

function combine(val1, val2) {if (typeof val1 == "number" && typeof val2 == "number" ||typeof val1 == "string" && typeof val2 == "string") {return val1 + val2;} else {throw new Error('Must be of type String or Number');} }

Good:

function combine(val1, val2) {return val1 + val2; }

避免過度優(yōu)化

現(xiàn)代瀏覽器已經(jīng)在運(yùn)行時(shí)做了很多的優(yōu)化，因此很多時(shí)候如果我們要遵循那些流傳已久的優(yōu)化策略不過是浪費(fèi)時(shí)間。可以參考這個(gè)來獲取建議的優(yōu)化要點(diǎn)。

Bad:

// On old browsers, each iteration would be costly because `len` would be // recomputed. In modern browsers, this is optimized. for (var i = 0, len = list.length; i < len; i++) {// ... }

Good:

for (var i = 0; i < list.length; i++) {// ... }

移除棄用的代碼

棄用的代碼就和重復(fù)的代碼一樣，我們沒有任何理由保留他們。不過為防萬一建議不要徹底從Git的歷史記錄中刪除它們。

Bad:

function oldRequestModule(url) {// ... }function newRequestModule(url) {// ... }var req = newRequestModule; inventoryTracker('apples', req, 'www.inventory-awesome.io');

Good:

function newRequestModule(url) {// ... }var req = newRequestModule; inventoryTracker('apples', req, 'www.inventory-awesome.io');

對象與數(shù)據(jù)結(jié)構(gòu)

使用getters與setters

在JavaScript的對象屬性讀寫中，建議使用getter或者setter，而不是直接讀取或者賦值。不過JavaScript并沒有類似于public或者private這樣的關(guān)鍵字，因此很難通過接口方式進(jìn)行強(qiáng)限制。不過鑒于以下優(yōu)勢我們還是強(qiáng)烈建議使用getter或者setter:
1.如果你打算不僅僅是直接獲取原始值，使用getter能夠避免去修改每個(gè)取值的地方。
2.使用set能夠方便地添加校驗(yàn)。

封裝內(nèi)部表述。

便于添加日志與錯(cuò)誤處理。

通過繼承能夠復(fù)寫默認(rèn)功能。

支持屬性懶加載。

Bad:

class BankAccount {constructor() {this.balance = 1000;} }let bankAccount = new BankAccount();// Buy shoes... bankAccount.balance = bankAccount.balance - 100;

Good:

class BankAccount {constructor() {this.balance = 1000;}// It doesn't have to be prefixed with `get` or `set` to be a getter/setterwithdraw(amount) {if (verifyAmountCanBeDeducted(amount)) {this.balance -= amount;}} }let bankAccount = new BankAccount();// Buy shoes... bankAccount.withdraw(100);

為對象添加私有屬性

可以通過閉包方式添加私有屬性：

Bad:

var Employee = function(name) {this.name = name; }Employee.prototype.getName = function() {return this.name; }var employee = new Employee('John Doe'); console.log('Employee name: ' + employee.getName()); // Employee name: John Doe delete employee.name; console.log('Employee name: ' + employee.getName()); // Employee name: undefined

Good:

類

單一職責(zé)原則

便如Clean Code中所述，不應(yīng)該為了多個(gè)理由去更改某個(gè)類的代碼，這樣會(huì)把某個(gè)類塞入過多的功能。最小化你需要去改變某個(gè)類的次數(shù)對于保證代碼的穩(wěn)定性至關(guān)重要，過多的改變代碼會(huì)影響代碼庫中依賴于該類的其他模塊。

Bad:

class UserSettings {constructor(user) {this.user = user;}changeSettings(settings) {if (this.verifyCredentials(user)) {// ...}}verifyCredentials(user) {// ...} }

Good:

class UserAuth {constructor(user) {this.user = user;}verifyCredentials() {// ...} }class UserSettings {constructor(user) {this.user = user;this.auth = new UserAuth(user)}changeSettings(settings) {if (this.auth.verifyCredentials()) {// ...}} }

開放封閉原則

正如Bertrand Meyer所述，譬如類、模塊、函數(shù)這樣的實(shí)體應(yīng)該面向擴(kuò)展開放，而拒絕修改。換言之，我們推薦去繼承擴(kuò)展某個(gè)函數(shù)或模塊，而不是每次都去修改源代碼。

Bad:

class AjaxRequester {constructor() {// What if we wanted another HTTP Method, like DELETE? We would have to // open this file up and modify this and put it in manually. this.HTTP_METHODS = ['POST', 'PUT', 'GET'];}get(url) {// ...}}

Good:

class AjaxRequester {constructor() {this.HTTP_METHODS = ['POST', 'PUT', 'GET'];}get(url) {// ...}addHTTPMethod(method) {this.HTTP_METHODS.push(method);} }

里氏替換原則

這個(gè)原則聽起來有點(diǎn)拗口，不過概念卻很好理解。其形式化描述為如果S為T的子類型，那么類型T的實(shí)例可以被類型S的實(shí)例替換而不需要修改任何的代碼。形象而言，我們創(chuàng)建的父類與其子類應(yīng)當(dāng)可交換地使用而不會(huì)引起異常，譬如下文的Square-Rectangle這個(gè)例子。Square也是Rectangle：

Bad:

class Rectangle {constructor() {this.width = 0;this.height = 0;}setColor(color) {// ...}render(area) {// ...}setWidth(width) {this.width = width;}setHeight(height) {this.height = height;}getArea() {return this.width * this.height;} }class Square extends Rectangle {constructor() {super();}setWidth(width) {this.width = width;this.height = width;}setHeight(height) {this.width = height;this.height = height;} }function renderLargeRectangles(rectangles) {rectangles.forEach((rectangle) => {rectangle.setWidth(4);rectangle.setHeight(5);let area = rectangle.getArea(); // BAD: Will return 25 for Square. Should be 20.rectangle.render(area);}) }let rectangles = [new Rectangle(), new Rectangle(), new Square()]; renderLargeRectangles(rectangles);

Good:

class Shape {constructor() {}setColor(color) {// ...}render(area) {// ...} }class Rectangle extends Shape {constructor() {super();this.width = 0;this.height = 0;}setWidth(width) {this.width = width;}setHeight(height) {this.height = height;}getArea() {return this.width * this.height;} }class Square extends Shape {constructor() {super();this.length = 0;}setLength(length) {this.length = length;}getArea() {return this.length * this.length;} }function renderLargeShapes(shapes) {shapes.forEach((shape) => {switch (shape.constructor.name) {case 'Square':shape.setLength(5);case 'Rectangle':shape.setWidth(4);shape.setHeight(5);}let area = shape.getArea();shape.render(area);}) }let shapes = [new Rectangle(), new Rectangle(), new Square()]; renderLargeShapes(shapes);

接口隔離原則

JavaScript本身并不包含對于接口語法的支持，因此也無法像其他語言那樣達(dá)到嚴(yán)格限制的程度。不過鑒于JavaScript本身類型系統(tǒng)的缺失，遵循接口隔離原則還是蠻重要的。ISP的表述為不應(yīng)該強(qiáng)制客戶端去依賴于他們不需要的接口，這一點(diǎn)在JavaScript中較為典型的例子就是那些需要大量配置信息的對象。其實(shí)使用者并不需要去關(guān)心每一個(gè)配置項(xiàng)，允許他們動(dòng)態(tài)的設(shè)置能夠節(jié)省大量的時(shí)間，代碼的可讀性也會(huì)更好。

Bad:

class DOMTraverser {constructor(settings) {this.settings = settings;this.setup();}setup() {this.rootNode = this.settings.rootNode;this.animationModule.setup();}traverse() {// ...} }let $ = new DOMTraverser({rootNode: document.getElementsByTagName('body'),animationModule: function() {} // Most of the time, we won't need to animate when traversing. // ... });

Good:

class DOMTraverser {constructor(settings) {this.settings = settings;this.options = settings.options;this.setup();}setup() {this.rootNode = this.settings.rootNode;this.setupOptions();}setupOptions() {if (this.options.animationModule) {// ...}}traverse() {// ...} }let $ = new DOMTraverser({rootNode: document.getElementsByTagName('body'),options: { animationModule: function() {}} });

依賴反轉(zhuǎn)原則

This principle states two essential things:

High-level modules should not depend on low-level modules. Both should

on abstractions.

Abstractions should not depend upon details. Details should depend onabstractions.

This can be hard to understand at first, but if you've worked with Angular.js,
you've seen an implementation of this principle in the form of Dependency
Injection (DI). While they are not identical concepts, DIP keeps high-level
modules from knowing the details of its low-level modules and setting them up.
It can accomplish this through DI. A huge benefit of this is that it reduces
the coupling between modules. Coupling is a very bad development pattern because
it makes your code hard to refactor.

As stated previously, JavaScript doesn't have interfaces so the abstractions
that are depended upon are implicit contracts. That is to say, the methods
and properties that an object/class exposes to another object/class. In the
example below, the implicit contract is that any Request module for an
InventoryTracker will have a requestItems method.

Bad:

class InventoryTracker {constructor(items) {this.items = items;// BAD: We have created a dependency on a specific request implementation. // We should just have requestItems depend on a request method: `request` this.requester = new InventoryRequester();}requestItems() {this.items.forEach((item) => {this.requester.requestItem(item);});} }class InventoryRequester {constructor() {this.REQ_METHODS = ['HTTP'];}requestItem(item) {// ...} }let inventoryTracker = new InventoryTracker(['apples', 'bananas']); inventoryTracker.requestItems();

Good:

class InventoryTracker {constructor(items, requester) {this.items = items;this.requester = requester;}requestItems() {this.items.forEach((item) => {this.requester.requestItem(item);});} }class InventoryRequesterV1 {constructor() {this.REQ_METHODS = ['HTTP'];}requestItem(item) {// ...} }class InventoryRequesterV2 {constructor() {this.REQ_METHODS = ['WS'];}requestItem(item) {// ...} }// By constructing our dependencies externally and injecting them, we can easily // substitute our request module for a fancy new one that uses WebSockets. let inventoryTracker = new InventoryTracker(['apples', 'bananas'], new InventoryRequesterV2()); inventoryTracker.requestItems();

優(yōu)先選擇ES6類而不是ES5的基本函數(shù)定義

傳統(tǒng)ES5的類實(shí)現(xiàn)語法對于類的繼承、構(gòu)建以及方法定義的可讀性都不是很好。如果你考慮在類中實(shí)現(xiàn)繼承，那么建議優(yōu)先考慮ES6的類語法糖。如果你只是需要構(gòu)建簡單的對象，那么可以考慮使用ES5的基本函數(shù)定義來構(gòu)造類對象。

Bad:

Good:

class Animal {constructor(age) {this.age = age;}move() {} }class Mammal extends Animal {constructor(age, furColor) {super(age);this.furColor = furColor;}liveBirth() {} }class Human extends Mammal {constructor(age, furColor, languageSpoken) {super(age, furColor);this.languageSpoken = languageSpoken;}speak() {} }

Use method chaining

Against the advice of Clean Code, this is one place where we will have to differ.
It has been argued that method chaining is unclean and violates the Law of Demeter.
Maybe it's true, but this pattern is very useful in JavaScript and you see it in
many libraries such as jQuery and Lodash. It allows your code to be expressive,
and less verbose. For that reason, I say, use method chaining and take a look at
how clean your code will be. In your class functions, simply return this at
the end of every function, and you can chain further class methods onto it.

Bad:

class Car {constructor() {this.make = 'Honda';this.model = 'Accord';this.color = 'white';}setMake(make) {this.name = name;}setModel(model) {this.model = model;}setColor(color) {this.color = color;}save() {console.log(this.make, this.model, this.color);} }let car = new Car(); car.setColor('pink'); car.setMake('Ford'); car.setModel('F-150') car.save();

Good:

class Car {constructor() {this.make = 'Honda';this.model = 'Accord';this.color = 'white';}setMake(make) {this.name = name;// NOTE: Returning this for chaining return this;}setModel(model) {this.model = model;// NOTE: Returning this for chaining return this;}setColor(color) {this.color = color;// NOTE: Returning this for chaining return this;}save() {console.log(this.make, this.model, this.color);} }let car = new Car().setColor('pink').setMake('Ford').setModel('F-150').save();

Prefer composition over inheritance

As stated famously in the Gang of Four,
you should prefer composition over inheritance where you can. There are lots of
good reasons to use inheritance and lots of good reasons to use composition.
The main point for this maxim is that if your mind instinctively goes for
inheritance, try to think if composition could model your problem better. In some
cases it can.

You might be wondering then, "when should I use inheritance?" It
depends on your problem at hand, but this is a decent list of when inheritance
makes more sense than composition:

Your inheritance represents an "is-a" relationship and not a "has-a"

(Animal->Human vs. User->UserDetails).

You can reuse code from the base classes (Humans can move like all animals).

You want to make global changes to derived classes by changing a base class.(Change the caloric expenditure of all animals when they move).

Bad:

class Employee {constructor(name, email) {this.name = name;this.email = email;}// ... }// Bad because Employees "have" tax data. EmployeeTaxData is not a type of Employee class EmployeeTaxData extends Employee {constructor(ssn, salary) {super();this.ssn = ssn;this.salary = salary;}// ... }

Good:

class Employee {constructor(name, email) {this.name = name;this.email = email;}setTaxData(ssn, salary) {this.taxData = new EmployeeTaxData(ssn, salary);}// ... }class EmployeeTaxData {constructor(ssn, salary) {this.ssn = ssn;this.salary = salary;}// ... }

測試

測試是代碼部署前不可避免的重要步驟，如果你沒有添加任何的測試，那么你在每次部署之前你壓根不敢確定是否會(huì)產(chǎn)生什么意外情況。不同的團(tuán)隊(duì)對于測試覆蓋率的需求不太一致，不過保持100%的覆蓋率能夠讓你的團(tuán)隊(duì)對于代碼保持較好的掌控與信賴。我們可以使用很多優(yōu)秀的測試工具與測試覆蓋率檢測工具，建議是對于每個(gè)新的特征或者模塊都添加測試用例。如果更傾向于使用測試驅(qū)動(dòng)開發(fā)，一定要注意在你打算添加新的特性或者重構(gòu)當(dāng)前代碼之前保證測試覆蓋率已經(jīng)達(dá)到了預(yù)期。

每個(gè)測試用例單一目標(biāo)

Bad:

const assert = require('assert');describe('MakeMomentJSGreatAgain', function() {it('handles date boundaries', function() {let date;date = new MakeMomentJSGreatAgain('1/1/2015');date.addDays(30);date.shouldEqual('1/31/2015');date = new MakeMomentJSGreatAgain('2/1/2016');date.addDays(28);assert.equal('02/29/2016', date);date = new MakeMomentJSGreatAgain('2/1/2015');date.addDays(28);assert.equal('03/01/2015', date);}); });

Good:

并發(fā)

使用Promise替代回調(diào)

回調(diào)含義不清晰，還會(huì)導(dǎo)致過深的代碼嵌套，就是所謂的回調(diào)地獄。在ES6中，Promises已經(jīng)是內(nèi)置的全局類型。

Bad:

require('request').get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', function(err, response) {if (err) {console.error(err);}else {require('fs').writeFile('article.html', response.body, function(err) {if (err) {console.error(err);} else {console.log('File written');}})} })

Good:

require('request-promise').get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin').then(function(response) {return require('fs-promise').writeFile('article.html', response);}).then(function() {console.log('File written');}).catch(function(err) {console.log(err);})

Async/Await 更為清晰

Promises本身已經(jīng)是對于回調(diào)的不錯(cuò)的替代，而ES7中的async與await則是更為清晰的解決方案，可以避免你編寫大量的then調(diào)用鏈。

Bad:

Good:

async function getCleanCodeArticle() {try {var request = await require('request-promise')var response = await request.get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin');var fileHandle = await require('fs-promise');await fileHandle.writeFile('article.html', response);console.log('File written');} catch(err) {console.log(err);}}

格式化

就像本文的很多建議一樣，格式化本身是非常主觀的原則。建議是使用工具來自動(dòng)完成格式化操作，而不是爭論具體的格式化的細(xì)節(jié)。

相似含義變量的大寫一致性

JavaScript本身是無類型的，因此變量名大寫也能傳遞很多有用的信息。這個(gè)規(guī)則算是比較主觀的，建議團(tuán)隊(duì)可以根據(jù)自己的內(nèi)部規(guī)范將相同含義變量的大小寫保持一致性。

Bad:

Good:

函數(shù)的定義與調(diào)用位置盡量靠近

盡量將兩個(gè)有相互調(diào)用關(guān)系的函數(shù)在源文件的豎直上較為接近的位置，并且將調(diào)用者放置于被調(diào)用者上方。我們習(xí)慣從上至下的閱讀代碼，這樣的布局會(huì)提高整個(gè)代碼的可讀性。

Bad:

class PerformanceReview {constructor(employee) {this.employee = employee;}lookupPeers() {return db.lookup(this.employee, 'peers');}lookupMananger() {return db.lookup(this.employee, 'manager');}getPeerReviews() {let peers = this.lookupPeers();// ...}perfReview() {getPeerReviews();getManagerReview();getSelfReview();}getManagerReview() {let manager = this.lookupManager();}getSelfReview() {// ...} }let review = new PerformanceReview(user); review.perfReview();

Good:

class PerformanceReview {constructor(employee) {this.employee = employee;}perfReview() {getPeerReviews();getManagerReview();getSelfReview();}getPeerReviews() {let peers = this.lookupPeers();// ...}lookupPeers() {return db.lookup(this.employee, 'peers');}getManagerReview() {let manager = this.lookupManager();}lookupMananger() {return db.lookup(this.employee, 'manager');}getSelfReview() {// ...} }let review = new PerformanceReview(employee); review.perfReview();

注釋

避免保留被注釋的代碼

Bad:

doStuff(); // doOtherStuff(); // doSomeMoreStuff(); // doSoMuchStuff();

Good:

doStuff();

不要使用日記形式的注釋

千萬記住，要使用版本控制工具，而不是在你的代碼前面添加日記形式的注釋，使用git log查看歷史記錄。

Bad:

/*** 2016-12-20: Removed monads, didn't understand them (RM)* 2016-10-01: Improved using special monads (JP)* 2016-02-03: Removed type-checking (LI)* 2015-03-14: Added combine with type-checking (JR)*/ function combine(a, b) {return a + b; }

Good:

function combine(a, b) {return a + b; }

避免額外的代碼標(biāo)記注釋

建議是讓函數(shù)與變量名來表述其功能，避免添加過多額外的注釋。

Bad:

// Scope Model Instantiationlet $scope.model = {menu: 'foo',nav: 'bar' };// Action setuplet actions = function() {// ... }

Good:

let $scope.model = {menu: 'foo',nav: 'bar' };let actions = function() {// ... }

原文發(fā)布時(shí)間：2017-01-07

原文作者：kimyeongnam

本文來源掘金如需轉(zhuǎn)載請緊急聯(lián)系作者

總結(jié)

以上是生活随笔為你收集整理的写出整洁的高效的js代码的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇： vue-cli搭建项目引入jquery和
下一篇： [react] 写例子说明React如何