关于命名

create on in simple_record with 0 comment and 116 view

我们在编码时,变量、方法的命名其实非常重要,它一定程度上决定代码的可读性和可维护性,好的变量命名能让我们的代码质量有质的提升

所以,平时总结相关命名就显得非常重要了.

命名类型

关于命名的好坏,似乎也没有一个标准,我个人认为一个变量的命名从差到好有以下类型:

类型1: 混沌型

此类命名毫无章法,词不达意,表达个人情绪等等

a
a1…23
fuck
bb
c_Uim

类型2: 词不达意型

此类命名通常没有正确表达业务逻辑的含义, 常见于开发者没有了解业务、不知如何命名、命名错误等

响应 -> rep(no) -> res(yes)
用户列表 -> list(no) -> userList(yes)

类型3: 无格式型

没有遵循峰驼式或下划线等统一风格,或多种风格混用.
getuserbackgroundcolor(no) -> getUserBackgroundColor
User-Name(no) -> userName
user_Name_find(no) -> userNameFind

类型4: 偷懒型

此类命名为了达一时之快而进行的命名,特征为使用汉语拼音,音汉混用,使用数字命名等.

shangjia
shangjiaStatus
page1,page2,page3,pages4

类型5: 冗长型

此类命名过于冗长,导致代码量大以及可读性不是很好,需要适当的进行缩写以改进.

managerReciveInformation(no) -> mgrRecvInfo(yes)
response(no) -> res(yes)

类型6: 推荐型

这种类型就是将上面几种都改进后得到的, 也是本文要做的事.
要达到这种类型,总的来说值得关注以下:

  1. 尽量不使用数字命名
  2. 使用峰驼式或下划线等格式
  3. 多积累专业英语词汇,不使用拼音命名(特殊情况除外)
  4. 开发团队内应统一常见的业务命名
  5. 多积累专业英语的缩写

命名和缩写

逐渐的我开始意识到, 总结一些常见的命名缩写是很有必要的,以下则是我积累的词汇(不断更新中):

>>> 点击传送门 <<<

😁😂😃😄😅😆😇😈😉😐😑😒😓😔😕😖😗😘😙😠😡😢😣😤😥😦😧😨😩😰😱😲😳😴😵😶😷😸😹🙀🙁🙂🙃🙄🙅🙆🙇🙈
🙂