返回知识库

工程与栈 · 工程协作

代码检查Linter

代码检查按规则静态扫源码,标出行号和改法,不需要先跑程序;error 可以挡住合并,但替代不了测试。

先认出这一行代码,再看红线在不在

下面就是花店页的一行判断:默认已经改成 ===。留下 ==,划红和挡住合并也写在同一行上。

花店页 · app.tsx干净 · 可以合并

if (user === null)

没有诊断。这一行可以合并。

干净 · 可以合并干净结果长在编辑器里。

原因:lint 不运行代码,只按规则扫。下一步:点「留下 ==」,看红线和门禁会不会写在这一行上。

知识点:检查发生在运行之前

编辑器上的红线和行号已经演示了差异,这里只命名四条。

  • linter 不跑程序,只按规则扫源码。
  • 诊断要带行号和怎么改,不能只说「有问题」。
  • error 能挡住 CI;warn 提醒但不一定禁合。
  • 离开后要盯:规则写进仓库,禁止无理由大面积关掉。

什么时候用、怎么用

团队要统一写法、想在运行前拦住低级错时用 lint;它替代不了测试。

  • 信号:== 和 === 混用、未使用变量、PR 里反复改格式。
  • 适用:风格、明显笔误、能自动修的规则。
  • 不适用:对错依赖运行结果——那是测试的事。
  • 最短路径:保存时扫 → 看行号 → 能自动修就修 → error 必须清掉再合并。

正反例:同一行用户判断

目标都是判断 user 空不空,只改比较符。

正例写成 ===

没有红线,可以合并。结果长在编辑器里。

反例留下 == 还合并

第 12 行划红,门禁不绿。失败写在代码上。

快速自测

保存后第 12 行划红「用 === 代替 ==」,这说明什么?

继续查证

术语的技术定义和行为以这些一手或权威资料为准。

下一步学

和本知识点经常一起出现的概念。