阿里 Java 代码规范的疑问 - POJO 类时不要设定任何属性默认值

[beryl]

规约 1.4.9 定义 DO/DTO/VO 等 POJO 类时不要设定任何属性默认值

对于定义的一些 DTO 中的数组类型，习惯性设置成一个空数组 new ArrayList ，如果不设置下游多处地方都需要先判空。

所以对于这跳规范一直持有质疑看法，也有人提了 issue 但是回答并不能够说服自己，不知道大家怎么看待 https://github.com/alibaba/p3c/issues/360

另外看了个阿里的开源项目 Nacos 和 Sentinel ，发现也没有遵守该规范： https://github.com/alibaba/nacos/blob/develop/api/src/main/java/com/alibaba/nacos/api/naming/pojo/Cluster.java https://github.com/alibaba/Sentinel/blob/master/sentinel-core/src/main/java/com/alibaba/csp/sentinel/node/DefaultNode.java

[BBCCBB]

这只是个参考. 根据你实际场景来判断用不用. 没必要迷信..

[hidemyself]

不是法律法规，没有必要一定遵守

[Vegetable]

规范就是为了降低沟通成本和犯错的可能性。你能要求所有同事在构造器里为所有属性填充 0 值也行，只要大家都一样就行了，没必要质疑。

[gadfly3173]

这俩例子都是配置类一类的东西。规约里给的场景意思也是用来区分 0 和 null 的。如果你的场景里不应该出现 null ，那设个默认值也很合理，就像 @RequestParam(defaultValue=xxx)这样

[AoEiuV020]

看按规范的意思，如果这个数组字段可能为空，那后面空判断就是了，
如果这个字段不可以为空，那创建的时候就必须给个值，没内容就必须是个空数组[]而不能是 null ，后面不需要 null 空判断，

我就比较喜欢这样的，有没有内容数组都别 null ， 但这需要前后端共同努力，一环掉链子就崩溃所以实际上还是得自己兼容 null ，

[Leviathann]

java 的类型系统太弱鸡
没法让人意识到可 null 不可 null 是两个类型
而空列表和非空列表仍然是同一个类型

[itechnology]

这只是阿里提出的代码规范，并不是一定要按照他的来的，毕竟又不是他说了算

[passerbytiny]

阿里规范只适合阿里。Java 通用开发规范建议用 Google 的，Github 上就有，但是建议手动遵循规范，不要用那个格式化插件。

[lonenol]

这个不让设默认值其实主要是针对 DB 更新的场景，比如为了偷懒，你的 DAO 层的更新是传递一个对象，然后判断不是空就更新，是空就跳过（很多人为了偷懒这么写），然后你更新的时候初始化了一个对象，设置了 id 和你要更新的字段，然后其他字段就都被更新成默认值了。。

当然你也可以避免，这只是一种可能。。相比于前端的约定，这种错误造成的损失更大一些。

[pengtdyd]

大家还记得数据库三范式吗？？？？一味的遵守所谓的规范只会让你陷入到一个思想上黑洞。灵活运用从实际情况出发，解决现实问题，最后形成规范，这个才是最好最合适的规范。

[chendy]

阿里家的规矩是阿里家的，不喜欢不习惯不需要强迫自己，更何况他们自己其实都遵守不好
顺便一说，默认空集合应该用 Collections.emptyXXX() （但是这个集合不能写）

[wolfie]

拿阿里巴巴自己的编程规范扫了一下阿里巴巴的所有开源项目
/t/543954

[Oktfolio]

我就遇到过默认值的坑

[angryfish]

看一下就好 ，取其精华，去其糟粕。

[0608516518]

有些编码规范是为了降低风险，或者由于某些公司内部原因（历史原因，或者只有阿里才会遇到的性能问题）而提出来的。我印象深刻的是 boolean 变量不要叫 isGood ，而要叫 good ，否则某些框架序列化成 json ，会变成 is_is_good 。但请问现代 jackson 会吗？不会。

看规范，更重要的是看它为什么要这样写。

[Chinsung]

这种遵守自己和前端的约定就完事了，这东西又不是圣经，团队管理的事情，就算你一个人遵守了所谓《阿里巴巴规范》，你也不能保证其他人都遵守了，这种事情的前提还是先完成任务吧。
更何况上面有位大佬也扫过阿里开源源码，他们自己遵守的也一般。