聊聊那些奇葩的代码规范 —— 所有 IntelliJ 的警告必须要处理
因为有些要求感觉实是太过奇葩,收集下来娱乐下大家。
代码规范要求
如果代码在 IntelliJ 出现了警告提示,所有的警告必须要在提交之前处理完成,否则 PR 合并全部被拒绝,不管有些警告是不是有点奇葩,
同时,如果你在提交代码的时候被这个奇葩架构师发现有警告没有处理的话,他会非常严厉的指出这个奇葩的问题,并且多次发现或者忽略这个问题的时候,他就会把这个问题上升到原则高度,说你根本不会编程,不会写代码,然后告诉全公司,这哥们压根不懂代码。
为什么要这样要求的解释:警告是程序错误的一种,如果你对警告不处理就是视而不见,是能力问题也是态度问题。
我们提出过异议:从 Apache 克隆一些代码,你会看到上面有成千上万条警告,这难道证明这些 Apache
的提交不是优秀代码,难道他们还不如我们吗?
得到的回复是:因为 Apache Commons 的包的警告被很多人证明这不是问题,所以不需要去处理。不同项目要求不一样,我们不能要求 Apache。
来看看 Apache 的这个类,估计他得哭晕在厕所里了。
其实并不反对对警告有些关注,但是这样吹毛求疵的要求所有警告被处理,就有点过分了。
比如说有些类,可以不用定义为 Public,奇葩架构师也要求进行修改,然后下次用得时候如果需要用这个类的方法还得再改回来。
还有呀,他对警告级别的认定不经过所有人的同意,也不经过任何其他人的同意。
突然那天脑袋被驴踢了,就改了 IntelliJ 警告基本设置,结果就出现程序员本地没有警告,在他那里全是警告,然后说你为什么不修改警告?
一言难尽的折腾,你们怎么看?
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 【杭电多校比赛记录】2025“钉耙编程”中国大学生算法设计春季联赛(1)
2022-06-07 Apache.commons.lang3 的 isNumber 将会在 lang 4 的时候丢弃
2022-06-07 Junit 测试中如何对异常进行断言
2022-06-07 AssertJ 的异常(Exception )断言
2019-06-07 HyperSQL 链接参数中文件的路径
2019-06-07 Maven 在 pom.xml 文件中配置 repositories 仓库
2019-06-07 Flyway Validate failed: Migration checksum mismatch for migration version 1.0.0.01 错误
2018-06-07 Confluence 6 在数据源连接中启用校验查询