查看原文
其他

PyLint 的优点、缺点和危险 | Linux 中国

邀你一起加入 Linux中国 2023-01-03
 
导读:充分利用 PyLint。                                                   
本文字数:3522,阅读时长大约:4分钟

充分利用 PyLint。

敲黑板:PyLint 实际上很好!

“PyLint 可以拯救你的生命”,这是一句夸张的描述,但没有你想象的那么夸张。PyLint 可以让你远离非常难找到的和复杂的缺陷。最差的情况下,它只可以节省测试运行的时间。最好的情况下,它可以帮你避免生产环境中复杂的错误。

优点

我不好意思说这种情况是多么普遍。测试的命名总是那么奇怪:没有人关心这个名称,而且通常也找不到一个自然的名称。例如以下代码:

  1. def test_add_small():
  2.     # Math, am I right?
  3.     assert 1 + 1 == 3
  4.    
  5. def test_add_large():
  6.     assert 5 + 6 == 11
  7.    
  8. def test_add_small():
  9.     assert 1 + 10 == 11

测试生效:

  1. collected 2 items                                                                        
  2. test.py ..
  3. 2 passed

但问题是:如果你覆盖了一个测试的名称,测试框架将愉快地跳过这个测试!

实际上,这些文件可能有数百行,而添加新测试的人可能并不知道所有的名称。除非有人仔细查看测试输出,否则一切看起来都很好。

最糟糕的是,被覆盖测试的添加被覆盖测试造成的破坏,以及连锁反应的问题可能要几天、几月甚至几年才能发现。

PyLint 会找到它

就像一个好朋友一样,PyLint 可以帮助你。

  1. test.py:8:0: E0102: function already defined line 1
  2.      (function-redefined)

缺点

就像 90 年代的情景喜剧一样,你对 PyLint 了解的越多,问题就越多。以下是一个库存建模程序的常规代码:

  1. """Inventory abstractions"""
  2. import attrs
  3. @attrs.define
  4. class Laptop:
  5.     """A laptop"""
  6.     ident: str
  7.     cpu: str

但 PyLint 似乎有自己的观点(可能形成于 90 年代),并且不怕把它们作为事实陈述出来:

  1. $ pylint laptop.py | sed -n '/^laptop/s/[^ ]*: //p'
  2. R0903: Too few public methods (0/2) (too-few-public-methods)

危险

有没有想过在一个数百万人使用的工具中加入自己未证实的观点?PyLint 每月有 1200 万次下载。

“如果太挑剔,人们会取消检查” — 这是 PyLint GitHub 的 6987 号议题,于 2022 年 7 月 3 号提出

对于添加一个可能有许多误报的测试,它的态度是 ... “”。

让它为你工作

PyLint 很好,但你需要小心地与它配合。为了让 PyLint 为你工作,以下是我推荐的三件事:

1、固定版本

固定你使用的 PyLint 版本,避免任何惊喜!

在你的 .toml 文件中定义:

  1. [project.optional-dependencies]
  2. pylint = ["pylint"]

在代码中定义:

  1. from unittest import mock

这与以下代码对应:

  1. # noxfile.py
  2. ...
  3. @nox.session(python=VERSIONS[-1])
  4. def refresh_deps(session):
  5.     """Refresh the requirements-*.txt files"""
  6.     session.install("pip-tools")
  7.     for deps in [..., "pylint"]:
  8.         session.run(
  9.             "pip-compile",
  10.             "--extra",
  11.             deps,
  12.             "pyproject.toml",
  13.             "--output-file",
  14.             f"requirements-{deps}.txt",
  15.         )

2、默认禁止

禁用所有检查,然后启用那些你认为误报比率高的。(不仅仅是漏报/误报的比率!)

  1. # noxfile.py
  2. ...
  3. @nox.session(python="3.10")
  4. def lint(session):
  5.     files = ["src/", "noxfile.py"]
  6.     session.install("-r", "requirements-pylint.txt")
  7.     session.install("-e", ".")
  8.     session.run(
  9.         "pylint",
  10.         "--disable=all",
  11.         *(f"--enable={checker}" for checker in checkers)
  12.         "src",
  13.     )

3、检查器

以下是我喜欢的检查器。加强项目的一致性,避免一些明显的错误。

  1. checkers = [
  2.     "missing-class-docstring",
  3.     "missing-function-docstring",
  4.     "missing-module-docstring",
  5.     "function-redefined",
  6. ]

使用 PyLint

你可以只使用 PyLint 好的部分。在 CI 中运行它以保持一致性,并使用常用检查器。

放弃不好的部分:默认禁止检查器。

避免危险的部分:固定版本以避免意外。


via: 

作者: 选题: 译者: 校对:

本文由  原创编译, 荣誉推出


LCTT 译者 :MjSeven💎翻译: 170.0 篇|贡献: 1720 天2018-01-30→2022-10-15https://linux.cn/lctt/MjSeven
欢迎遵照 CC-BY-SA 协议规定转载,如需转载,请在文章下留言 “转载:公众号名称”,我们将为您添加白名单,授权“转载文章时可以修改”。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存