Coding，命名是个技术活
来吧
日常编码少不了的事情就是给代码命名，代码中命名的重要性在项目前期不会有太大感受，因为是边做边命名，代码天天见，自然会加深记忆。但到了后期上线后半年一年后，再回过头看的时候，我擦，这个变量是啥意思？这个方法不对呀，不是更新用户状态的吗？ 接下来就是各种吐槽，谁写的代码，这么烂，翻一下提交日志，哦？我写的，赶紧悄悄的改过来。
经常性我们吐槽别人的代码烂，那么你是如何定义你认为的烂代码，它们烂在哪里 ?
代码究竟烂在哪里
这个问题说的具体点，可能经常我们在没理清业务逻辑的情况下去直接看别人的代码，相当于通过代码反推业务逻辑，别人的命名、编程思维跟自己的习惯不一致，需要时间去消化理解他的逻辑和习惯，然后加上代码排版乱七八糟，一堆 if else，还掺杂着各种奇怪的命名，魔鬼数字，OMG，简直不要太爽。以上综合起来，大概就是大家眼中认为的烂代码吧。
简要总结下：
- 自身原因，业务并未完全理解清楚，直接上手看代码
这里是建议先搞懂业务逻辑和相关的实体或数据库表，最好是自己简要画出流程图或时序图辅助理解代码，展开说的话比较多，后面有机会单独写一篇吧
- 代码风格不规范
体现在各种接口、方法、变量的命名不规范，代码格式排版混乱，过长方法，无注释或不详细等，注释这块最坑的不是没有注释，而是错误的注释。自己脑补下画面
- 代码逻辑混乱
体现在代码逻辑不清楚、冗余代码、废弃方法、深层的嵌套等，怎么优化，也值得单独写几篇
可以看到命名在里面占有一席之地，那么如何做好代码中的命名，且往下看。
好的命名，看这里
先给出结论，一个好的命名最最最关键的一点，见名知意，见名知意，见名知意，重要的内容重复三遍，并加个底色。
不要怕长
我工作中碰到不少人有个命名习惯，我称为半命名方式，看个例子，定义一个业务需求的实体类，正常见名知意的命名是这样的BusinessRequirement，但是，他们觉得这样太长，他们会这样
BusRequi、（各省一半）
BusinessReq（后面省一半）
BusinessXq（一半英文、一半拼音，洋不洋气）
这样的命名完全不具有可读性，还容易产生歧义。所以，不要怕长，能让人和有道词典读懂是前提。
看个springboot中的命名
SpringApplicationJsonEnvironmentPostProcessor
长吗？但肯定能读懂对吧。
但是有一类是可以简化的，就是行业内大家公认的术语简称，比如你想整个ip工具类，那么你可以这样命名IpUtil，就没必要整成这样InternetProtocolUtil，因为Ip这个词在业内大家都懂，就可以简写。
准确
准确就是命名要符合当下的业务场景，比如我老早之前做的考试类项目中有个题目实体，同事采用的命名是Problem，显然放这里是不合适的，最后纠正为Question。要做到准确，还是比较考验英文功底的。
具体
具体就是能正确表达变量或类所指向的代码含义，例如我们定义了一个代表软件版本号的数组，可能会这样定义
int[] array = new int[] {1,2,3,4,5};
数组倒是能看懂，但是单看这一行代码并不能搞清楚干什么用，放在具体的代码逻辑里结合上下文代码，倒也能推导出来数组中定义的具体是什么，但是增加的阅读代码的难度，好一点的当然是下面这样
int[] versionNumberArray = new int[] {1,2,3,4,5};
说清楚具体含义，表示的是什么数组，而不是只抽象的表达个数组的概念。
额外补充一点
我见过一个项目从代码到数据库整体命名都是拼音简写形式，说实话拼音简写对业务不熟悉人来说很难识别，而且时间一长完全是懵逼的，完全得靠猜。
拿上面的业务需求来说拼音整出来Ywxq，拼音组合可以有很多种解读。项目得以持续维护的关键是他们有详细的字典说明文档，实际上就是上篇文章说的公司或团队有一套自己的标准就行。
但是可想而知仍然很痛苦，除非是个别领域内的专业词汇，英文很难表达，可以尝试拼音解决，其他情况还是尽量用英文命名。
总结
好的命名就是做到见名知意，具体遵循以下几点：
1、不要怕长，专业术语行业内有简称，可用简称
2、用词准确
3、表达具体
4、尽量使用英文
5、上面没提到的一点，公司有规范，优先符合公司规范
未入行之前，很多人总是好奇，英文基础对编码到底有没有影响，到底有多大，这里就可以看到，是有影响的，起码命名的时候有障碍，需要借助有道词典或 code if 这样的工具。
而且越往后英语的重要性就愈加明显，比如你可以直接读一手英文资料、文献等。
最后
写完了老感觉烂代码这个词用的很不好，奈何词穷，先这么着吧。
