充分利用 PyLint。敲黑板：PyLint 实际上很好！“PyLint 可以拯救你的生命”，这是一句夸张的描述，但没有你想象的那么夸张。PyLint 可以让你远离非常难找到的和复杂的缺陷。最差的情况下，它只可以节省测试运行的时间。最好的情况下，它可以帮你避免生产环境中复杂的错误。优点我不好意思说这种情况是多么普遍。测试的命名总是那么奇怪：没有人关心这个名称，而且通常也找不到一个自然的名称。例如以下代码：def test_add_small(): # Math, am I right? assert 1 + 1 == 3 def test_add_large(): assert 5 + 6 == 11 def test_add_small(): assert 1 + 10 == 11 测试生效：collected 2 items test.py .. 2 passed 但问题是：如果你覆盖了一个测试的名称，测试框架将愉快地跳过这个测试！实际上，这些文件可能有数百行，而添加新测试的人可能并不知道所有的名称。除非有人仔细查看测试输出，否则一切看起来都很好。最糟糕的是，被覆盖测试的添加、被覆盖测试造成的破坏，以及连锁反应的问题可能要几天、几月甚至几年才能发现。PyLint 会找到它就像一个好朋友一样，PyLint 可以帮助你。test.py:8:0: E0102: function already defined line 1 (function-redefined) 缺点就像 90 年代的情景喜剧一样，你对 PyLint 了解的越多，问题就越多。以下是一个库存建模程序的常规代码："""Inventory abstractions""" import attrs @attrs.define class Laptop: """A laptop""" ident: str cpu: str 但 PyLint 似乎有自己的观点（可能形成于 90 年代），并且不怕把它们作为事实陈述出来：$ pylint laptop.py | sed -n '/^laptop/s/[^ ]*: //p' R0903: Too few public methods (0/2) (too-few-public-methods) 危险有没有想过在一个数百万人使用的工具中加入自己未证实的观点？PyLint 每月有 1200 万次下载。“如果太挑剔，人们会取消检查” — 这是 PyLint GitHub 的 6987 号议题，于 2022 年 7 月 3 号提出对于添加一个可能有许多误报的测试，它的态度是 ... “嗯”。让它为你工作PyLint 很好，但你需要小心地与它配合。为了让 PyLint 为你工作，以下是我推荐的三件事：1、固定版本固定你使用的 PyLint 版本，避免任何惊喜！在你的 .toml 文件中定义:[project.optional-dependencies] pylint = ["pylint"] 在代码中定义：from unittest import mock 这与以下代码对应：# noxfile.py ... @nox.session(python=VERSIONS[-1]) def refresh_deps(session): """Refresh the requirements-*.txt files""" session.install("pip-tools") for deps in [..., "pylint"]: session.run( "pip-compile", "--extra", deps, "pyproject.toml", "--output-file", f"requirements-{deps}.txt", ) 2、默认禁止禁用所有检查，然后启用那些你认为误报比率高的。（不仅仅是漏报/误报的比率！）# noxfile.py ... @nox.session(python="3.10") def lint(session): files = ["src/", "noxfile.py"] session.install("-r", "requirements-pylint.txt") session.install("-e", ".") session.run( "pylint", "--disable=all", *(f"--enable={checker}" for checker in checkers) "src", ) 3、检查器以下是我喜欢的检查器。加强项目的一致性，避免一些明显的错误。checkers = [ "missing-class-docstring", "missing-function-docstring", "missing-module-docstring", "function-redefined", ] 使用 PyLint你可以只使用 PyLint 好的部分。在 CI 中运行它以保持一致性，并使用常用检查器。放弃不好的部分：默认禁止检查器。避免危险的部分：固定版本以避免意外。via: https://opensource.com/article/22/9/pylint-good-bad-ugly作者：Moshe Zadka 选题：lkxed 译者：MjSeven 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
当你想要争论代码复杂性时，Pylint 是你的朋友。 in VIM")Pylint 是更高层级的 Python 样式强制程序。而 flake8 和 black 检查的是“本地”样式：换行位置、注释的格式、发现注释掉的代码或日志格式中的错误做法之类的问题。默认情况下，Pylint 非常激进。它将对每样东西都提供严厉的意见，从检查是否实际实现声明的接口到重构重复代码的可能性，这对新用户来说可能会很多。一种温和地将其引入项目或团队的方法是先关闭所有检查器，然后逐个启用检查器。如果你已经在使用 flake8、black 和 mypy，这尤其有用：Pylint 有相当多的检查器和它们在功能上重叠。但是，Pylint 独有之处之一是能够强制执行更高级别的问题：例如，函数的行数或者类中方法的数量。这些数字可能因项目而异，并且可能取决于开发团队的偏好。但是，一旦团队就参数达成一致，使用自动工具强制化这些参数非常有用。这是 Pylint 闪耀的地方。配置 Pylint要以空配置开始，请将 .pylintrc 设置为[MESSAGES CONTROL] disable=all这将禁用所有 Pylint 消息。由于其中许多是冗余的，这是有道理的。在 Pylint 中，message 是一种特定的警告。你可以通过运行 pylint 来确认所有消息都已关闭：$ pylint <my package>通常，向 pylint 命令行添加参数并不是一个好主意：配置 pylint 的最佳位置是 .pylintrc。为了使它做一些有用的事，我们需要启用一些消息。要启用消息，在 .pylintrc 中的 [MESSAGES CONTROL] 下添加enable=<message>, ...对于看起来有用的“消息”（Pylint 称之为不同类型的警告）。我最喜欢的包括 too-many-lines、too-many-arguments 和 too-many-branches。所有这些会限制模块或函数的复杂性，并且无需进行人工操作即可客观地进行代码复杂度测量。检查器是消息的来源：每条消息只属于一个检查器。许多最有用的消息都在设计检查器下。默认数字通常都不错，但要调整最大值也很简单：我们可以在 .pylintrc 中添加一个名为 DESIGN 的段。[DESIGN] max-args=7 max-locals=15另一个有用的消息来源是“重构”检查器。我已启用一些最喜欢的消息有 consider-using-dict-comprehension、stop-iteration-return（它会查找正确的停止迭代的方式是 return 而使用了 raise StopIteration 的迭代器）和 chained-comparison，它将建议使用如 1 <= x < 5，而不是不太明显的 1 <= x && 5 > 5 的语法。最后是一个在性能方面消耗很大的检查器，但它非常有用，就是 similarities。它会查找不同部分代码之间的复制粘贴来强制执行“不要重复自己”（DRY 原则）。它只启用一条消息：duplicate-code。默认的 “最小相似行数” 设置为 4。可以使用 .pylintrc 将其设置为不同的值。[SIMILARITIES] min-similarity-lines=3Pylint 使代码评审变得简单如果你厌倦了需要指出一个类太复杂，或者两个不同的函数基本相同的代码评审，请将 Pylint 添加到你的持续集成配置中，并且只需要对项目复杂性准则的争论一次就行。via: https://opensource.com/article/19/10/python-pylint-introduction作者：Moshe Zadka 选题：lujun9972 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出