There are only two hard things in Computer Science: cache invalidation and naming things.
节后第一天,无心敲代码,随意聊聊命名这件事吧。(别问为什么不聊缓存失效,问就是不会)
对于大多数码农来说,命名确实是一个很大的难题。我们往往会花费很多时间在命名上,一个好的命名对于代码可读性提升的帮助是巨大的。
一、遵循规范
一个优雅的命名必定是严格遵循一定的规范的,这个规范既指行业通用规范也包括公司团队内部的规范。不符合规范的命名对于代码可读性的破坏力是巨大的。
zhuanhuanweiriqi //拼音命名,不符合规范convertstandardtermtodate //全部小写,不符合规范convertStandardTermToDate //采用小驼峰命名复制代码
上面的几个命名表达了同一个意思,但是很显然前两个命名如果出现在我们的代码中无疑是一场灾难,最后一个采用了小驼峰命名对于代码可读性的提升则是显而易见的。
二、表意清晰
命名最基本也最重要的一点就是表意要清晰。每一个变量、方法都应该能够见名知义。在小白程序的代码中经常会看到list1,list2,fun1,fun2
这样的命名。这样的命名在项目或者页面内容较少的时候也许还能勉强阅读。但是会极大的降低代码的可扩展和可维护性。
但是还有一种情况下会给我们命名带来困扰,比如我们在用户管理中最常见的几个命名问题:userList
和users
都可以用来表示用户列表;getUsers
和getUserList
都可以用来获取用户列表;getUserById, getUserInfoById, queryUser, ...
。当我们遇到这种多个命名意义相近的无法取舍的时候,我们需要做的事情就又回到了第一点,让项目团队约定其中一种命名方法并且统一地运用到所有模块。
三、功能的合理拆分
通常,如果我们想不到一个合适的命名或者命名过长,这意味着我们的代码里一定出现了不合理的设计。比如goOutToPlayFootball
显而易见的可以被拆分成goOut
和playFootball
两个更单一的方法,这样做的好处是不言而喻的,既简化了命名增强了代码可读性,又降低了耦合度,还提高了代码的可扩展性。
四、整合工具类
我们经常需要是实现一些功能相近的方法,比如日期相关的一些方法,我们就可以创建一个名为dateUtil
的集合,把所有日期相关的方法放到dateUtil
内部去实现,比如数字格式化的方法可以放在numberFormatter
里面等等。
结语
快跑题了,就此打住吧。
命名确实是一件挺难的事情,要在巨量的词汇库中挑选出一两个词来表达出最正确和具体的意思。但这也不是一件坏事,它可以迫使我们去思考我们的方法和组件到底要需要实现怎样的功能。每一次命名都给了我们一次代码审查和优化的机会,我们要学会珍惜。
随手写了点自己的体会,权当抛砖引玉,大家可以一起交流下心得。你们对命名这件事又是怎么看的呢?