请教一下，大公司（BAT 级别的）对 lombok 有规定吗？

[wdwwtzy]

是推荐用还是禁止用啊？

[wiix]

@lxk11153 org.apache.commons.lang3.builder.ToStringBuilder
commons lang 里的一个工具。

[lxk11153]

@wiix #81 你说父类，我以为要继承它。[doge]

[jorneyr]

我曾经有一个表单，使用的 Bean 已经有 50 多个属性了 (都是 getter, setter 访问，有的 setter 还有手写的逻辑)，由于是遗留项目，只好在原来的 Bean 上增加新的属性，有一次增加了一个属性，忘了写 getter setter，导致怎么测试都不对，最后搞了半天才发现忘记 getter setter 了，那以后新项目都推荐使用 Lombok 了，代码简洁，尽量避免低级错误吧。

使用 Lombok 的缺点无非就是 IDE 里需要安装插件，几分钟的事而已，但也不能滥用，我们只允许使用 @Getter @Setter 注解，@ToString 尽量不用，测试输出时使用 Utils.toJson(xxx) 好了。

[aguesuka]

就我个人而言，如果是为了省几行代码，直接上 java14 或者 kotlin 更好

[blless]

🌚虽然我不是 java 仔，但是我似乎已经看见一条 java 的分裂路线了

[ganning]

使用 lombok 也没有禁止生成 /使用 get/set 。。。。就看个人风格还是团队风格了。

[iweisi]

一个 get set 都吵，这么在乎细节，看来项目质量肯定很棒哦

[MakHoCheung]

我是菜鸡，我用 public

[cheng6563]

其实挺方案这种直接改语法的插件的，但无奈 getter setter 太臭了

[iyangyuan]

多一事不如少一事，不用不会出问题，用了可能会出问题

[andj4cn]

我之前也不用，后来团队有人开始用了，就跟着用。其实 @Getter @Setter 这些注解确实省不少事，让纯 Java 项目实体类代码少一点。这个主要看内部项目推进用了没，用了就用，要达成共识。

[hecz]

@Reficul 你说的定规则的观点我同意，这种东西要么就全用，要么就全都不用，定完规则按照规则走就行。简单当然比复杂好，但是还是得看场景的，比如之前的 beanUtils 类，试用起来确实方便，但是也会新增一些性能问题

[yuekcc]

曾经在一个项目上用过，代码确实整洁了。但是后面全部改回手写的 getter/setter 了，原因就是这东西不是所有人能接受。而且还得手工安装一个插件。团队小还好，最多就是多安排几次培训。这样想来成本也不低，如果人员流动大的话，就不是一两次培训能解决的了。而且 idea 这种 ide 按个快捷键就能生成 getter 、setter 了，可以解决不少的手写 getter 、setter 场景。

最好解决方案就是上 kotlin 。