程序员写出这样的代码，能不挨骂吗？
当你换槽填坑时，面对一个新的环境。可以快速熟练，上手实现业务需求是关键。java
可是，哪些因素会影响你快速上手呢？是原有代码写的不够好？仍是注释写的不够好？数据库
昨夜，闲情雅致，瞅了瞅隔壁小王的代码，看完以后真是太上火，气不打一处来。编程
因而，把小王犯的错误拉了个清单，一块儿帮他改进一下，顺便看看这些坏习惯，你是否也有呢？网络
1.
过分相信别人，会给本身挖坑。并发
针对接口输入参数，没有进行严格校验，尤为是要插入数据库库的参数，一路透传到底（数据库层面），数据库就报数据插入异常。框架
对于调用者而言，会一直等待接口响应，而最后拿到数据库错误，会一脸懵 B；对于接口自己而言，会占用数据库链接，损耗资源，若是并发量大的状况，影响可想而知。工具
建议：业务代码研发过程当中，不要相信调用者会按照要求传参数，要作到防护性编程。性能
2.
异常捉都捉啦，就差一哆嗦。学习
2.1. 抓住了异常，却什么都没作！
2.2. 打印异常栈的方式，却显得毫无心义。
估计不少人，都会这么写，可是在生产上，却显得意义不大，因此最好用记录日志的形式输出异常信息。开发工具
建议：业务代码研发过程当中，针对接口中发生的异常，既然进行了 catch，那就必定要好好封装处理，若不作任何处理，私自把异常给吞没了，一旦线上出了问题，殊不知道问题出在了哪里。
3.
小儿科的问题，会大意失荆州。
3.1. 代码这么写，还谈什么用户体验？
例如，用户绑定银行卡场景，判断银行卡是否已经绑定，未绑定则进行绑定。
循环遍历用户绑定的银行卡列表，而后比较传入的卡号（cardNo）是否已经绑定过，当传入的卡号与绑定的卡号一致时，修改 hasCard 为 true，并无跳出循环，继续下一次比较判断。
那么，若是相似这种代码，发生在数据量比较大的场景下，势必会下降性能，过分浪费资源，用户确定会骂街。
建议修改方式（仁者见仁智者见智）：
3.2. 数据挨个去处理，怎么还出现了漏网之鱼？
例如，三方数据对帐时，判断三方传过来的数据在本地状态是否正常匹配，把没匹配的数据进行注销处理。
代码这么写，一旦条件匹配，进行删除某条记录后，list 的大小发生了变化，而 i 的值也在变化，就会致使在遍历的时候，漏掉某些记录。
好比，当删除第 1 个元素后，继续根据索引访问第 2 个元素时，由于删除的关系，后面的元素都往前移动了一位，因此实际访问的是第 3 个元素。
建议采用 Iterator 删除，或者集合倒序遍历删除。
3.3. & 与 && 的使用不当，终酿错。
例如，在 Web 项目中，判断输入的邮箱是否为空。
当 email 输入为 null 时，& 使用时，后面的条件会发生空指针异常。
建议修改成:
一样，| 与 || 也有相似的状况，因此在使用时，也要注意此类场景的问题。
3.4. equals 比较，搞很差会出幺蛾子。
当 resMap.get(Global.RETCODE) 为 null 时，会发生空指针异常。
鉴于 Object 的 equals 方法容易抛空指针异常，因此业务研发中，应使用常量或肯定有值的对象来调用 equals。
建议修改成：
3.5. 数学运算，搞很差会倾家荡产。
输出结果：0.010000000000005116，通常遇到须要用到浮点数运算的地方，均可以使用 java.math.BigDecimal。
建议修改成：
注意构造 BigDecimal 的参数为 String，千万别搞错了，这也是新手易犯的问题。
3.6. 奇葩的注释，看到就想骂街。
3.6.1. 项目中的某类的注释。
代码的做者是管理员，敢问，管理员 TM 又是谁？并且源文件有过修改，可是修改描述的是啥？着实让人费解！
3.6.2. 项目中的某方法的注释。
方法参数没有解释；方法返回值没有解释；做者又是属于管理员；修改描述描述的是个啥？
4.
让代码会说话。
4.1. 避免江边卖水。
4.1.1. 业务接口验签代码片断。
红色圈住部分，感受有点江边卖水，画蛇添足。那么，能够去掉 false 判断，建议修改以下：
一样的，代码研发中，true 的判断也同样能够去掉。
4.1.2. 用户登陆代码片断。
最后的 else 有点画蛇添足，能够省略，能够修改成：
4.1.3. 用户是否绑定银行卡片断。
在 return 前的判断，貌似略显多余，能够修改成：
4.2. 减小 Bug，减小圈的复杂度。
(图片来源于网络)
会发现嵌套层数越多，代码越复杂，其圈复杂度也就可能越高。不过，控制嵌套层数，即是下降 Bug 发生几率的一个有效手段。
例如，下面的代码片断，项目中可谓是一抓一大把。
根据场景，能够适当调整以下：
4.3. 统一做战，代码未动，规范先行。
为了让写出的代码可以清晰阅读，前提是团队要进行统一，不能为了我的嗜好，而首创研发秘笈。
敢问，有哪些须要进行统一呢？
统一的开发环境（JDK版本、集成开发工具 IDE、存放目录...）；
统一的开发框架，更多精力集中到业务开发上；
统一的开发模板，开发工具要进行统一 Scheme；
统一的开发规约，命名、注释、代码结构等约束；
统一的 DB 规约，具有一个良好的标准。
统一的 ... ...
5.
代码评审的过程，会让人啼笑皆非！
铁打的营盘流水的码农，你的代码早晚会被其余同事接手，为了让接手你代码的同事，内心不默默骂你，建议仍是好好对待编码这件事，认真写好每行代码。
写代码是一件快乐的事情，评审代码更是一件有趣的事情，经过评审代码，可以相互学习，并使代码更加健壮，提前发现 Bug，因此每一次都不要错过。
最后，本次分享就到这里，但愿大家可以喜欢。