现在 IDE 的代码提示已经很完善了,为啥大家都不关注警告的?
前前后后也待过好几家大大小小的公司了,没见过一个人写的代码是 0 Warning 0 Error
的。
打开一个类全是黄黄的不难受的吗?
强迫症已经要死了……
101
liyhu 2022-08-19 09:42:01 +08:00
又不是不能跑(狗头
|
103
pkoukk 2022-08-19 09:59:20 +08:00
所以在 ci 加了 lint 规则,自己本地随便写,提交的时候都得改清楚
|
104
ZMGFX56s 2022-08-19 10:01:46 +08:00
一个两个可能随手就改了,几百几千个改什么,毁灭吧
|
105
huoshanhui 2022-08-19 10:13:42 +08:00
看心情
|
106
jqknono 2022-08-19 10:20:11 +08:00
因为技术能力不够
|
108
zhttp 2022-08-19 10:29:57 +08:00
我自己写的会尽量保证 0 warning ,接手其他人的能跑就绝对不会改。
|
109
LeegoYih 2022-08-19 10:33:41 +08:00 1
不可能存在 0 warnings 的代码,比如:"Return value of the method is never used", "Parameter is never used" 这种是无法避免的,有究极代码洁癖的 antirez 写的 Redis 源码里也有一堆 warnings ,但这不代表就是代码质量有问题,纯纯的 IDE 无法理解
|
110
lcj2class 2022-08-19 10:40:33 +08:00
1. 增加 lint 检查,放到流水线里面,不过不给合并
2. 不是每个人都用 ide 的,Vim/Emacs 之类的用户相对虽然少,但还是有一定量的,所以还是要把编码规范放到 CI 的 lint 里面最靠谱 3. 没有 CI 忽略上面两点 :-)逃 |
111
nothingistrue 2022-08-19 11:05:07 +08:00
第一,设置成警告而非错误的原因,就是因为警告不是必须解决的,连警告都不允许是“水至清则无鱼”的行为。
第二,警告可以随时清理,也可以定期清理,但无论是哪种清理方式,都要是软件开发过程当中,而不是加班当中。 简单来说,就是这种情况,先找 QA ,别先找编码的人。 |
112
Diod 2022-08-19 11:09:50 +08:00
其他语言不清楚,原生的 IDEA 在 Java 代码里报黄 90%都是可以一个快捷键解决的事情
|
113
ClosureEleven 2022-08-19 11:33:46 +08:00
借楼问问 Xcode 的 "Update to recommended settings. This will update the minimum deployment target of Target `xx` to 12.0" warning 怎么去掉,我会尽量保证 0warning 可是这个就是没法不提示,目前又没法放弃低端机用户
|
114
Leviathann 2022-08-19 11:35:31 +08:00
@Diod 有时候有坑的,比如判断 一个 if (Boolean == true) 它会不考虑可能为 null 的情况直接标黄让你换成 if (Boolean)
|
116
Diod 2022-08-19 12:26:25 +08:00
@Leviathann 不都是 Boolean.TRUE.equals(obj)吗
|
117
bk201 2022-08-19 12:58:25 +08:00
一个 ide 的提示又不一定对,有必要纠结吗
|
118
Cyshall 2022-08-19 13:02:02 +08:00
op 平常写代码都是 0 Warning ?
|
119
stoluoyu 2022-08-19 13:02:08 +08:00
如果不是全团队通用配置的话,很可能在你这的 warning 在他那不 warning
|
121
iamqk 2022-08-19 13:29:49 +08:00
我们这个项目 1623 的警告
|
122
icyalala 2022-08-19 13:35:21 +08:00
对各种 warning 我反正很不爽,所以在公司我有时间肯定会去改。
但是现在剩下的大部分 warning 都是提示 deprecated 声明或用法,改得麻烦还要过测试。还有的是其他团队代码带来的警告直接没法改,时间长了也只能放着了。 至于我自己的开源项目,CI 里什么 -Werror -Wall -Wextra 之类的全都加上去,希望别人用得时候至少不会在 warning 上糟心。 |
123
fyxtc 2022-08-19 14:59:12 +08:00
有意义,但意义不大,矫枉过正,改警告的时间去写新功能或者摸鱼任何一个都比这个有价值
|
124
asmoker 2022-08-19 15:49:19 +08:00
说不定人家的 IDE 已经忽略了这些 ⚠️ 看不到呢 [/doge]
|
125
nicegp 2022-08-19 17:01:39 +08:00
开发第一原则:能跑就不动
|
126
kkbblzq 2022-08-19 17:15:46 +08:00
我自己的代码会尽量处理,别人的管不着,当然没办法一定清零,部分 warning 只是建议项,有的改起来成本挺高的。
|
127
loryyang 2022-08-19 17:17:20 +08:00
warning 就是 warning ,如果觉得没问题,就没必要处理。
我在内部要求是:要看 warning ,但不要求全部处理。但是明显有问题的 warning 没发现,事后会被打板子 |
130
FrankHB 2022-08-19 18:49:33 +08:00
@icyalala 极不建议默认 -Werror ,即便是自己控制的项目。要是刚好有用户升级了新版编译器多检查出了没在你这里报的 warning 然后变成 error 就糟心了。要是源码发行版用这种默认策略很可能整个系统动不动升级失败。
|
131
349865361 2022-08-19 19:15:29 +08:00
type Template struct {
templates *template.Template } func (t *Template) Render(w io.Writer, name string, data interface{}, c echo.Context) error { return t.templates.ExecuteTemplate(w, name, data) } 报黄色 c 参数没有使用 但是这是通过其他库的接口方法 c 参数不传会报错 传了不用会警告变黄 我也木法 |
132
x86 2022-08-19 19:27:14 +08:00
不出点错我怎么摸鱼修改
|
133
cosmosz 2022-08-19 19:35:19 +08:00
CI 里加上没加 lint 或者 format 的要求, 能过 CI 就算过。
或者 IDE 没 config 好, 没读 linter 的 configuration , 用了初设。 |
134
fstar 2022-08-19 19:49:31 +08:00
逆风而行的靓丽风景线
|
135
akira 2022-08-19 19:53:48 +08:00
项目明天上线,目前还有 32 个 warning ,你是改还是不改
|
136
aigonna 2022-08-19 22:43:03 +08:00 via iPhone
反正能跑就行了
|
137
icyalala 2022-08-20 00:55:32 +08:00
@FrankHB 正常 Release 当然不会加,严格的检查只在开发阶段 CI 里用参数启用,至少能给那些瞎提 PR 的人看
|
138
mingl0280 2022-08-20 10:19:26 +08:00
我们这的话,给客户发的示例代码一定是 0 err 0 warn 的,自己用的软件大部分是 0 err 0 warn 的,少数软件有一些以前的旧硬件的操作必然有 warning 也没办法……
|
139
mingl0280 2022-08-20 10:20:46 +08:00
不过这个是编译器的 0 err 0 warn ,不是 lint 的,lint 不要求 0 warning ( C++项目要按 Lint 做,能把你坑死,特指某些傻逼的不让用全局变量 /不让用裸指针的 Lint 规则。)
|
140
Aixtuz 2022-08-20 13:15:30 +08:00
1. 有些我不擅长的,只是拿来用用,不敢动;
2. 有些就算擅长的,又不是我写的,懒得管; 3. 有些确实我写的,又不是不能用,催的紧; |
141
FrankHB 2022-08-21 07:32:48 +08:00
@icyalala CI 确实是没问题因为环境可预测,不过瞎 pr 有紧迫到用得着这样对付么……
(虽说一般通过的用户也没法指望想太多……github.com/kifuan/helang/issues/271 。) |
142
by73 2022-08-21 14:44:59 +08:00
我个人而言,有余力就会去管一下,没有就算了。很多时候 warning 确实很 verbose ,像 c/cpp 这种语言,对有无符号的很多操作都会产生一个 warning ,但是毕竟人家真的是 ub ,只是大家都普适性地认为架构就是“二进制补码”,给个 warning 我觉得很合理。
其实也就是,要是你知道这些 warning 真正会引发什么问题,然后根据后果来自行判断到底要不要 fix 就好了;毕竟真实的应用挺复杂的,只要你知道自己在干什么,有什么后果,需不需要管,我觉得就 ok 了。 而且有时候我也能在 warning 中学会很多 best practice ,例如 cpp 构造函数里,把右值放在 member-initializers 而非参数中,能有更强的“适应性”,之类的。 |
143
dengshen 2022-08-21 17:20:29 +08:00 via iPhone
@ikaros 自己负责的项目还有点追求。合作的项目如果对方写的稀烂还不用 lint 和 prettier 工具的话确实就是堆 shit
|
144
z1829909 2022-08-21 20:36:20 +08:00
把警告级别调高就可以解决了
|
146
NewYear 2022-08-22 15:09:20 +08:00
小项目,warning 不影响使用,懒得弄,弄起来也对原来的代码要做优化,麻烦有风险。
|
147
DivineRapierH 2022-09-03 21:42:02 +08:00
我觉得 warning 有两种,一种是代码确实有小问题的,一种是 IDE 没理解代码它以为有问题实则没问题的。前者最好改,后者当然可以无视。
我自己不会追求 0 warning (不过确实会追求 0 typo 哈哈),但是我会把所有的 warning 都过一遍,能改则改。大多数 IDE 报的 warning 改一改也就是举手之劳,我是很乐意改的。 |