如何寫出優雅的JS 代碼
// 不好的寫法const yyyymmdstr = moment().format('YYYY/MM/DD');// 好的寫法const currentDate = moment().format('YYYY/MM/DD');對同一類型的變量使用相同的詞匯
// 不好的寫法getUserInfo();getClientData();getCustomerRecord();// 好的寫法getUser();使用可搜索的名字
我們讀的會比我們寫的多得多，所以如果命名太過隨意不僅會給后續的維護帶來困難，也會傷害了讀我們代碼的開發者。讓你的變量名可被讀取，像buddy.js和ESLint這樣的工具可以幫助識別未命名的常量。
// 不好的寫法// 86400000 的用途是什么？setTimeout(blastOff, 86400000);// 好的寫法const MILLISECONDS_IN_A_DAY = 86_400_000;setTimeout(blastOff, MILLISECONDS_IN_A_DAY);使用解釋性變量
// 不好的寫法const address = 'One Infinite Loop, Cupertino 95014';const cityZipCodeRegex = /^[^,]+[,s]+(.+?)s*(d{5})?$/;saveCityZipCode( address.match(cityZipCodeRegex)[1], address.match(cityZipCodeRegex)[2]);// 好的寫法const address = 'One Infinite Loop, Cupertino 95014';const cityZipCodeRegex = /^[^,]+[,s]+(.+?)s*(d{5})?$/;const [_, city, zipCode] = address.match(cityZipCodeRegex) || [];saveCityZipCode(city, zipCode);避免費腦的猜測
顯式用于隱式
// 不好的寫法const locations = ['Austin', 'New York', 'San Francisco'];locations.forEach(l => { doStuff(); doSomeOtherStuff(); // ... // ... // ... // 等等，“l”又是什么？ dispatch(l);// 好的寫法const locations = ['Austin', 'New York', 'San Francisco'];locations.forEach(location => { doStuff(); doSomeOtherStuff(); // ... // ... // ... dispatch(location);});無需添加不必要的上下文
如果類名/對象名已經說明了，就無需在變量名中重復。
// 不好的寫法const Car = { carMake: 'Honda', carModel: 'Accord', carColor: 'Blue'};function paintCar(car) { car.carColor = 'Red';}// 好的寫法const Car = { make: 'Honda', model: 'Accord', color: 'Blue'};function paintCar(car) { car.color = 'Red';}使用默認參數代替邏輯或(與)運算
// 不好的寫法function createMicrobrewery(name) { const breweryName = name || 'Hipster Brew Co.'; // ...}// 好的寫法function createMicrobrewery(name = 'Hipster Brew Co.') { // ...}函數函數參數（理想情況下為2個或更少）
限制函數參數的數量是非常重要的，因為它使測試函數變得更容易。如果有三個以上的參數，就會導致組合爆炸，必須用每個單獨的參數測試大量不同的情況。
一個或兩個參數是理想的情況，如果可能，應避免三個參數。 除此之外，還應該合并。大多數情況下，大于三個參數可以用對象來代替。
// 不好的寫法function createMenu(title, body, buttonText, cancellable) { // ...}createMenu('Foo', 'Bar', 'Baz', true);// 好的寫法function createMenu({ title, body, buttonText, cancellable }) { // ...}createMenu({ title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true});函數應該只做一件事
這是目前為止軟件工程中最重要的規則。當函數做不止一件事時，它們就更難組合、測試和推理。可以將一個函數隔離為一個操作時，就可以很容易地重構它，代碼也會讀起來更清晰。
// 不好的寫法function emailClients(clients) { clients.forEach(client => { const clientRecord = database.lookup(client); if (clientRecord.isActive()) { email(client); } });}// 好的寫法function emailActiveClients(clients) { clients.filter(isActiveClient).forEach(email);}function isActiveClient(client) { const clientRecord = database.lookup(client); return clientRecord.isActive();}函數名稱應說明其作用
// 不好的寫法function addToDate(date, month) { // ...}const date = new Date();// 從函數名稱很難知道添加什么addToDate(date, 1);// 好的寫法function addMonthToDate(month, date) { // ...}const date = new Date();addMonthToDate(1, date);函數應該只有一個抽象層次
當有一個以上的抽象層次函數，意味該函數做得太多了，需要將函數拆分可以實現可重用性和更簡單的測試。
// 不好的寫法function parseBetterjsAlternative(code) { const REGEXES = [ // ... ]; const statements = code.split(' '); const tokens = []; REGEXES.forEach(REGEX => { statements.forEach(statement => { // ... }); }); const ast = []; tokens.forEach(token => { // lex... }); ast.forEach(node => { // parse... });}// 好的寫法function parseBetterJSAlternative(code) { const tokens = tokenize(code); const syntaxTree = parse(tokens); syntaxTree.forEach(node => { // parse... });}function tokenize(code) { const REGEXES = [ // ... ]; const statements = code.split(' '); const tokens = []; REGEXES.forEach(REGEX => { statements.forEach(statement => { tokens.push(/* ... */); }); }); return tokens;}function parse(tokens) { const syntaxTree = []; tokens.forEach(token => { syntaxTree.push(/* ... */); }); return syntaxTree;}刪除重復的代碼
盡量避免重復的代碼，重復的代碼是不好的，它意味著如果我們需要更改某些邏輯，要改很多地方。
通常，有重復的代碼，是因為有兩個或多個稍有不同的事物，它們有很多共同點，但是它們之間的差異迫使我們編寫兩個或多個獨立的函數來完成許多相同的事情。 刪除重復的代碼意味著創建一個僅用一個函數/模塊/類就可以處理這組不同事物的抽象。
獲得正確的抽象是至關重要的，這就是為什么我們應該遵循類部分中列出的SOLID原則。糟糕的抽象可能比重復的代碼更糟糕，所以要小心!說了這么多，如果你能做一個好的抽象，那就去做吧!不要重復你自己，否則你會發現自己在任何時候想要改變一件事的時候都要更新多個地方。
設計模式的六大原則有：
Single Responsibility Principle：單一職責原則 Open Closed Principle：開閉原則 Liskov Substitution Principle：里氏替換原則 Law of Demeter：迪米特法則 Interface Segregation Principle：接口隔離原則 Dependence Inversion Principle：依賴倒置原則把這六個原則的首字母聯合起來（兩個 L 算做一個）就是 SOLID （solid，穩定的），其代表的含義就是這六個原則結合使用的好處：建立穩定、靈活、健壯的設計。下面我們來分別看一下這六大設計原則。
不好的寫法
function showDeveloperList(developers) { developers.forEach(developer => { const expectedSalary = developer.calculateExpectedSalary(); const experience = developer.getExperience(); const githubLink = developer.getGithubLink(); const data = { expectedSalary, experience, githubLink }; render(data); });}function showManagerList(managers) { managers.forEach(manager => { const expectedSalary = manager.calculateExpectedSalary(); const experience = manager.getExperience(); const portfolio = manager.getMBAProjects(); const data = { expectedSalary, experience, portfolio }; render(data); });}
好的寫法
function showEmployeeList(employees) { employees.forEach(employee => { const expectedSalary = employee.calculateExpectedSalary(); const experience = employee.getExperience(); const data = { expectedSalary, experience }; switch (employee.type) { case 'manager':data.portfolio = employee.getMBAProjects();break; case 'developer':data.githubLink = employee.getGithubLink();break; } render(data); });}使用Object.assign設置默認對象
不好的寫法
const 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);
好的寫法
const menuConfig = { title: 'Order', // User did not include ’body’ key buttonText: 'Send', cancellable: true};function createMenu(config) { config = Object.assign( { title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true }, config ); // config now equals: {title: 'Order', body: 'Bar', buttonText: 'Send', cancellable: true} // ...}createMenu(menuConfig);不要使用標志作為函數參數
標志告訴使用者，此函數可以完成多項任務，函數應該做一件事。 如果函數遵循基于布爾的不同代碼路徑，請拆分它們。
// 不好的寫法function createFile(name, temp) { if (temp) { fs.create(`./temp/${name}`); } else { fs.create(name); }}// 好的寫法function createFile(name) { fs.create(name);}function createTempFile(name) { createFile(`./temp/${name}`);}避免副作用(第一部分)
如果函數除了接受一個值并返回另一個值或多個值以外，不執行任何其他操作，都會產生副作用。 副作用可能是寫入文件，修改某些全局變量，或者不小心將你的所有資金都匯給了陌生人。
不好的寫法
let name = 'Ryan McDermott';function splitIntoFirstAndLastName() { name = name.split(' ');}splitIntoFirstAndLastName();console.log(name); // [’Ryan’, ’McDermott’];
好的寫法
function splitIntoFirstAndLastName(name) { return name.split(' ');}const name = 'Ryan McDermott';const newName = splitIntoFirstAndLastName(name);console.log(name); // ’Ryan McDermott’;console.log(newName); // [’Ryan’, ’McDermott’];避免副作用(第二部分)
在JavaScript中，原始類型值是按值傳遞，而對象/數組按引用傳遞。 對于對象和數組，如果有函數在購物車數組中進行了更改（例如，通過添加要購買的商品），則使用該購物車數組的任何其他函數都將受到此添加的影響。 那可能很棒，但是也可能不好。 來想象一個糟糕的情況：
用戶單擊“購買”按鈕，該按鈕調用一個purchase函數，接著，該函數發出一個網絡請求并將cart數組發送到服務器。由于網絡連接不好，purchase函數必須不斷重試請求。現在，如果在網絡請求開始之前，用戶不小心點擊了他們實際上不需要的項目上的“添加到購物車”按鈕，該怎么辦?如果發生這種情況，并且網絡請求開始，那么購買函數將發送意外添加的商品，因為它有一個對購物車數組的引用，addItemToCart函數通過添加修改了這個購物車數組。
一個很好的解決方案是addItemToCart總是克隆cart數組，編輯它，然后返回克隆。這可以確保購物車引用的其他函數不會受到任何更改的影響。
關于這種方法有兩點需要注意：
1.可能在某些情況下，我們確實需要修改輸入對象，但是當我們采用這種編程實踐時，會發現這種情況非常少見，大多數東西都可以被改造成沒有副作用。
2.就性能而言，克隆大對象可能會非常昂貴。 幸運的是，在實踐中這并不是一個大問題，因為有很多很棒的庫使這種編程方法能夠快速進行，并且不像手動克隆對象和數組那樣占用大量內存。
// 不好的寫法const addItemToCart = (cart, item) => { cart.push({ item, date: Date.now() });};// 好的寫法const addItemToCart = (cart, item) => { return [...cart, { item, date: Date.now() }];};不要寫全局函數
污染全局變量在 JS 中是一種不好的做法，因為可能會與另一個庫發生沖突，并且在他們的生產中遇到異常之前，API 的用戶將毫無用處。 讓我們考慮一個示例：如果想擴展 JS 的原生Array方法以具有可以顯示兩個數組之間差異的diff方法，該怎么辦？ 可以將新函數寫入Array.prototype，但它可能與另一個嘗試執行相同操作的庫發生沖突。 如果其他庫僅使用diff來查找數組的第一個元素和最后一個元素之間的區別怎么辦？ 這就是為什么只使用 ES6 類并簡單地擴展Array全局會更好的原因。
// 不好的寫法Array.prototype.diff = function diff(comparisonArray) { const hash = new Set(comparisonArray); return this.filter(elem => !hash.has(elem));};// 好的寫法class SuperArray extends Array { diff(comparisonArray) { const hash = new Set(comparisonArray); return this.filter(elem => !hash.has(elem)); }}盡量使用函數式編程而非命令式
JavaScript不像Haskell那樣是一種函數式語言，但它具有函數式的風格。函數式語言可以更簡潔、更容易測試。如果可以的話，盡量喜歡這種編程風格。
不好的寫法
const programmerOutput = [ { name: 'Uncle Bobby', linesOfCode: 500 }, { name: 'Suzie Q', linesOfCode: 1500 }, { name: 'Jimmy Gosling', linesOfCode: 150 }, { name: 'Gracie Hopper', linesOfCode: 1000 }];let totalOutput = 0;for (let i = 0; i < programmerOutput.length; i++) { totalOutput += programmerOutput[i].linesOfCode;}
好的寫法
const programmerOutput = [ { name: 'Uncle Bobby', linesOfCode: 500 }, { name: 'Suzie Q', linesOfCode: 1500 }, { name: 'Jimmy Gosling', linesOfCode: 150 }, { name: 'Gracie Hopper', linesOfCode: 1000 }];const totalOutput = programmerOutput.reduce( (totalLines, output) => totalLines + output.linesOfCode, 0);封裝條件
// 不好的寫法if (fsm.state === 'fetching' && isEmpty(listNode)) { // ...}// 好的寫法function shouldShowSpinner(fsm, listNode) { return fsm.state === 'fetching' && isEmpty(listNode);}if (shouldShowSpinner(fsmInstance, listNodeInstance)) { // ...}避免使用非條件
// 不好的寫法function isDOMNodeNotPresent(node) { // ...}if (!isDOMNodeNotPresent(node)) { // ...}// 好的寫法function isDOMNodePresent(node) { // ...}if (isDOMNodePresent(node)) { // ...}避免使用過多條件
這似乎是一個不可能完成的任務。一聽到這個，大多數人會說，“沒有if語句，我怎么能做任何事情呢?”答案是，你可以在許多情況下使用多態性來實現相同的任務。
第二個問題通常是，“那很好，但是我為什么要那樣做呢?”答案是上面講過一個概念:一個函數應該只做一件事。當具有if語句的類和函數時，這是在告訴你的使用者該函數執行不止一件事情。
不好的寫法
class Airplane { // ... getCruisingAltitude() { switch (this.type) { case '777':return this.getMaxAltitude() - this.getPassengerCount(); case 'Air Force One':return this.getMaxAltitude(); case 'Cessna':return this.getMaxAltitude() - this.getFuelExpenditure(); } }}
好的寫法
class Airplane { // ...}class Boeing777 extends Airplane { // ... getCruisingAltitude() { return this.getMaxAltitude() - this.getPassengerCount(); }}class AirForceOne extends Airplane { // ... getCruisingAltitude() { return this.getMaxAltitude(); }}class Cessna extends Airplane { // ... getCruisingAltitude() { return this.getMaxAltitude() - this.getFuelExpenditure(); }}避免類型檢查
JavaScript 是無類型的，這意味著函數可以接受任何類型的參數。 有時q我們會被這種自由所困擾，并且很想在函數中進行類型檢查。 有很多方法可以避免這樣做。 首先要考慮的是一致的API。
// 不好的寫法function travelToTexas(vehicle) { if (vehicle instanceof Bicycle) { vehicle.pedal(this.currentLocation, new Location('texas')); } else if (vehicle instanceof Car) { vehicle.drive(this.currentLocation, new Location('texas')); }}// 好的寫法function travelToTexas(vehicle) { vehicle.move(this.currentLocation, new Location('texas'));}不要過度優化
現代瀏覽器在運行時做了大量的優化工作。很多時候，如果你在優化，那么你只是在浪費時間。有很好的資源可以查看哪里缺乏優化，我們只需要針對需要優化的地方就行了。
// 不好的寫法// 在舊的瀏覽器上，每一次使用無緩存“list.length”的迭代都是很昂貴的// 會為“list.length”重新計算。在現代瀏覽器中，這是經過優化的for (let i = 0, len = list.length; i < len; i++) { // ...}// 好的寫法for (let i = 0; i < list.length; i++) { // ...}
以上就是如何寫出優雅的JS 代碼的詳細內容，更多關于優雅的JS 代碼的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備