intdaysSinceCreation
Handler>
handlerList
privateMap<
TypeEnum,Handler>
handlerMap=newConcurrentHashMap<
>
()
@PostConstructprivatevoidinit(){if(
CollectionUtils.isEmpty(handlerList)){for(Handlerhandler:handlerList){handlerMap.put(handler.getType(),handler)
}}publicResult<
Map<
String,Object>
>
query(Longid,TypeEnumtypeEnum){Handlerhandler=handlerMap.get(typeEnum)
if(null==handler){returnResult.returnFailed(ErrorCode.CAN_NOT_HANDLE)
}returnhandler.query(id)
}}如果空行被移除，可读性将大大降低。publicclassDemo{@ResourceprivateList<
Handler>
handlerList
privateMap<
TypeEnum,Handler>
handlerMap=newConcurrentHashMap<
>
()
@PostConstructprivatevoidinit(){if(
CollectionUtils.isEmpty(handlerList)){for(Handlerhandler:handlerList){handlerMap.put(handler.getType(),handler)
}}publicResult<
Map<
String,Object>
>
query(Longid,TypeEnumtypeEnum){Handlerhandler=handlerMap.get(typeEnum)
if(null==handler){returnResult.returnFailed(ErrorCode.CAN_NOT_HANDLE)
}returnhandler.query(id)
}}类静态变量和实体变量应定义在类的顶部。类内方法的定义顺序是：公共方法或保护方法>
私有方法>
getter/setter方法。水平格式有适当的缩进和空间。团队统一通常，同一个团队的风格应该尽可能保持一致。Java开发规范非常详细。类与函数?
类和函数应该很短类和函数不应过长（集团要求函数长度不得超过80线），过长函数可读性必须较差，通常包含大量重复代码。函数只做一件事(同级)同一函数的每个执行语句都应该是统一层次的抽象。例如，我们经常写一个函数给DTO赋值，然后调用接口，然后返回结果。此函数应包括三个步骤：DTO赋值，调用接口，处理结果。如果函数还包含DTO赋值的具体操作表明，该函数的执行语句在同一层次上并不抽象。参数越少越好参数越多，调用时就越麻烦。尽量保持参数足够少，最好不要。注释?
不要注释坏代码，重建他注释不能美化糟糕的代码。在试图使用注释之前，首先考虑是否可以通过调整结构、命名和其他操作来消除注释的必要性，这通常是多余的。良好的注释提供信息、表达意图、解释和警告我们经常遇到这样的情况：注释写的代码执行逻辑不符合实际代码的逻辑。大多数时候，注释没有跟进，因为代码已经改变了。因此，注释最好提供一些代码没有的额外信息，以显示其设计意图，而不是如何实现。删除注释代码git当版本控制帮助我们记录代码变更的历史时，没有必要继续保留过时的代码，注释的代码也会干扰阅读。错误处理?
else或使用switch过多的if…
else或者switch，应考虑用多态替换。有些人甚至认为代码中不应该存在，除了个别情况。if…
else。总结本文首先总结了我认为好代码的必要条件：清洁，然后具体分析了清洁代码的特点，并分析了好代码的负面条件：什么样的代码不是好代码。只是我的一些观点，我希望能帮助你未来的编程。我认为仅仅编写可操作代码是远远不够的。我们应该始终注意代码的清洁度，留下一些漂亮的代码。我们希望所有的代码都能保留和运行102！添加一些实际的例子来解释好的和坏的代码；分享如何编写整洁的代码——一些你认为有用的编程技巧
