音乐分享网站开发,什么是wordpress响应式主题,合肥网站营销,网页设计实验报告分析与体会阿里妹导读#xff1a;你有没有遇到过这种情况#xff1a;过几周或者几个月之后#xff0c;再看到自己写的代码#xff0c;感觉一团糟#xff0c;不禁怀疑人生#xff1f;我们每天都与代码打交道#xff0c;但当被问道什么是好的代码时#xff0c;很多人可能会先愣一下… 阿里妹导读你有没有遇到过这种情况过几周或者几个月之后再看到自己写的代码感觉一团糟不禁怀疑人生我们每天都与代码打交道但当被问道什么是好的代码时很多人可能会先愣一下然后给出的回答要么比较空泛要么比较散没办法简单明了地概括出来。今天我们就来说什么是好的代码 一句话概括 衡量代码质量的唯一有效标准WTF/min —— Robert C. Martin Bob大叔对于好代码的理解非常有趣对我也有很大的启发。我们编写的代码除了用于机器执行产生我们预期的效果以外更多的时候是给人读的这个读代码的可能是后来的维护人员更多时候是一段时间后的作者本人。 我敢打赌每个人都遇到过这样的情况过几周或者几个月之后再看到自己写的代码感觉一团糟不禁怀疑人生。 我们自己写的代码一段时间后自己看尚且如此更别提拿给别人看了。 任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码才是优秀的程序员。 —— Martin Fowler 所以谈到好代码首先跳入自己脑子里的一个词就是整洁。好的代码一定是整洁的给阅读的人一种如沐春风赏心悦目的感觉。 整洁的代码如同优美的散文。 —— Grady Booch 好代码的特性 很难给好的代码下一个定义相信很多人跟我一样不会认为整洁的代码就一定是好代码但好代码一定是整洁的整洁是好代码的必要条件。整洁的代码一定是高内聚低耦合的也一定是可读性强、易维护的。 高内聚低耦合 高内聚低耦合几乎是每个程序员员都会挂在嘴边的但这个词太过于宽泛太过于正确所以聪明的编程人员们提出了若干面向对象设计原则来衡量代码的优劣 开闭原则OCP (The Open-Close Principle)单一职责原则SRP (Single Responsibility Principle)依赖倒置原则DIP (Dependence Inversion Principle)最少知识原则LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)里氏替换原则LSP (Liskov Substitution Principle)接口隔离原则ISP (Interface Segregation Principle)组合/聚合复用原则CARP (Composite/Aggregate Reuse Principle) 这些原则想必大家都很熟悉了是我们编写代码时的指导方针按照这些原则开发的代码具有高内聚低耦合的特性。换句话说我们可以用这些原则来衡量代码的优劣。 但这些原则并不是死板的教条我们也经常会因为其他的权衡例如可读性、复杂度等违背或者放弃一些原则。比如子类拥有特性的方法时我们很可能打破里氏替换原则。再比如单一职责原则跟接口隔离原则有时候是冲突的我们通常会舍弃接口隔离原则保持单一职责。只要打破原则的理由足够充分也并不见得是坏的代码。 可读性 代码只要具有了高内聚和低耦合就足够好了吗并不见得我认为代码还必须是易读的。好的代码无论是风格、结构还是设计上都应该是可读性很强的。可以从以下几个方面考虑整洁代码提高可读性。 | 命名 大到项目名、包名、类名小到方法名、变量名、参数名甚至是一个临时变量的名称其命名都是很严肃的事好的名字需要斟酌。名副其实好的名称一定是名副其实的不需要注释解释即可明白其含义的。 /** * 创建后的天数 **/ int d; int daysSinceCreation; 后者比前者的命名要好很多阅读者一下子就明白了变量的意思。 容易区分我们很容易就会写下非常相近的方法名仅从名称无法区分两者到底有啥区别eg. getAccount()与getAccountInfo()这样在调用时也很难抉择要用哪个需要去看实现的代码才能确定。 可读的名称一定是可读的易读的最好不要用自创的缩写或者中英文混写。 足够短名称当然不是越长越好应该在足够表达其含义的情况下越短越好。 | 格式 良好的代码格式也是提高可读性非常重要的一环分为垂直格式和水平格式。 垂直格式通常一行只写一个表达式或者子句。一组代码代表一个完整的思路不同组的代码中间用空行间隔。 public class Demo { Resource private ListHandler handlerList; private MapTypeEnum, Handler handlerMap new ConcurrentHashMap();PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) {handlerMap.put(handler.getType(), handler);}}}public ResultMapString, Object query(Long id, TypeEnum typeEnum) {Handler handler handlerMap.get(typeEnum); if (null handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE);} return handler.query(id);} } 如果去掉了空行可读性大大降低 public class Demo { Resource private ListHandler handlerList; private MapTypeEnum, Handler handlerMap new ConcurrentHashMap(); PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) {handlerMap.put(handler.getType(), handler); } } } public ResultMapString, Object query(Long id, TypeEnum typeEnum) {Handler handler handlerMap.get(typeEnum); if (null handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE);} return handler.query(id); } } 类静态变量、实体变量应定义在类的顶部。类内方法定义顺序依次是公有方法或保护方法 私有方法 getter/setter方法。 水平格式要有适当的缩进和空格。 团队统一通常同一个团队的风格尽量保持一致。集团对于Java开发进行了非常详细的规范。 | 类与函数 类和函数应短小更短小类和函数都不应该过长集团要求函数长度最多不能超过80行过长的函数可读性一定差往往也包含了大量重复的代码。 函数只做一件事同一层次的事同一个函数的每条执行语句应该是统一层次的抽象。例如我们经常会写一个函数需要给某个DTO赋值然后再调用接口接着返回结果。那么这个函数应该包含三步DTO赋值调用接口处理结果。如果函数中还包含了DTO赋值的具体操作那么说明此函数的执行语句并不是在同一层次的抽象。 参数越少越好参数越多的函数调用时越麻烦。尽量保持参数数量足够少最好是没有。 | 注释 别给糟糕的代码加注释重构他注释不能美化糟糕的代码。当企图使用注释前先考虑是否可以通过调整结构命名等操作消除写注释的必要往往这样做之后注释就多余了。 好的注释提供信息、表达意图、阐释、警告我们经常遇到这样的情况注释写的代码执行逻辑与实际代码的逻辑并不符合。大多数时候都是因为代码变化了而注释并没有跟进变化。所以注释最好提供一些代码没有的额外信息展示自己的设计意图而不是写具体如何实现。 删除掉注释的代码git等版本控制已经帮我们记录了代码的变更历史没必要继续留着过时的代码注释的代码也会对阅读等造成干扰。 | 错误处理 错误处理很重要但他不能搞乱代码逻辑错误处理应该集中在同一层处理并且错误处理的函数最好不包含其他的业务逻辑代码只需要处理错误信息即可。 抛出异常时提供足够多的环境和说明方便排查问题异常抛出时最好将执行的类名关键数据环境信息等均抛出此时自定义的异常类就派上用场了通过统一的一层处理异常可以方便快速地定位到问题。 特例模型可消除异常控制或者null判断大多数的异常都是来源于NPE有时候这个可以通过Null Object来消除掉。 尽量不要返回null不要传null参数不返回null和不传null也是为了尽量降低NPE的可能性。 如何判断不是好的代码 讨论了好代码的必要条件我们再来看看好代码的否定条件什么不是好的代码。 Kent Beck使用味道来形容重构的时机我认为当代码有坏味道的时候也代表了其并不是好的代码。 代码的坏味道 重复可能是软件中一切邪恶的根源。 —— Robert C.Martin 重复Martin Fowler也认为坏味道中首当其冲的就是重复代码。很多时候当我们消除了重复代码之后发现代码就已经比原来整洁多了。 函数过长、类过大、参数过长过长的函数解释能力、共享能力、选择能力都较差也不易维护。 过大的类代表了类做了很多事情也常常有过多的重复代码。 参数过长不易理解调用时也容易出错。 发散式变化、霰弹式修改、依恋情结如果一个类不是单一职责的则不同的变化可能都需要修改这个类说明存在发散式变化应考虑将不同的变化分离开。 如果某个变化需要修改多个类的方法则说明存在霰弹式修改应考虑将这些需要修改的方法放入同一个类。 如果函数对于某个类的兴趣高于了自己所处的类说明存在依恋情结应考虑将函数转移到他应有的类中。 数据泥团有时候会发现三四个相同的字段在多个类和函数中均出现这时候说明有必要给这一组字段建立一个类将其封装起来。 过多的if...else 或者使用switch过多的if...else或者switch都应该考虑用多态来替换掉。甚至有些人认为除个别情况外代码中就不应该存在if...else。 总结 本文首先一句话概括了我认为的好代码的必要条件整洁接着具体分析了整洁代码的特点又分析了好代码的否定条件什么样的代码不是好的代码。仅是本人的一些见解希望对各位以后的编程有些许的帮助。 我认为仅仅编写出可运行的代码是远远不够的还要时刻注意代码的整洁度留下一些漂亮的代码。 原文链接 本文为云栖社区原创内容未经允许不得转载。