标签 Pylint 下的文章

充分利用 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 是你的朋友。

 title= in VIM")

Pylint 是更高层级的 Python 样式强制程序。而 flake8black 检查的是“本地”样式:换行位置、注释的格式、发现注释掉的代码或日志格式中的错误做法之类的问题。

默认情况下,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-linestoo-many-argumentstoo-many-branches。所有这些会限制模块或函数的复杂性,并且无需进行人工操作即可客观地进行代码复杂度测量。

检查器消息的来源:每条消息只属于一个检查器。许多最有用的消息都在设计检查器下。默认数字通常都不错,但要调整最大值也很简单:我们可以在 .pylintrc 中添加一个名为 DESIGN 的段。

[DESIGN]
max-args=7
max-locals=15

另一个有用的消息来源是“重构”检查器。我已启用一些最喜欢的消息有 consider-using-dict-comprehensionstop-iteration-return(它会查找正确的停止迭代的方式是 return 而使用了 raise StopIteration 的迭代器)和 chained-comparison,它将建议使用如 1 <= x < 5,而不是不太明显的 1 <= x && 5 > 5 的语法。

最后是一个在性能方面消耗很大的检查器,但它非常有用,就是 similarities。它会查找不同部分代码之间的复制粘贴来强制执行“不要重复自己”(DRY 原则)。它只启用一条消息:duplicate-code。默认的 “最小相似行数” 设置为 4。可以使用 .pylintrc 将其设置为不同的值。

[SIMILARITIES]
min-similarity-lines=3

Pylint 使代码评审变得简单

如果你厌倦了需要指出一个类太复杂,或者两个不同的函数基本相同的代码评审,请将 Pylint 添加到你的持续集成配置中,并且只需要对项目复杂性准则的争论一次就行。


via: https://opensource.com/article/19/10/python-pylint-introduction

作者:Moshe Zadka 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出