代码的坏味道

代码的坏味道体现在：

1.注释太多或者太少

整个代码都是很多的注释，整个屏幕没几行是代码的，能维护你代码的人不需要看过多的注释，只需要在关键处标明要体现的目的即可。

有些业务实现起来过于复杂在标明想要表达的意思，且意思需要简短清晰最好可一句话表达出。

2.代码风格不统一

这个一般出现在新人的代码中，比如下划线命名和驼峰命名法交叉使用，看起来就让人厌恶，代码风格整体必须保持统一，整体看起来不那么乱。

3.函数命名

看一段代码，首先看到的是代码的函数名，好的代码，一看函数名就知道函数的作用，烂的代码，函数名字模棱两可，让人只能去读函数的每一行代码才能读懂。

bool check(int gid);       // 烂的函数名
bool isAvaliable(int gid); //好的函数名

4.变量命名

初学者经常容易用t1,t2,t3等以字母加数字组合的方式来命名。变量命宁愿长点也不要太短。
比如要保存项目的物品列表

List<int> goods; 
List<int> projectGoods

i，j，k一般仅用于for循环中的下标。推荐换为具体的下表定义单词。

5.代码一行字符太多

有的函数声明就好长的一行，要看完还得需要移动光标到最后，继续往后翻，这种看了就不想看，一般不要超过80字符，有些不可避免的过长，换行然后第二行插两个tab对齐。

6.函数体函数太长

一个函数体代表了一个模块的封装，如果函数的实现太长，有的甚至一屏幕都看不完，这时候你应该考虑你的模块划分的有问题了，一般来说函数体平均不要超过50行，对于模块进行正确的划分。完全能够减少函数的行数，使得函数实现更清晰明了。

7.重复的代码

在实现功能的时候，完全只考虑怎么实现逻辑，完全没去想结构的调整，重复的逻辑出现了好几次，代码块看起来臃肿不堪，需要很大力气才能读懂。
面向对象的继承，多态，封装这些的出现都是为了解决代码复用的问题，对于重复的逻辑完全可以将重复的功能提炼出来，封装成一个函数，再去调用。

8.错误的设计

本来可以有的更简洁的实现，被实现的过于繁琐，让人看起来啰里啰嗦，打个简单的比方，需要保存一个列表，列表里每个元素只能唯一，如果被设计用List去实现，手动去重，如果一开始用set来存储，代码就会简洁很多。

9.缺乏一定的抽象能力

主要体现在一个最初的一个简单需求，后来提了更多的需求，到最后一个功能有了好多的变种实现，功能代码很难复用，比如对于一个初期的推荐，最开始需要保存的数据只是物品信息表以及一些操作一个类ReposManger就够了，后期可能需要用户的浏览记录，心愿单，用户画像等，该类操作越来越多，需要管理的数据越来越庞大，架构都不敢随便动。这个主要体现在项目组里开发效率比较高的人，大量的业务开发工作导致没做过多的思考，要体会到这个坏味道需要一定的经验。

要消除这些代码的坏味道，只有通过多写，多思考，多看好的代码！