代码整洁之道--命名规范
给代码命名真的是一件很头疼的事情，对于命名规则，有一些基础的编码者，都会知道使用驼峰命名，比如userName,designPattern这样的驼峰命名法，这很酷，还有命名的时候不要使用什么int a、int b 这样的命名，但除此之外呢？命名的时候还需要做写什么？在《代码整洁之道》这本书中，对命名规则有其他需要值得我们学习的地方，让我们来看看
1、命名要有意义
如何去表示多少天这个概念，int day?这看上去是个不错的选择，至少在我很长一段时间都喜欢这样取名字，但其实这样取名字是不好的，因为day这个概念是一个广义的概念,可以在它的基础上根据业务场景延申出很多day,比如elapsedTimeInDay（拖延天数），daysSinceCreation(创建天数)等，可能最开始你的类里面需要一个字段，记录某个计划执行了多少天，你int day记录这个字段，在后期，又需要加其他的比如超时时间，你又需要加一个day表示，但是因为已经有一个day字段了，所以只能定义成一个overtimeDay,这样你的方法中，有一个day,一个overtimeDay，这对代码可读性来说简直是灾难，如果你想去修改其中一个变量，那就得修改所以使用这个day变量的代码，数据库字段名称，与其这样，比如取名的时候就不要为了图方便而随意取名，要考虑后期扩展。
2、避免误导
l、o在编辑器中，很容易被误认为是1和0，应该避免使用起来定义变量，定义类名，类的名称避免和一些常用的API类名称重合，会导致在使用的时候分不清哪个是自己的，哪个是api的
3、使用能读出来的单词作为变量名称
我们作为名称的单词应该做到是可以读出来的单词，有时候我们需要描绘的事务，可能需要好几个单词才能表达我们的意思，比如（发送信息模拟器）Sending information simulator，不推荐为了压缩命名的长度，简写成sis或者是siSimulaor这种格式，长的读的出名字的单词命名大于短的失去其含义的单词更能表达代码的意义。
4、使用常量去代替固定的字符
int salary = 0;
for(int i=0; i<21; i++){
salary += 190;
}
System.out.println(salary);
看下面这段简单的代码，计算21天的工资并输出，在这里一眼就能明白，因为代码很少，没有上下文的干扰，但是如果是在一段复杂的业务逻辑中，当你看到这段代码中的两个数字，21和190，你能立刻知道这是什么意思么？如何去改进这段代码使其能更容易理解？
运用常量去代替固定的符合，有助于理解，还有在全文检索的时候
ACTUAL_WORKING_DAYS 也比21更容易找到5、避免使用成员前缀
在《代码整洁之道》书中，作者不推荐使用成员前缀，就是IService,m_apple这种，用I表示这个类是个接口，m_表示这是个成员变量。
6、坚守自己的命名，不要被他人影响
并不是每个人都会严格遵循命名的规范，可能你的前辈为了项目进度，或者懒得像，在一个函数中，同时出现了list1,list2,list3,在你接手后，不要有反正这代码已经很烂了，那我也定义一个list4,list5,千万不要有这样的心态
7、命名应该严谨，不要开玩笑
可能你觉得代码好无聊，就想用一些梗作为命名，比如说robberyShop(抢劫)，定义成zeroDollarPurchase(零元购),不要这样，可能后来会让接收你代码的人一头雾水
注：零元购一般用来嘲讽美国一些人在暴乱的时候组团打劫商店；
8、类名和方法名
类名应该是一个名词，方法名应该是一个动词
9、使用所涉及领域的专有名词
我们开发的软件涉及各个领域，有些领域的一些名词并不是简单的逐字翻译，他们有他们的专有名称，比如说你做的是一个音乐相关的软件，里面有一个名称，八分音符
外文名Eight note,那 你就不应该定义成Eight music symbol,专有名词的命名应当仔细确认，而不能想当然的命名。
10、不要用近义词
vehicle，和car都有表示车的意思，date和time都有表示时间的意思，organization和department都有表示组织部门的意思，千万不要在写代码命名的时候，一会儿用这个单词命名，一会儿又用另一个单词命名，如果一个函数中同时出现了car和vehicle，希望接手你代码的老哥不会骂你
总结
大概就总结这10条，我觉得比较有用的，比较贴合于实际生产的，应该是1，2，3，4，6，7，10
好了，我总结完了，之后再总结一下关于函数代码规范
- 点赞
- 收藏
- 关注作者
评论（0）