bring it on
Daily coding ultimately do is give the code name, code named the importance of early in the project will not have much experience, because by doing name, code, see every day, it will naturally enhance memory. But by the latter part of the line after half a year later, and then look back, I rub, this variable What do you mean? This method is not right, do not update the user status? Then there is all kinds of Tucao, who wrote the code, so bad, submitted a brief look at the log, oh? I wrote, quietly and quickly change overnight.
We regularly Tucao code for rotten people, then how do you define bad you think the code, where they are rotten?
The code exactly where rot
This question is of particular point, we may often did not clarify the situation in the business logic of going direct look at the code, the code is equivalent to the thrust reverser by business logic, someone else's name, thinking with their programming habits inconsistent, need time to digest understand his logic and habits , and then add the code layout mess, a pile if else, also mixed with a variety of strange name, a magic number, OMG, just do not be too cool. Above together, you probably think of the bad in the eyes of the code.
Brief summary follows:
- Their own reasons, did not fully understand the business a clear, direct look at the code to get started
Here is recommended to get to know the business logic and related entities or database table, it is best to draw their own brief flow chart or timing chart aid the understanding of the code, expand to say more, later to have time alone to write one now
- Non-standard coding style
Reflected in a variety of interfaces, methods, non-standard variable naming, code formatting typesetting confusion, long way without comment or details, etc., most comments this pit is not without comment, but erroneous comments. Own brain to make up the picture
- Code logic confusion
Logic code embodied unclear, redundant code, discarding method, deep nesting, how to optimize, worth several separate write
We can see a place name in it, then how do the code name, and look down.
Good name, see here
First given conclusion, a good name by far the most crucial point, see the name to know Italy, to see to know the name of Italy, to see to know the name of Italy , important content is repeated three times, and add a background color.
不要怕长
我工作中碰到不少人有个命名习惯，我称为半命名方式，看个例子，定义一个业务需求的实体类，正常见名知意的命名是这样的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 这样的工具。
而且越往后英语的重要性就愈加明显，比如你可以直接读一手英文资料、文献等。
最后
写完了老感觉烂代码这个词用的很不好，奈何词穷，先这么着吧。