阿里云主机折上折
  • 微信号
您当前的位置:网站首页 > 滥用缩写(如 'usrPwdChk' 代替 'userPasswordCheck')

滥用缩写(如 'usrPwdChk' 代替 'userPasswordCheck')

作者:陈川 阅读数:44167人阅读 分类: 前端综合

滥用缩写(如 'usrPwdChk' 代替 'userPasswordCheck')

代码里充斥着各种缩写,比如把 userPasswordCheck 写成 usrPwdChk,把 calculateTotalPrice 写成 calcTotPrc,把 getUserInformation 写成 getUsrInf。这种缩写看似节省了敲键盘的时间,但实际上却给代码的可读性和可维护性带来了巨大的灾难。

为什么缩写是维护的噩梦

缩写最大的问题在于它的不明确性。同一个缩写可能有多种解释,不同的人可能有不同的理解。例如,usr 可以代表 user,也可以代表 usernamepwd 可以代表 password,也可以代表 print working directory(在 Unix 系统中)。这种歧义会导致代码难以理解,甚至引发错误。

// 糟糕的例子:缩写导致歧义
function valUsrInpt(inpt) {
  // val 是 validate 还是 value?
  // usr 是 user 还是 username?
  // inpt 是 input 还是 integer part?
  // 完全看不懂这个函数在做什么
  return inpt.length > 0;
}

缩写的代价远超你的想象

虽然缩写看起来节省了时间,但实际上它带来的维护成本远远超过你节省的那点打字时间。当其他开发者(甚至未来的你自己)阅读代码时,他们需要花费额外的时间去猜测这些缩写的含义。这种认知负担会显著降低开发效率,并增加出错的可能性。

// 好的例子:清晰明确的命名
function validateUserInput(input) {
  // 一眼就能看出这个函数的作用
  return input.length > 0;
}

缩写的“传染性”

缩写还具有传染性。一旦你在代码中开始使用缩写,其他人很可能会效仿,甚至变本加厉。最终,整个代码库都会充斥着各种晦涩难懂的缩写,变成一个难以维护的“缩写地狱”。

// 糟糕的例子:缩写的传染性
function procOrd(ord) {
  const ordDet = getOrdDet(ord.id);
  const custInf = getCustInf(ord.custId);
  const totAmt = calcTotAmt(ordDet);
  // ... 更多的缩写
}

如何优雅地避免缩写

避免缩写其实很简单:使用完整、清晰的单词。虽然这样会让变量名和函数名稍微长一点,但它们的可读性和可维护性会大大提高。现代 IDE 都支持代码补全,所以你根本不需要担心打字的问题。

// 好的例子:清晰完整的命名
function processOrder(order) {
  const orderDetails = getOrderDetails(order.id);
  const customerInfo = getCustomerInfo(order.customerId);
  const totalAmount = calculateTotalAmount(orderDetails);
  // ... 清晰的代码
}

一些常见的缩写陷阱

以下是一些常见的缩写陷阱,以及它们的完整形式:

  • usruser
  • pwdpassword
  • chkcheck
  • calccalculate
  • valvalidatevalue
  • infinformation
  • detdetails
  • amtamount
  • ordorder
  • custcustomer

什么时候可以使用缩写

虽然大多数情况下应该避免缩写,但在一些广泛接受且无歧义的情况下,缩写是可以接受的。例如:

  • ijk 用于循环计数器
  • id 代表 identifier
  • max 代表 maximum
  • min 代表 minimum
  • avg 代表 average
// 可以接受的缩写
for (let i = 0; i < array.length; i++) {
  // i 作为循环计数器是广泛接受的
}

团队协作中的命名约定

在团队协作中,制定统一的命名约定非常重要。确保所有成员都遵循相同的命名规则,避免个人喜好的缩写混入代码库。可以使用工具如 ESLint 来强制执行命名约定。

// ESLint 规则示例:强制使用完整的单词
{
  "rules": {
    "id-length": ["error", { "min": 3 }], // 避免过短的缩写
    "camelcase": ["error", { "properties": "always" }] // 强制驼峰命名
  }
}

缩写与代码压缩

有些人可能会担心使用完整的单词会增加代码体积,影响性能。但实际上,现代代码压缩工具(如 Webpack、UglifyJS)会在构建过程中将变量名和函数名缩短为单个字母或简短的标识符。因此,在源代码中使用完整的单词完全不会影响最终的生产代码。

// 源代码:使用完整的单词
function calculateTotalPrice(items) {
  return items.reduce((total, item) => total + item.price, 0);
}

// 压缩后的代码:变量名被缩短
function n(t){return t.reduce((t,e)=>t+e.price,0)}

历史遗留代码中的缩写

如果你接手了一个充满缩写的历史遗留代码库,不要绝望。可以逐步进行重构,将缩写替换为完整的单词。每次修改相关代码时,顺便修复其中的缩写。同时,添加清晰的注释和文档,帮助其他开发者理解这些缩写,直到它们被完全替换。

// 历史遗留代码
function updUsrInf(usrId, inf) {
  // ... 晦涩的逻辑
}

// 重构后的代码
function updateUserInformation(userId, information) {
  // ... 清晰的逻辑
}

缩写与国际化团队

在国际化团队中,缩写的问题更加严重。非母语开发者可能无法理解某些缩写的含义,导致沟通障碍和代码理解困难。使用完整的单词可以大大降低这种沟通成本。

// 糟糕的例子:非母语开发者可能不理解
function chkAuthTok(tok) {
  // chk 是 check 还是 chalk?
  // tok 是 token 还是 talk?
}

// 好的例子:清晰的命名
function checkAuthorizationToken(token) {
  // 任何开发者都能理解
}

缩写与自动补全

现代 IDE 和编辑器都支持强大的自动补全功能。使用完整的单词实际上可以提高编码效率,因为你只需要输入前几个字母,IDE 就会自动补全整个单词。相比之下,缩写反而需要你记住更多的“秘密代码”。

// 使用自动补全
// 输入 "val" → 自动补全为 "validate"
// 输入 "user" → 自动补全为 "userInformation"
// 比记住 "usrInf" 容易多了

缩写与代码搜索

完整的单词使得代码搜索更加高效。你可以轻松地搜索 userInformation,而不用猜测它可能被缩写为 usrInfuserInfusrInfo 还是其他形式。

# 在代码库中搜索完整的单词
grep -r "userInformation" src/

# 如果使用缩写,你可能需要搜索多个变体
grep -r "usrInf\|userInf\|usrInfo" src/

缩写与文档生成

许多文档生成工具(如 JSDoc)依赖于函数和变量的名称来生成文档。使用完整的单词可以使生成的文档更加清晰和专业。

/**
 * 计算订单总金额
 * @param {Array} orderDetails - 订单详情列表
 * @returns {number} 总金额
 */
function calculateTotalAmount(orderDetails) {
  // ... 清晰的实现
}

// 生成的文档会非常清晰
// 如果使用缩写如 "calcTotAmt",文档会显得不专业

缩写与代码审查

在代码审查中,缩写往往会引发更多的讨论和争议。审查者可能需要花费额外的时间来理解这些缩写的含义,从而降低审查效率。使用完整的单词可以使代码审查更加流畅。

// 代码审查中的对话
// 审查者:这个 "usrPwdChk" 是什么意思?
// 开发者:哦,是 "userPasswordCheck"
// 审查者:那为什么不直接写 "userPasswordCheck"?
// ... 浪费时间的讨论

缩写与新手开发者

对于新手开发者来说,缩写是一个巨大的障碍。他们可能还没有熟悉所有的缩写惯例,阅读充满缩写的代码会让他们感到困惑和沮丧。清晰的命名可以帮助新手更快地融入团队。

// 新手的困惑
// "这个 'calcTotPrc' 是什么意思?是 'calculateTotalPrice' 还是 'calculateTotalProcess'?"
// "这个 'valUsrInpt' 是在验证用户输入还是在获取用户输入的值?"

缩写与代码重用

清晰的命名可以提高代码的可重用性。其他开发者在复用你的代码时,不需要花费时间去解密各种缩写,可以更快地理解代码的功能和用法。

// 清晰的命名使得代码更容易被复用
function validateEmailAddress(email) {
  // ... 清晰的实现
}

// 其他开发者可以轻松地理解和使用这个函数
// 如果命名为 "valEml",他们可能会犹豫或误解

缩写与调试

在调试过程中,清晰的命名可以帮助你更快地定位问题。看到 userPassword 比看到 usrPwd 更能让你立刻理解这个变量的用途和可能的问题。

// 调试时的困惑
// "这个 'usrPwd' 的值为什么是空的?它是从哪里来的?"
// 如果命名为 'userPassword',你可能立刻想到是登录表单中的密码字段

缩写与代码美学

有些人认为缩写可以让代码看起来更“简洁”或“专业”,但实际上,清晰的命名才是真正专业的体现。代码的首要目标是传达意图,而不是展示编写者的打字速度。

// 真正的专业代码
function calculateMonthlyRevenue(salesData) {
  // ... 清晰的实现
}

// 看似“简洁”实则晦涩的代码
function calcMthRev(slsDt) {
  // ... 难以理解的实现
}

缩写与变量作用域

变量的作用域越大,它的名称就应该越清晰。全局变量或模块级变量绝对不应该使用缩写,因为它们的可见范围广,影响深远。即使是局部变量,也应该尽量使用清晰的命名。

// 糟糕的例子:全局变量使用缩写
let usrSess = getCurrentSession();

// 好的例子:全局变量使用完整名称
let userSession = getCurrentSession();

// 即使是局部变量,也建议使用清晰命名
function processOrder(order) {
  const shippingAddress = order.shippingAddress; // 清晰
  // 而不是 const shpAddr = order.shippingAddress;
}

缩写与常量命名

常量通常用于表示不变的值,它们的命名应该特别清晰,因为它们的值在程序运行期间不会改变,因此名称需要传达足够的信息。

// 糟糕的例子:常量使用缩写
const MAX_USR_CNT = 100;

// 好的例子:常量使用完整名称
const MAXIMUM_USER_COUNT = 100;

缩写与布尔变量

布尔变量通常表示某种状态或条件,它们的命名应该清楚地表达其含义。使用缩写会导致难以理解的逻辑。

// 糟糕的例子:布尔变量使用缩写
let isAuth = checkAuthorization();
if (isAuth) {
  // isAuth 是 "isAuthorized" 还是 "isAuthenticationValid"?
}

// 好的例子:布尔变量使用完整名称
let isUserAuthorized = checkAuthorization();
if (isUserAuthorized) {
  // 清晰明确
}

缩写与 API 设计

在设计 API 时,清晰的命名尤为重要。API 会被其他开发者频繁使用,晦涩的缩写会导致大量的文档需求和困惑。

// 糟糕的 API 设计:使用缩写
class UsrMgr {
  addUsr(usrInf) {
    // ...
  }
}

// 好的 API 设计:使用完整名称
class UserManager {
  addUser(userInformation) {
    // ...
  }
}

缩写与测试代码

测试代码尤其需要清晰的命名,因为测试的目的是验证代码的正确性。晦涩的缩写会使得测试难以理解和维护。

// 糟糕的例子:测试代码使用缩写
it('shld val usr inpt', () => {
  const rslt = valUsrInpt('test');
  xpct(rslt).toBe(true);
});

// 好的例子:测试代码使用完整名称
it('should validate user input', () => {
  const result = validateUserInput('test');
  expect(result).toBe(true);
});

缩写与错误信息

错误信息应该尽可能清晰,帮助开发者快速定位问题。使用缩写会导致错误信息难以理解。

// 糟糕的例子:错误信息使用缩写
throw new Error('Inv usr pwd');

// 好的例子:错误信息使用完整名称
throw new Error('Invalid user password');

缩写与日志记录

日志信息同样需要清晰明确,因为它们通常用于故障排查。晦涩的缩写会使得日志分析变得困难。

// 糟糕的例子:日志使用缩写
console.log('Usr login fail: inv cred');

// 好的例子:日志使用完整名称
console.log('User login failed: invalid credentials');

缩写与配置项

配置项通常会被不同层级的开发者查看和修改,清晰的命名尤为重要。

// 糟糕的例子:配置项使用缩写
const config = {
  dbConnStr: '...',
  maxConn: 10,
  srvTimeout: 5000
};

// 好的例子:配置项使用完整名称
const config = {
  databaseConnectionString: '...',
  maximumConnections: 10,
  serverTimeoutMilliseconds: 5000
};

缩写与枚举类型

枚举类型的值应该特别清晰,因为它们通常代表固定的选项集合。

// 糟糕的例子:枚举使用缩写
const UserRole = {
  ADM: 'Admin',
  MGR: 'Manager',
  USR: 'User'
};

// 好的例子:枚举使用完整名称
const UserRole = {
  ADMINISTRATOR: 'Administrator',
  MANAGER: 'Manager',
  USER: 'User'
};

缩写与类型定义

在使用 TypeScript 或 Flow 等类型系统时,类型名称应该清晰表达其用途。

// 糟糕的例子:类型定义使用缩写
type UsrInf = {
  nm: string;
  eml: string;
};

// 好的例子:类型定义使用完整名称
type UserInformation = {
  name: string;
  email: string;
};

缩写与 React 组件

React 组件名称应该清楚地表达其功能和用途。

// 糟糕的例子:组件名称使用缩写
function UsrCard({ usrInf }) {
  return <div>{usrInf.nm}</div>;
}

// 好的例子:组件名称使用完整名称
function UserCard({ userInformation }) {
  return <div>{userInformation.name}</div>;
}

缩写与 CSS 类名

CSS 类名同样需要清晰明确,因为它们会影响样式的可维护性。

/* 糟糕的例子:CSS 类名使用缩写 */
.usr-prof {
  /* ... */
}

/* 好的例子:CSS 类名使用完整名称 */
.user-profile {
  /* ... */
}

缩写与性能优化

有些人可能会认为使用缩写可以减少文件大小,提高性能。但实际上,这种微小的优化在现代 web 开发中几乎可以忽略不计,而且完全可以通过构建工具来实现,不应该牺牲代码的可读性。

// 不值得的“优化”
// 将 "userInformation" 改为 "usrInf" 节省了 12 个字符
// 但使得代码难以理解
// 更好的做法是使用构建工具进行压缩

缩写与代码示例

在编写代码示例或教程时,清晰的命名尤为重要,因为读者需要快速理解代码的意图。

// 糟糕的教程示例
function calcTot(arr) {
  return arr.reduce((a, b) => a + b, 0);
}

// 好的教程示例
function calculateTotal(numbers) {
  return numbers.reduce((sum, number) => sum + number, 0);
}

缩写与开源项目

在开源项目中,清晰的命名更为重要,因为代码会被来自世界各地的开发者阅读和贡献。晦涩的缩写会成为贡献的障碍。

// 开源项目中的糟糕实践
function prsMd(mdTxt) {
  // ... 解析 Markdown 的逻辑
}

// 好的实践
function parseMarkdown(markdownText) {
  // ... 清晰的实现
}

缩写与职业发展

编写清晰、易维护的代码是专业开发者的标志。过度依赖缩写可能会给人留下不专业的印象,影响职业发展。

// 不专业的代码
function updOrdSts(ordId, sts) {
  // ... 晦涩的实现
}

// 专业的代码
function updateOrderStatus(orderId, status) {
  // ... 清晰的实现
}

缩写与代码审查工具

现代代码审查工具(如 GitHub PR)会显示差异对比。清晰的命名可以使差异更加易于理解。

// 清晰的差异对比
- function validateUserInput(input) {
+ function validateUserInput(input, options) {
// 晦涩的差异对比
- function valUsrInpt(inpt) {
+ function valUsrInpt(inpt, opts) {

缩写与移动开发

在移动开发中,资源可能更加有限,但清晰的命名仍然比微小的节省更重要。现代的移动设备完全能够处理稍长的变量名。

// Android 开发中的糟糕实践
String usrNm = getUserNm();

// 好的实践
String userName = getUserName();

缩写与函数式编程

在函数式编程中,函数名称应该清晰地表达其功能和意图。

// 糟糕的例子:函数式编程中的缩写
const addUsr = usr => users => [...users, usr];

// 好的例子:清晰的命名
const addUserToCollection = user => users => [...users, user];

缩写与异步代码

异步代码本身已经比较复杂,清晰的命名可以帮助理解代码的执行流程。

// 糟糕的例子:异步代码中的缩写
async function getUsrData(usrId) {
  const usr = await fetchUsr(usrId);
  const ords = await fetchOrds(usrId);
  return { usr, ords };
}

// 好的例子:清晰的命名
async function getUserDataWithOrders(userId) {
  const user = await fetchUser(userId);
  const orders = await fetchOrders(userId);
  return { user, orders };
}

缩写与正则表达式

即使是正则表达式,相关的变量名也应该清晰表达其用途。

//

本站部分内容来自互联网,一切版权均归源网站或源作者所有。

如果侵犯了你的权益请来信告知我们删除。邮箱:cc@cccx.cn

前端川

前端川,陈川的代码茶馆🍵,专治各种不服的Bug退散符💻,日常贩卖秃头警告级的开发心得🛠️,附赠一行代码笑十年的摸鱼宝典🐟,偶尔掉落咖啡杯里泡开的像素级浪漫☕。‌