開發(fā)人員需要思考大量日常工作，這已不是什么秘密。他們的部分心思總是花在各種日常事務上，例如 "我應該把這個函數(shù)放在哪個模塊中？"、"我應該如何給這個變量命名？"或 "這個變量應該做什么？"。盡管這些問題看似簡單瑣碎，卻一直在消耗著人們的腦力資源。然而，如果有辦法通過自動化一些常規(guī)任務來簡化這一過程，從而將注意力集中到更重要的事情上，那么利用這些方法無疑是有意義的。

在這種情況下，命名約定發(fā)揮著至關重要的作用。掌握知識并明智地使用這些約定有助于增強代碼的可讀性、簡化理解并減輕開發(fā)人員的認知負擔。然而，并非所有開發(fā)人員都知道，有時甚至會忘記如何正確應用這些約定，從而無意識地將注意力轉(zhuǎn)移到看似更重要的事情上。這反過來又會使代碼的可讀性和理解復雜化，使表面上 "更關鍵 "的任務變得比實際上更復雜。

下面是我有機會參與的一個真實項目的截圖。記下每個導入項。嘗試根據(jù)名稱猜測我們可以從每個導入項中獲得什么項目。

Pasted image 20231122113525.png

在本文中，我們將探討其中的大部分，了解或提醒自己在為編寫的結(jié)構(gòu)體選擇名稱時最好遵循哪些原則。這將幫助您和今后使用您代碼的任何人（無論是您的團隊還是您自己）避免臆測，并提高代碼的可讀性。

JavaScript 命名約定

本文將包括一系列命名建議。我不希望你將它們視為唯一的真理。首先，事實并非完全如此，因為大多數(shù)建議都附有免責聲明，指出存在許多例外情況，暗示約定本身并不涵蓋所有情況。其次，雖然 JavaScript 社區(qū)接受了大多數(shù)建議，但出于各種原因，并不是每個人都會遵循這些建議，而且有些建議會根據(jù)特定團隊的需要進行部分或大幅修改。

這篇文章的主旨是，每個項目都應建立自己的命名慣例，無論這些慣例是與廣泛采用的慣例相一致，還是與你的團隊獨有的慣例相一致。最重要的是制定并遵守約定。

一般規(guī)則

互聯(lián)網(wǎng)上有大量關于最佳命名實踐的文章。眾所周知的慣例強調(diào)，名稱應簡短，更重要的是應易于理解。名稱應該具體，符合使用環(huán)境，并能一目了然地傳達代碼的含義。實際上，這些規(guī)則不僅適用于 JavaScript，也適用于任何編程語言。在這些一般規(guī)則中，我想重點談談約定中的一些具體細節(jié)，它們廣為人知，但經(jīng)常被遺忘或沒有得到完全遵守。

統(tǒng)一性

在 JavaScript 項目中，有許多約定俗成的慣例，但最值得遵守的是在單個項目中保持一致的編碼風格。參與不同項目的人員比任何人都清楚，不同項目之間的編寫風格會有很大差異。

應用程序的不同部分由不同團隊開發(fā)或在開發(fā)過程中使用不同技術的情況經(jīng)常出現(xiàn)。命名約定可能因所選編程語言或開發(fā)團隊的偏好而不同。盡管存在這些差異，應用程序的不同部分仍需要相互交互，例如前臺和后臺之間的數(shù)據(jù)交換。例如，從后端請求的數(shù)據(jù)的命名風格可能與前端代碼中使用的風格不同。

我們無權(quán)評判使用不同的命名方式是好是壞，因為可能會有各種原因?qū)е逻@種選擇。不過，明確混合兩種或多種命名方式可能會帶來挑戰(zhàn)。對于新加入項目的開發(fā)人員來說，理解正在發(fā)生的事情并決定使用哪種命名方式可能會變得相當具有挑戰(zhàn)性。

// Bad 
const hasAccess = checkHasUserAccess(session.current_user) && checkIsPageVisible(session.current_page)

// Good
const hasAccess = checkHasUserAccess(session.currentUser) && checkIsPageVisible(session.currentPage)

// Also good, if such a naming case is preferred
const has_access = check_has_user_access(session.current_user) && check_is_page_visible(session.current_page)

解決這一問題的方法有多種，包括使用重命名與析構(gòu)、導入重命名、使用映射函數(shù)（如 Array.prototype.map()），以及使用適配器設計模式等更高級的方法。

關鍵是要采用一致的方法，不僅在命名規(guī)則上，而且在完成任務的方式上。在可能的情況下，優(yōu)先選擇單一方法來完成特定操作。避免強迫自己和其他開發(fā)人員花費時間和額外的精神資源來決定使用哪種方法?？紤]將此類任務（尤其是與編碼風格相關的任務）委托給 ESLint 等工具。

僅限英文

盡管在 JavaScript 中可以使用非拉丁字母，但不建議這樣做。雖然不會出現(xiàn)任何編程錯誤，但強烈不建議使用英語以外的任何語言。即使是為自己編寫代碼，每段代碼都有 "長壽 "的能力，也許有一天您需要與其他開發(fā)人員共享這些代碼。對于其他開發(fā)人員，尤其是來自不同國家的開發(fā)人員來說，很難理解代碼中發(fā)生了什么。

在強調(diào)只使用英語時，人們往往只想到鍵盤布局。然而，我們不應忘記縮寫和名稱簡稱的普遍使用?？s寫和簡寫只應用于公認的單詞，如 idx 、 err 、 evt 、 xhr 、 src 及其他社會上歷史上公認的單詞。在其他情況下，我們強烈反對使用縮略詞和詞的簡寫形式，因為它們往往會導致混淆，而且破譯它們會耗費大量時間。

// Bad
const 新規(guī)ユーザーのウェルカムメッセージ = 'こんにちは'
const usrInf = { fName: 'John', lName: 'Doe' }
const isAdult = a >= 18

// Good
const newUserWelcomeMessage = 'こんにちは'
const userInfo = { firstName: 'John', lastName: 'Doe' }
const isAdult = userAge >= 18

此外，建議在代碼編輯器中啟用拼寫檢查程序，它將突出顯示單詞中的語法錯誤。在許多編輯器中，它都是默認啟用的，對于某些編輯器，您可能需要安裝一個擴展，如 VS Code 的 Code Spell Checker。如今的拼寫檢查程序已經(jīng)足夠智能，大多數(shù)常用縮寫和單詞簡寫都不會被標記為錯誤。

不僅是 camelCase

許多資源都強調(diào)，在使用 JavaScript 編寫時，只能使用 camelCase 符號。然而，這并不完全準確。該建議更多的是要遵守語言本身使用的符號。雖然 JavaScript 語言中有很大一部分是使用 camelCase 編寫的，但并不普遍。下面是幾個例子：

parseInt('18') // camelCase
new RegExp('[A-Z]', 'i') // PascalCase
Number.MAX_SAFE_INTEGER // PascalCase + UPPER_SNAKE_CASE

正如我們所看到的，JavaScript 不僅使用了 camelCase 符號，還使用了其他一些符號。JavaScript 中的所有類和構(gòu)造函數(shù)都是使用 PascalCase 符號編寫的。在聲明自定義類和構(gòu)造函數(shù)時，通常會遵循與語言本身相同的命名約定。這同樣適用于表示固定值的常量。無論是內(nèi)置的 JavaScript 常量還是開發(fā)人員創(chuàng)建的常量，都習慣使用 UPPER_SNAKE_CASE 命名。

有些編程語言在編寫應用程序接口（API）時，會使用各種不同的情況，而沒有明確的分配，相比之下，JavaScript 的應用程序接口（API）就不存在這個問題。因此，我們習慣于遵守語言本身的約定。

遵循readme.md

假設您正在使用 axios 這樣的網(wǎng)絡請求庫，而該庫的 README 建議使用標準名稱 axios 進行導入。

import httpRequester from 'npm:axios'

// Somewhere very far at the bottom of the file
httpRequester('https://example.com')

將名稱從 axios 更改為 httpRequester 可能會導致混亂和錯誤，因為其他開發(fā)人員在開發(fā)該項目時，如果期望使用標準名稱 axios 可能會遇到問題。因此，請務必遵守庫 README 中的建議，以確保兼容性和代碼理解。

乍一看， axios 庫的示例似乎并無大礙，但在使用深度集成到項目中的更復雜的庫和框架時，也會出現(xiàn)類似的重命名情況。采用有意義重命名做法的團隊需要創(chuàng)建自己的文檔，因為新團隊成員無法在官方文檔中找到足夠的信息來理解技術使用風格的變化。

通常情況下，將有意義的重命名轉(zhuǎn)換為更抽象的名稱，會與依賴反轉(zhuǎn)原則結(jié)合使用。不過，理解這里的細微差別很重要。您和您的團隊必須清楚地了解您在做什么以及為什么這樣做，因為在采用這種做法時需要保持平衡。

無數(shù)據(jù)類型

在變量名中包含數(shù)據(jù)類型可能很誘人，但屈從于這種誘惑往往會給變量名增加不必要的語義負擔。例如，使用 arr 作為包含數(shù)組的變量名，可能會在其他地方使用同名變量時產(chǎn)生沖突。此外，名稱 arr 并不能傳達有意義的信息。使名稱更具體（如 userArr ）是一種改進，但并不能解決所有問題。

// Bad
const userNameMinLengthConst = 3
const userObj = getUser()
const getUniqueUserNames = (arr) => Array.from(new Set(arr))

// Good
const USER_NAME_MIN_LENGTH_COUNT = 3
const user = getUser()
const getUniqueUserNames = (names) => Array.from(new Set(names))

對于每種語言結(jié)構(gòu)體，無論是內(nèi)置的還是自定義的數(shù)據(jù)結(jié)構(gòu)，都有一種常規(guī)的方法來表示值的預期數(shù)據(jù)類型。這反映在結(jié)構(gòu)體的名稱中，該名稱應與已確立的社區(qū)約定和團隊內(nèi)部約定保持一致。建議優(yōu)先考慮社區(qū)約定，因為解釋廣為接受的東西通常比引入完全獨特的東西更容易。如果是社區(qū)約定俗成的東西，你可以讓別人參考互聯(lián)網(wǎng)上的文章，而對于團隊特定的約定俗成的東西，你可能需要自己撰寫這篇文章。

具體規(guī)則

在本節(jié)中，我們將討論數(shù)據(jù)類型和數(shù)據(jù)結(jié)構(gòu)的具體命名規(guī)則。雖然 JavaScript 的內(nèi)置數(shù)據(jù)類型和結(jié)構(gòu)看起來很有限，但它卻提供了廣泛的功能。這些功能包括各種方法，而在其他編程語言中，這些方法通常被劃分為不同的內(nèi)置類型或數(shù)據(jù)結(jié)構(gòu)。

例如，在 JavaScript 中，一個對象可以作為 enum 、 map ( dictionary )、 graph 等。JavaScript 中的 number 數(shù)據(jù)類型包括處理整數(shù)和浮點數(shù)。根據(jù)具體要求，JavaScript 數(shù)據(jù)類型和結(jié)構(gòu)可以靈活調(diào)整使用，這為 JavaScript 提供了多樣性和強大的功能。

在這種情況下，命名約定的重要性就顯而易見了。它們不僅能提高代碼的可讀性，還能防止在與代碼庫的其他部分交互時出現(xiàn)混淆和錯誤。良好的命名規(guī)范可確保代碼的清晰度，并有助于其他開發(fā)人員理解數(shù)據(jù)結(jié)構(gòu)及其用途，從而提高團隊內(nèi)部的協(xié)作效率。

布爾值

布爾值的名稱應以肯定前綴開頭，即前綴應回答 "是 "的問題。雖然有幾個肯定詞語（should、can、will 等）可以回答 "是"，但建議首選兩個最常用的詞語 - is 和 has 。雖然使用其他肯定詞語不會被視為錯誤，但應將其作為例外情況處理，如果可能，最好避免使用。

這一約定還有一個經(jīng)常被忽視的重要補充，即肯定前綴不應包含否定。這是因為否定操作符 ( ! ) 最常用于布爾值。因此，一個名為 isNotAllowed 的值如果應用了否定操作符 !isNotAllowed ，就會產(chǎn)生相當大的誤導。不信？那就試著快速找出 !!isNotAllowed （雙重否定）等于什么。即使你能很快做到，想象一下，在實際代碼中，所有這些否定反轉(zhuǎn)都散布在整個文件中。跟蹤這些邏輯，尤其是當這些邏輯很多的時候，可能會相當具有挑戰(zhàn)性。在這種情況下，最好改變布爾變量的評估邏輯，在其名稱中使用肯定肯定。

// Bad
const userLogin = user !== null

const user = {
  friend: false,
}

const isNotUserRemoved = userActionState !== ActionState.REMOVED
if (isNotUserRemoved) { /* some logic */ }

// Good
const isUserAuthorized = user !== null
const hasUser = user !== null

const user = {
  hasFriend: false,
}

const isUserRemoved = userActionState === ActionState.REMOVED
if (!isUserRemoved) { /* some logic */ }

除了在布爾名稱中使用肯定前綴這一約定之外，我們還偏離了 W3C 規(guī)范的建議，因為它建議不要在布爾名稱中使用這些前綴。這與前面提到的優(yōu)先選擇語言本身使用的慣例的觀點相矛盾。不過，凡事都有例外，這就是其中之一。這是正常的，因為規(guī)范作者的思維方式可能與社區(qū)的觀點不同。

JavaScript 是很久以前創(chuàng)建的，在創(chuàng)建之初，作者決定不在布爾名稱中使用肯定前綴。現(xiàn)在，即使與社區(qū)的意見相悖，他們也會盡力繼續(xù)遵循自己的約定。即使作者想在規(guī)范中引入新的命名約定，他們也做不到，至少做不到連貫一致。舊代碼不能重新命名，因為 JavaScript 必須保持向后兼容。使用新方法開始編寫新代碼也不是一個好主意，因為做同一件事會有兩種方法，這也是不可取的。

例外是正常的。世界上沒有任何事物是完美無缺的。即使是規(guī)范本身也有例外 - node.isContentEditable 或 evt.isTrusted 。關鍵是在遵守先前約定的同時，盡量減少例外情況。

函數(shù)和方法

函數(shù)/方法的名稱應為動詞，并與其執(zhí)行的操作相對應。

// Bad
const userNaming = (name) => name.charAt(0).toUpperCase() + name.slice(1)

const user = {
  name: 'John',
  action() {
    console.log('Hey')
  },
}

const userPermissions = (userId) => permissionRepository.getByUserId(userId)

// Good
const getCapitalizedUserName = (name) => name.charAt(0).toUpperCase() + name.slice(1)

const user = {
  name: 'John',
  sayHello() {
    console.log('Hey')
  },
}

const getUserPermissions = (userId) => permissionRepository.getByUserId(userId)

雖然函數(shù)/方法的命名約定乍看之下似乎很簡單，但它們的命名卻有最多的例外和其他約定。

• 遵循 JavaScript 的寫作風格（ Number.isNaN() 、 Array.isArray() 、 salary.toFixed() 、構(gòu)造函數(shù)等）。
• 事件處理函數(shù)的命名約定（ onBtnClick 、 onImgMouseOver 等）
• 庫函數(shù)，例如 Redux 庫中的還原器函數(shù)（ const users = (state, action) => { /* some logic */ } ）、React 中的功能組件（ const UserDashboard = () => { /* component */ } ），以及庫和框架提出的許多其他例外和約定。

您可以通過直接使用這些函數(shù)和方法來了解它們。不過，對于大多數(shù)函數(shù)和方法而言，其名稱應為動詞并與其執(zhí)行的操作相對應這一主要約定保持不變。

集合和迭代器

命名規(guī)則如下--如果使用迭代器或索引集合（例如， Array , NodeList , FileList 等），名稱應為復數(shù)名詞。否則，如果使用鍵集合（ Set , Map ），并且我們只對可以通過鍵獲得的值（通常使用 Array.from() 或擴展語法）感興趣，那么命名約定將保持不變--名稱應為復數(shù)名詞。但是，如果在鍵集合中鍵對我們也很重要，那么這類集合就應該使用單數(shù)名詞命名，并在名稱末尾添加一個前綴，表示一組東西。例如， Collection , List , Group 等。

一個重要的補充是，這一約定也應適用于用戶使用迭代協(xié)議創(chuàng)建的索引或鍵值集合。

// Bad
const userRoleArr = Object.values(UserRole)

const usersAccordionList = document.querySelectorAll('.users-accordion__list-item',)

const groupPermissions = new Map(Object.entries(Object.groupBy(permissions, (permission) => permission.group)))

// Good
const userRoles = Object.values(UserRole)

const usersAccordionItemNodes = document.querySelectorAll('.users-accordion__list-item',)

const permissionsByGroupList = new Map(Object.entries(Object.groupBy(permissions, (permission) => permission.group)))

類

在使用類時，必須遵守幾個約定。下面是一個列表：

• 使用 PascalCase 作為類名，采用與 JavaScript 類和構(gòu)造函數(shù)相同的大小寫樣式。
• 類名應為單數(shù)名詞。
• 所有類成員的名稱不應包括類名稱。

// Bad
class userService { /* class members */ }

class Permissions { /* class members */ }

class UserAuthPopup {
  isPopupOpen = false

  openPopup() {
    this.isPopupOpen = true
  }
}

// Good
class UserService { /* class members */ }

class PermissionService { /* class mmebers */ }

class UserAuthPopup {
  isOpen = false

  open() {
    this.isOpen = true
  }
}

如果試圖在其成員名稱中使用類名，則很可能是該類的邏輯負載過重，或者負責的事情超過了它應該負責的范圍。在這種情況下，往往會出現(xiàn)違反 "單一責任原則 "的情況。為避免這種情況，建議創(chuàng)建更多的類，并使用繼承或依賴注入來限制每個類的責任。

常量

用于描述程序執(zhí)行前已知的值，這些值在程序執(zhí)行過程中不應發(fā)生變化。

常量是組織程序代碼的一種重要且被廣泛采用的方法。關于命名約定，開發(fā)人員之間有一個重要的共識：常量的名稱應使用 UPPER_SNAKE_CASE 符號來書寫。

const userFailingLoginAttempts = 3 

const USER_ROLE = calculateUserRole(user)

let userDefaultAuthMethod = 'mfa'

// Good
const USER_FAILING_LOGIN_ATTEMPTS_COUNT = 3

const userRole = calculateUserRole(user)

let USER_DEFAULT_AUTH_METHOD = 'mfa'

雖然在 JavaScript 中聲明變量和常量有多種方法，但只使用 const 關鍵字似乎是合乎邏輯的，因為這樣可以防止在程序執(zhí)行過程中對其進行更改，但有些團隊卻不愿意為選擇變量聲明的關鍵字而操心。他們可能會使用 ESLint 等自動化工具來強制程序代碼中的變量聲明只使用 let 關鍵字。

同樣，每個團隊都不盡相同，每個團隊都可能有自己的慣例。但是，即使是禁止使用看似更合適的結(jié)構(gòu)和關鍵詞，也不能說明應該如何做或如何命名。命名總是比使用任何關鍵詞更有意義。這就是為什么命名是代碼編寫的一個重要方面。

枚舉

也稱為枚舉。在 JavaScript 中，這種數(shù)據(jù)結(jié)構(gòu)用于枚舉一組固定值。

許多其他編程語言都有單獨的枚舉數(shù)據(jù)類型，而 JavaScript 卻沒有這種數(shù)據(jù)類型（至少目前還沒有）。相反，要在 JavaScript 中模擬枚舉，可以使用普通對象，但要遵守特定的命名約定。下面列出了這些命名約定：

• 枚舉名稱應以大寫字母開頭。
• 枚舉名稱應使用單數(shù)名詞。
• 枚舉的鍵值應大寫。

// Bad
const userRole = {
  admin: 'admin',
  guest: 'guest',
}

const USER_API_PATHS = {
  root: '/',
  users$Id: '/users/:id',
}

const userValidationRules = {
  MIN_PASSWORD_LENGTH: 8,
  MAX_NAME_LENGTH: 20,
  VALID_REFERRER_DOMAINS: ['google.com'],
}

// Good
const UserRole = {
  ADMIN: 'admin',
  GUEST: 'guest',
}

const UserApiPath = {
  ROOT: '/',
  USERS_$ID: '/users/:id',
}

const UserValidationRule = {
  MIN_PASSWORD_LENGTH: 8,
  MAX_NAME_LENGTH: 20,
  VALID_REFERRER_DOMAINS: ['google.com'],
}

由于 TypeScript 已成為 JavaScript 開發(fā)的重要組成部分，因此值得一提的是，TypeScript 使用 enum 關鍵字來表示枚舉。如果您決定在您的團隊中使用 TypeScript 的枚舉，那么習慣上也要遵循相同的命名約定。

映射(Maps)

也稱為 dictionary 數(shù)據(jù)結(jié)構(gòu)。這種數(shù)據(jù)結(jié)構(gòu)用于將一個值映射到另一個值。

在任何編程語言中，地圖都是一種非常有用且經(jīng)常使用的數(shù)據(jù)結(jié)構(gòu)。對于 JavaScript 世界中的地圖，有一個特定的命名約定。名稱應遵循 aToB 的模式，其中 a 是從映射表中檢索值的鍵，其后是介詞 To 表示兩個事物的映射，然后是 B 表示 a 的映射值。

// Bad
const userRolesReadable = {
  [UserRole.ADMIN]: 'Administrator',
  [UserRole.GUEST]: 'Guest',
}

const REDIRECTING = {
  '/groups': '/admin-login',
  '/profile': '/login',
}

const UserPermissions = {
  [UserRole.ADMIN]: [Permission.MANAGE_USERS, Permission.MANAGE_GROUPS],
  [UserRole.GUEST]: [Permission.EDIT_PROFILE],
}

// Good
const userRoleToReadable = {
  [UserRole.ADMIN]: 'Administrator',
  [UserRole.GUEST]: 'Guest',
}

const pagePathToRedirectPath = {
  '/groups': '/admin-login',
  '/profile': '/login',
}

const userRoleToPermissions = {
  [UserRole.ADMIN]: [Permission.MANAGE_USERS, Permission.MANAGE_GROUPS],
  [UserRole.GUEST]: [Permission.EDIT_PROFILE],
}

JavaScript 中有一個內(nèi)置的 Map 類。它與普通對象的主要區(qū)別在于可以使用任何數(shù)據(jù)類型（甚至是對象）作為鍵。通常情況下，使用本機 Map 類創(chuàng)建映射作為數(shù)據(jù)結(jié)構(gòu)是多余的。但是，如果需要本地 Map 提供的功能，則可以使用它來創(chuàng)建映射數(shù)據(jù)結(jié)構(gòu)。在大多數(shù)情況下，使用普通對象就足夠了。

類型和接口

如前所述，TypeScript 已成為當今 JavaScript 開發(fā)中不可或缺的一部分。一般來說，在大多數(shù)情況下，類型和接口是可以互換的。不過，由于關于選擇哪一種類型的討論已經(jīng)夠多了，在本文中，我們將特別關注命名問題。對于類型和接口，存在以下命名約定：

• 類型和接口的名稱應以 PascalCase 符號書寫。
• 名稱應盡可能直截了當?shù)孛枋鲱愋突蚪涌诘挠猛荆?const user: User = getUserById(id) / const users: User[] = getUsers() 。
• 如果開發(fā)團隊決定在一個代碼庫中同時使用類型和接口，建議為接口添加一個前綴來區(qū)分它們。最常用的前綴是 I 和 Contract 。

// Bad
type TUser = {
  firstName: string
  lastName: string
}

interface user {
  firstName: string
  lastName: string
}

interface userServiceInterface {
  findByEmail: (email: string) => User
}

// Good
type User = {
  firstName: string
  lastName: string
}

interface User {
  firstName: string
  lastName: string
}

interface UserServiceContract {
  findByEmail: (email: string) => User
}
interface IUserService {
  findByEmail: (email: string) => User
}

重要的是要認識到，盡管本文對 JavaScript 命名約定進行了廣泛的概述，但并不能涵蓋所有可能的情況。即使在本文介紹的要點中，也應考慮到許多例外情況。命名過程雖然是最基本的，但也意味著應用的靈活性，要考慮到每個項目的獨特功能和要求。

結(jié)論

在開發(fā)過程中，我們經(jīng)常鉆研復雜的技術細節(jié)，卻忘記了細節(jié)往往蘊含著力量。多年的開發(fā)經(jīng)驗告訴我們，關注細節(jié)（如命名）對于創(chuàng)建高效、可讀性強的代碼至關重要。在開發(fā)人員的日常工作中，簡單明了、無需思考如何命名一個值以及如何快速理解該值所包含的內(nèi)容，這些都會給開發(fā)人員帶來難以置信的輕松感。

如果一個開發(fā)人員的變量沒有清晰的命名，他還能認為自己很強大嗎？清晰的命名不僅能讓其他開發(fā)人員更容易理解代碼，也能讓程序員自己更容易理解代碼，從而提高開發(fā)效率，減少錯誤。

經(jīng)常出現(xiàn)的情況是，搜索不良命名會導致發(fā)現(xiàn)不良代碼。這只能說明命名規(guī)范是代碼質(zhì)量的一個指標。正確的命名反映了對細節(jié)的關注，反過來也說明了開發(fā)過程中的細心。

下面是在應用本文討論的約定時，從介紹部分導入值的情況?，F(xiàn)在看起來清晰多了，不是嗎？我相信，現(xiàn)在你理解每個導入值的含義所花費的精力會少很多。

Pasted image 20231122113525.png

總之，必須記住，命名標準固然重要，但并非絕對。每個項目都有其特殊性，因此確定自己的約定至關重要。最重要的是，它們應該存在，并且您應該遵守它們，以確保代碼的一致性并提高集體的工作效率。此外，如果可能的話，盡量將代碼風格問題委托給 ESLint 等工具來簡化和改進開發(fā)流程。

英文原文