1. 这篇文章真正要解决的问题在技术社区和日常开发交流中我们经常会遇到一个看似简单却影响深远的挑战如何高效、准确地命名项目、变量、函数甚至是一个临时的脚本文件。你可能觉得这不过是“起个名字而已”但无数项目后期的混乱、团队协作的摩擦、代码审查时的反复拉扯其根源往往就埋藏在这些最初看似随意的命名里。今天我们不谈高深的算法和架构就聚焦于这个最基础、最容易被忽视却又至关重要的工程实践——命名规范。为什么“命名”值得专门写一篇文章因为糟糕的命名是技术债的“高利贷”。一个被随意命名为sbdx假设是“傻逼东西”的缩写的模块在三个月后不仅原作者可能忘记其确切功能新接手的同事更是会一头雾水debug成本直线上升。更严重的是这种随意的文化会像病毒一样扩散侵蚀整个代码库的可读性和可维护性。本文要解决的就是帮你建立一套从认知到实践的命名心法让你彻底告别“起名困难症”写出让人包括未来的你一眼就能看懂的代码。我们将从“为什么好命名至关重要”这一认知破题然后拆解命名的核心原则与常见模式接着深入到不同语言如Java、Python、JavaScript和不同场景项目、变量、函数、数据库的具体实践最后给出可立即落地的检查清单和重构建议。读完本文你将获得的不是一堆死板的规则而是一种能够提升代码质量、促进团队协作的底层思维。2. 为什么糟糕的命名是“技术债”的源头在深入具体规则之前我们必须先达成一个共识命名不是装饰而是设计。它直接体现了开发者对问题域的理解深度和抽象能力。一个典型的反面案例就是使用无意义的缩写、拼音、甚至带有情绪的词汇如“傻逼东西”。假设我们有一个处理用户订单异常状态的函数如果命名为do_sbdx()它传达了零信息。其他开发者调用时必须跳转到函数定义内部阅读其实现逻辑才能明白它是做什么的。这造成了严重的认知断层和上下文切换成本。让我们量化一下糟糕命名的成本理解成本新成员需要额外时间 decipher破译代码意图。修改风险因为不理解真实功能修改时容易引入错误。协作效率在代码评审中需要花费大量时间讨论“这个名字到底指什么”。知识留存当关键人员离职那些晦涩的命名将成为项目“黑盒”。反之良好的命名如同代码的“自文档”。一个命名为retry_failed_payment(order_id, max_attempts3)的函数即使不看实现也能大致了解其职责、参数和边界。它降低了心智负担让开发者能聚焦于更复杂的逻辑而非记忆“sbdx”到底代表什么。3. 命名的基础原则从“意图”出发好的命名有章可循。下面四个原则是基石适用于任何编程语言和场景。3.1 原则一揭示意图Intention-Revealing名字应该告诉你它“为什么存在”、“做什么事”而不是“怎么实现”。差int d; // 经过的天数好int elapsed_days;或int days_since_creation;差function processData(list) {...}好function calculate_order_totals(orders) {...}3.2 原则二避免误导Avoid Disinformation名字不能提供虚假线索。例如不要用accountList来指代一个非列表如数组或集合类型的数据结构除非它真的是List。用accountGroup、accounts或bunchOfAccounts更好。避免使用外形相似的名字如XYZControllerForEfficientHandlingOfStrings和XYZControllerForEfficientStorageOfStrings极易看错。3.3 原则三做有意义的区分Make Meaningful Distinctions如果两个不同的东西名字相似那就要在名字上体现出有意义的区别。差copyData(data1, data2)和copyData2(data1, data2)。2没有意义。好copy_data_by_value(source, dest)和copy_data_by_reference(source, dest)。差Product类和ProductInfo类。Info没有提供有效区分。好Product核心实体和ProductInventory库存信息或ProductDescription描述信息。3.4 原则四使用可读的名称Use Pronounceable Names人类擅长用语言交流。如果名字读不出来讨论代码时就会变成“那个 s-b-d-x 函数”。差genymdhms(生成年月日时分秒)好generation_timestamp差class DtaRcrd102好class Customer4. 不同编程语言的命名规范实践原则是通用的但具体语法和社区习惯各有不同。遵循语言惯例能让你的代码更“地道”也便于工具如IDE、Linter识别。4.1 Java 命名规范Java 社区规范如Oracle官方约定非常成熟。类名/接口名大驼峰式PascalCase名词或名词短语。Customer,OrderService,AbstractController。方法名/变量名小驼峰式camelCase动词或动词短语开头。getUserName(),calculateTotalPrice(),isValid。常量名全大写下划线分隔。MAX_RETRY_COUNT,DEFAULT_TIMEOUT_MS。包名全小写点号分隔通常采用组织域名反写。com.example.project.module。示例对比差与好的命名// 差的命名意图模糊使用拼音缩写 public class Sbdx { private String yhm; // 用户名用户号 private Date cjsj; // 创建时间 public void cl() { // 处理测量 // ... 模糊的逻辑 } } // 好的命名清晰揭示意图 public class OrderProcessor { private String customerName; private Date orderCreationTime; public void validateAndProcessPayment() { // 方法名即注释 if (isPaymentValid()) { processPayment(); } } private boolean isPaymentValid() { ... } private void processPayment() { ... } }4.2 Python 命名规范遵循 PEP 8 风格指南。模块名/包名全小写短横线分隔包名下划线分隔模块名。my_package,utils.py。类名大驼峰式。BaseHTTPClient,CustomException。函数名/变量名/方法名/属性名小写下划线分隔蛇形命名法。get_user_data(),max_retries,instance_method。常量全大写下划线分隔。API_VERSION,DEFAULT_PORT。私有成员单下划线开头约定俗成。_internal_cache。避免与关键字冲突尾部加下划线。class_,type_。示例Python 命名# 差的命名随意缩写无意义 def sbdx_zl(data): 处理数据 for d in data: if d[zt] 1: # zt是什么状态 # ... 操作 return jg # jg是结果 # 好的命名清晰符合 PEP 8 def calculate_discounted_price(order_items, discount_rate): 计算订单商品折后总价 total_price 0.0 for item in order_items: if item[status] ACTIVE: total_price item[price] * item[quantity] discounted_total total_price * (1 - discount_rate) return round(discounted_total, 2) # 常量定义 MAX_ORDER_ITEMS 100 DEFAULT_DISCOUNT_RATE 0.14.3 JavaScript (包括Node.js与前端) 命名规范变量/函数名小驼峰式。userProfile,fetchData()。类名/构造函数名大驼峰式。class HttpClient,function Person(name) {...}。常量全大写下划线分隔。API_ENDPOINT。对于使用const定义且不会变的变量也常用此规则。私有成员ES6社区习惯使用#作为前缀真正私有或约定使用下划线_。#internalState,_privateMethod()。布尔变量/函数常以is,has,can,should开头。isLoading,hasPermission,shouldUpdate。示例JavaScript 命名// 差的命名 let sbdxArr []; // 这是什么数组 function cl() { // 处理什么 // ... } // 好的命名 let pendingOrders []; async function fetchUserOrders(userId) { try { const response await apiClient.get(/users/${userId}/orders); return response.data.orders.filter(order order.status PENDING); } catch (error) { console.error(Failed to fetch orders for user ${userId}:, error); throw new Error(Order fetch failed); } } // 常量与类 const MAX_RETRY_ATTEMPTS 3; class PaymentGateway { #apiKey; // 私有字段 constructor(apiKey) { this.#apiKey apiKey; } async charge(amount, currency) { // ... 支付逻辑 } }5. 特定场景的命名策略5.1 项目/模块/包命名简短、有意义user-service,payment-gateway,>public class TT { private ListMapString, Object sj; // “数据”的拼音缩写 public void cl() { // “处理”的拼音缩写 for (MapString, Object m : sj) { if ((int)m.get(“zt”) 1) { // “状态”的拼音 // 一些复杂的业务逻辑 System.out.println(m.get(“mc”)); // “名称”的拼音 } } } }重构步骤理解逻辑首先我们需要读懂这段代码。它遍历一个列表列表中的元素是Map当Map中zt键的值为1时打印mc键的值。这看起来像是在筛选并打印某种“活跃”项目的名称。创建有意义的类名TT毫无意义。根据其持有的数据sj和行为cl它可能是一个“数据处理器”或“报告生成器”。假设上下文是订单我们可以命名为OrderReportGenerator。重构字段名sj-orders或orderList。使用具体的类型如ListOrder代替Map是更佳选择但这里先改名字。重构方法名cl-printActiveOrderNames明确其行为。重构键名常量将魔法字符串“zt”和“mc”提取为常量并赋予有意义的名字。引入对象模型进阶最好的重构是引入Order类用order.getStatus()和order.getName()代替Map查找。重构后代码public class OrderReportGenerator { private ListMapString, Object rawOrders; // 定义键名常量避免魔法字符串 private static final String KEY_STATUS “status”; private static final String KEY_NAME “name”; private static final int STATUS_ACTIVE 1; public void printActiveOrderNames() { for (MapString, Object order : rawOrders) { // 使用常量更安全意图更清晰 Integer status (Integer) order.get(KEY_STATUS); if (status ! null status STATUS_ACTIVE) { String name (String) order.get(KEY_NAME); if (name ! null) { System.out.println(name); } } } } // 更理想的重构使用强类型对象 // private ListOrder orders; // public void printActiveOrderNames() { // orders.stream() // .filter(order - order.getStatus() OrderStatus.ACTIVE) // .map(Order::getName) // .forEach(System.out::println); // } }7. 常见命名“坑”与排查清单即使知道了原则实践中仍会踩坑。下面是一个快速自查清单。问题现象可能原因排查与改进方式看到名字不知道是干嘛的使用了无意义的缩写、拼音或过于通用的词如data,info,util。问自己这个名字能直接回答“它是什么”或“它做什么”吗如果不能用更具体的名词或动词短语替换。两个名字看起来太像容易混淆缺乏有意义的区分如UserDatavsUserInfo。找出两者的核心差异并在名字中体现。是UserProfile资料 vsUserCredentials凭证还是UserInput输入 vsUserOutput输出名字太长影响可读性试图把太多信息塞进一个名字。审视作用域。在小的局部作用域如短函数内可以使用短名字i,item。在大的作用域如类名、全局常量名字应完整。也可以考虑是否应该拆分这个过大的概念。名字与实现不符函数名是getX但内部还做了修改操作。确保名字准确反映行为。get应是纯读取如果涉及修改应命名为calculateAndUpdateX或拆分成两个函数。团队内命名风格不一致缺乏统一的编码规范。引入并强制执行团队代码规范如使用 Checkstyle, ESLint, Pylint并在代码评审中重点关注命名。可以制定团队的《命名约定》文档。8. 最佳实践与工程建议制定并遵守团队规范在项目启动时就约定好命名规范参考哪份指南、缩进、括号风格等。使用.editorconfig,prettier,eslint,checkstyle等工具自动化格式化。命名是设计的一部分在写代码前先想好名字。如果发现很难起一个好名字这往往是一个信号你可能还没把这个概念想清楚或者它的职责过于复杂需要考虑拆分单一职责原则。保持一致性在整个代码库中对同一概念使用相同的词汇。如果叫Customer就不要在另一个模块叫Client或User除非它们确实是不同的业务概念。适时重构不要害怕修改坏名字。现代IDE的重构工具重命名非常强大且安全可以同步更新所有引用点。早期重构的成本远低于后期维护的代价。在代码评审中关注命名将命名清晰度作为代码评审的核心标准之一。问评审者“只看这个名字和签名你能猜出它是做什么的吗”为布尔函数取个好名字is,has,can开头的函数能让条件判断读起来像自然语言极大提升可读性。if (user.canEdit(document))比if (checkEditPermission(user, document))更直观。9. 总结与行动指南命名这件“小事”实则是软件工程基石的一部分。它关乎代码的可读性、可维护性最终关乎团队的生产力和项目的长期健康。从今天起你可以立即采取以下行动意识觉醒在写下每一个名字变量、函数、类、文件时停顿一秒问自己“这个名字能清晰地传达我的意图吗”局部实践从你正在开发或修改的一个模块开始有意识地应用本文的原则优化其中的命名。工具辅助为你使用的语言配置代码检查工具Linter让机器帮你捕捉常见的命名问题。团队倡导在下次技术分享或团队会议中讨论命名的重要性并共同制定或完善团队的命名约定。记住好的代码是写给人类看的只是恰好能被机器执行。而一个好名字就是这段代码写给读者的第一句也是最关键的一句自我介绍。别再让你精心编写的逻辑埋没在像“傻逼东西”这样随意的标签之下。从命名的艺术开始编写出真正专业、优雅、经得起时间考验的代码。 告别命名困难症：从原则到实践，打造自文档化代码
1. 这篇文章真正要解决的问题在技术社区和日常开发交流中我们经常会遇到一个看似简单却影响深远的挑战如何高效、准确地命名项目、变量、函数甚至是一个临时的脚本文件。你可能觉得这不过是“起个名字而已”但无数项目后期的混乱、团队协作的摩擦、代码审查时的反复拉扯其根源往往就埋藏在这些最初看似随意的命名里。今天我们不谈高深的算法和架构就聚焦于这个最基础、最容易被忽视却又至关重要的工程实践——命名规范。为什么“命名”值得专门写一篇文章因为糟糕的命名是技术债的“高利贷”。一个被随意命名为sbdx假设是“傻逼东西”的缩写的模块在三个月后不仅原作者可能忘记其确切功能新接手的同事更是会一头雾水debug成本直线上升。更严重的是这种随意的文化会像病毒一样扩散侵蚀整个代码库的可读性和可维护性。本文要解决的就是帮你建立一套从认知到实践的命名心法让你彻底告别“起名困难症”写出让人包括未来的你一眼就能看懂的代码。我们将从“为什么好命名至关重要”这一认知破题然后拆解命名的核心原则与常见模式接着深入到不同语言如Java、Python、JavaScript和不同场景项目、变量、函数、数据库的具体实践最后给出可立即落地的检查清单和重构建议。读完本文你将获得的不是一堆死板的规则而是一种能够提升代码质量、促进团队协作的底层思维。2. 为什么糟糕的命名是“技术债”的源头在深入具体规则之前我们必须先达成一个共识命名不是装饰而是设计。它直接体现了开发者对问题域的理解深度和抽象能力。一个典型的反面案例就是使用无意义的缩写、拼音、甚至带有情绪的词汇如“傻逼东西”。假设我们有一个处理用户订单异常状态的函数如果命名为do_sbdx()它传达了零信息。其他开发者调用时必须跳转到函数定义内部阅读其实现逻辑才能明白它是做什么的。这造成了严重的认知断层和上下文切换成本。让我们量化一下糟糕命名的成本理解成本新成员需要额外时间 decipher破译代码意图。修改风险因为不理解真实功能修改时容易引入错误。协作效率在代码评审中需要花费大量时间讨论“这个名字到底指什么”。知识留存当关键人员离职那些晦涩的命名将成为项目“黑盒”。反之良好的命名如同代码的“自文档”。一个命名为retry_failed_payment(order_id, max_attempts3)的函数即使不看实现也能大致了解其职责、参数和边界。它降低了心智负担让开发者能聚焦于更复杂的逻辑而非记忆“sbdx”到底代表什么。3. 命名的基础原则从“意图”出发好的命名有章可循。下面四个原则是基石适用于任何编程语言和场景。3.1 原则一揭示意图Intention-Revealing名字应该告诉你它“为什么存在”、“做什么事”而不是“怎么实现”。差int d; // 经过的天数好int elapsed_days;或int days_since_creation;差function processData(list) {...}好function calculate_order_totals(orders) {...}3.2 原则二避免误导Avoid Disinformation名字不能提供虚假线索。例如不要用accountList来指代一个非列表如数组或集合类型的数据结构除非它真的是List。用accountGroup、accounts或bunchOfAccounts更好。避免使用外形相似的名字如XYZControllerForEfficientHandlingOfStrings和XYZControllerForEfficientStorageOfStrings极易看错。3.3 原则三做有意义的区分Make Meaningful Distinctions如果两个不同的东西名字相似那就要在名字上体现出有意义的区别。差copyData(data1, data2)和copyData2(data1, data2)。2没有意义。好copy_data_by_value(source, dest)和copy_data_by_reference(source, dest)。差Product类和ProductInfo类。Info没有提供有效区分。好Product核心实体和ProductInventory库存信息或ProductDescription描述信息。3.4 原则四使用可读的名称Use Pronounceable Names人类擅长用语言交流。如果名字读不出来讨论代码时就会变成“那个 s-b-d-x 函数”。差genymdhms(生成年月日时分秒)好generation_timestamp差class DtaRcrd102好class Customer4. 不同编程语言的命名规范实践原则是通用的但具体语法和社区习惯各有不同。遵循语言惯例能让你的代码更“地道”也便于工具如IDE、Linter识别。4.1 Java 命名规范Java 社区规范如Oracle官方约定非常成熟。类名/接口名大驼峰式PascalCase名词或名词短语。Customer,OrderService,AbstractController。方法名/变量名小驼峰式camelCase动词或动词短语开头。getUserName(),calculateTotalPrice(),isValid。常量名全大写下划线分隔。MAX_RETRY_COUNT,DEFAULT_TIMEOUT_MS。包名全小写点号分隔通常采用组织域名反写。com.example.project.module。示例对比差与好的命名// 差的命名意图模糊使用拼音缩写 public class Sbdx { private String yhm; // 用户名用户号 private Date cjsj; // 创建时间 public void cl() { // 处理测量 // ... 模糊的逻辑 } } // 好的命名清晰揭示意图 public class OrderProcessor { private String customerName; private Date orderCreationTime; public void validateAndProcessPayment() { // 方法名即注释 if (isPaymentValid()) { processPayment(); } } private boolean isPaymentValid() { ... } private void processPayment() { ... } }4.2 Python 命名规范遵循 PEP 8 风格指南。模块名/包名全小写短横线分隔包名下划线分隔模块名。my_package,utils.py。类名大驼峰式。BaseHTTPClient,CustomException。函数名/变量名/方法名/属性名小写下划线分隔蛇形命名法。get_user_data(),max_retries,instance_method。常量全大写下划线分隔。API_VERSION,DEFAULT_PORT。私有成员单下划线开头约定俗成。_internal_cache。避免与关键字冲突尾部加下划线。class_,type_。示例Python 命名# 差的命名随意缩写无意义 def sbdx_zl(data): 处理数据 for d in data: if d[zt] 1: # zt是什么状态 # ... 操作 return jg # jg是结果 # 好的命名清晰符合 PEP 8 def calculate_discounted_price(order_items, discount_rate): 计算订单商品折后总价 total_price 0.0 for item in order_items: if item[status] ACTIVE: total_price item[price] * item[quantity] discounted_total total_price * (1 - discount_rate) return round(discounted_total, 2) # 常量定义 MAX_ORDER_ITEMS 100 DEFAULT_DISCOUNT_RATE 0.14.3 JavaScript (包括Node.js与前端) 命名规范变量/函数名小驼峰式。userProfile,fetchData()。类名/构造函数名大驼峰式。class HttpClient,function Person(name) {...}。常量全大写下划线分隔。API_ENDPOINT。对于使用const定义且不会变的变量也常用此规则。私有成员ES6社区习惯使用#作为前缀真正私有或约定使用下划线_。#internalState,_privateMethod()。布尔变量/函数常以is,has,can,should开头。isLoading,hasPermission,shouldUpdate。示例JavaScript 命名// 差的命名 let sbdxArr []; // 这是什么数组 function cl() { // 处理什么 // ... } // 好的命名 let pendingOrders []; async function fetchUserOrders(userId) { try { const response await apiClient.get(/users/${userId}/orders); return response.data.orders.filter(order order.status PENDING); } catch (error) { console.error(Failed to fetch orders for user ${userId}:, error); throw new Error(Order fetch failed); } } // 常量与类 const MAX_RETRY_ATTEMPTS 3; class PaymentGateway { #apiKey; // 私有字段 constructor(apiKey) { this.#apiKey apiKey; } async charge(amount, currency) { // ... 支付逻辑 } }5. 特定场景的命名策略5.1 项目/模块/包命名简短、有意义user-service,payment-gateway,>public class TT { private ListMapString, Object sj; // “数据”的拼音缩写 public void cl() { // “处理”的拼音缩写 for (MapString, Object m : sj) { if ((int)m.get(“zt”) 1) { // “状态”的拼音 // 一些复杂的业务逻辑 System.out.println(m.get(“mc”)); // “名称”的拼音 } } } }重构步骤理解逻辑首先我们需要读懂这段代码。它遍历一个列表列表中的元素是Map当Map中zt键的值为1时打印mc键的值。这看起来像是在筛选并打印某种“活跃”项目的名称。创建有意义的类名TT毫无意义。根据其持有的数据sj和行为cl它可能是一个“数据处理器”或“报告生成器”。假设上下文是订单我们可以命名为OrderReportGenerator。重构字段名sj-orders或orderList。使用具体的类型如ListOrder代替Map是更佳选择但这里先改名字。重构方法名cl-printActiveOrderNames明确其行为。重构键名常量将魔法字符串“zt”和“mc”提取为常量并赋予有意义的名字。引入对象模型进阶最好的重构是引入Order类用order.getStatus()和order.getName()代替Map查找。重构后代码public class OrderReportGenerator { private ListMapString, Object rawOrders; // 定义键名常量避免魔法字符串 private static final String KEY_STATUS “status”; private static final String KEY_NAME “name”; private static final int STATUS_ACTIVE 1; public void printActiveOrderNames() { for (MapString, Object order : rawOrders) { // 使用常量更安全意图更清晰 Integer status (Integer) order.get(KEY_STATUS); if (status ! null status STATUS_ACTIVE) { String name (String) order.get(KEY_NAME); if (name ! null) { System.out.println(name); } } } } // 更理想的重构使用强类型对象 // private ListOrder orders; // public void printActiveOrderNames() { // orders.stream() // .filter(order - order.getStatus() OrderStatus.ACTIVE) // .map(Order::getName) // .forEach(System.out::println); // } }7. 常见命名“坑”与排查清单即使知道了原则实践中仍会踩坑。下面是一个快速自查清单。问题现象可能原因排查与改进方式看到名字不知道是干嘛的使用了无意义的缩写、拼音或过于通用的词如data,info,util。问自己这个名字能直接回答“它是什么”或“它做什么”吗如果不能用更具体的名词或动词短语替换。两个名字看起来太像容易混淆缺乏有意义的区分如UserDatavsUserInfo。找出两者的核心差异并在名字中体现。是UserProfile资料 vsUserCredentials凭证还是UserInput输入 vsUserOutput输出名字太长影响可读性试图把太多信息塞进一个名字。审视作用域。在小的局部作用域如短函数内可以使用短名字i,item。在大的作用域如类名、全局常量名字应完整。也可以考虑是否应该拆分这个过大的概念。名字与实现不符函数名是getX但内部还做了修改操作。确保名字准确反映行为。get应是纯读取如果涉及修改应命名为calculateAndUpdateX或拆分成两个函数。团队内命名风格不一致缺乏统一的编码规范。引入并强制执行团队代码规范如使用 Checkstyle, ESLint, Pylint并在代码评审中重点关注命名。可以制定团队的《命名约定》文档。8. 最佳实践与工程建议制定并遵守团队规范在项目启动时就约定好命名规范参考哪份指南、缩进、括号风格等。使用.editorconfig,prettier,eslint,checkstyle等工具自动化格式化。命名是设计的一部分在写代码前先想好名字。如果发现很难起一个好名字这往往是一个信号你可能还没把这个概念想清楚或者它的职责过于复杂需要考虑拆分单一职责原则。保持一致性在整个代码库中对同一概念使用相同的词汇。如果叫Customer就不要在另一个模块叫Client或User除非它们确实是不同的业务概念。适时重构不要害怕修改坏名字。现代IDE的重构工具重命名非常强大且安全可以同步更新所有引用点。早期重构的成本远低于后期维护的代价。在代码评审中关注命名将命名清晰度作为代码评审的核心标准之一。问评审者“只看这个名字和签名你能猜出它是做什么的吗”为布尔函数取个好名字is,has,can开头的函数能让条件判断读起来像自然语言极大提升可读性。if (user.canEdit(document))比if (checkEditPermission(user, document))更直观。9. 总结与行动指南命名这件“小事”实则是软件工程基石的一部分。它关乎代码的可读性、可维护性最终关乎团队的生产力和项目的长期健康。从今天起你可以立即采取以下行动意识觉醒在写下每一个名字变量、函数、类、文件时停顿一秒问自己“这个名字能清晰地传达我的意图吗”局部实践从你正在开发或修改的一个模块开始有意识地应用本文的原则优化其中的命名。工具辅助为你使用的语言配置代码检查工具Linter让机器帮你捕捉常见的命名问题。团队倡导在下次技术分享或团队会议中讨论命名的重要性并共同制定或完善团队的命名约定。记住好的代码是写给人类看的只是恰好能被机器执行。而一个好名字就是这段代码写给读者的第一句也是最关键的一句自我介绍。别再让你精心编写的逻辑埋没在像“傻逼东西”这样随意的标签之下。从命名的艺术开始编写出真正专业、优雅、经得起时间考验的代码。