RP

@MjSeven
https://linux.cn/article-15144-1.html

published/20220919 PyLint- The good, the bad, and the ugly.md

@@ -3,27 +3,26 @@
 [#]: author: "Moshe Zadka https://opensource.com/users/moshez"
 [#]: collector: "lkxed"
 [#]: translator: "MjSeven"
-[#]: reviewer: " "
+[#]: reviewer: "wxy"
-[#]: publisher: " "
+[#]: publisher: "wxy"
-[#]: url: " "
+[#]: url: "https://linux.cn/article-15144-1.html"
 
-PyLint: 优点，缺点和危险
+PyLint 的优点、缺点和危险
 ======
-充分利用 PyLint。
 
-![带有问号的 Python 编程标志][1]
+![](https://img.linux.net.cn/data/attachment/album/202210/16/093840z9pnzfv9ykfccoq9.jpg)
 
-图像来源: Opensource.com
+> 充分利用 PyLint。
 
 热议：PyLint 实际上很好！
 
-“PyLint 可以拯救你的生命”，这是一句夸张的描述，但没有你想象的那么多。PyLint 可以让你远离非常难找到和复杂的缺陷。最坏的情况下，它只可以节省测试运行的时间。最好情况下，它可以帮你避免生产环境中复杂的错误。
+“PyLint 可以拯救你的生命”，这是一句夸张的描述，但没有你想象的那么夸张。PyLint 可以让你远离非常难找到的和复杂的缺陷。最差的情况下，它只可以节省测试运行的时间。最好的情况下，它可以帮你避免生产环境中复杂的错误。
 
 ### 优点
 
-我不好意思说这种情况是多么普遍。命名测试总是*奇怪的*：没有人关心名字，而且通常也找不到一个自然的名字。例如以下代码：
+我不好意思说这种情况是多么普遍。测试的命名总是*那么奇怪*：没有人关心这个名称，而且通常也找不到一个自然的名称。例如以下代码：
 
-```python
+```
 def test_add_small():
     # Math, am I right?
     assert 1 + 1 == 3
@@ -43,10 +42,11 @@ test.py ..
 2 passed
 ```
 
-但问题是：如果你覆盖了一个名称，测试框架将愉快地跳过这个测试！
+但问题是：如果你覆盖了一个测试的名称，测试框架将愉快地跳过这个测试！
+
 实际上，这些文件可能有数百行，而添加新测试的人可能并不知道所有的名称。除非有人仔细查看测试输出，否则一切看起来都很好。  
 
-最糟糕的是，*覆盖测试的添加*，*覆盖测试的破坏*，以及*连锁反应问题*可能以会以天、月甚至年为单位发现。
+最糟糕的是，*被覆盖测试的添加*、*被覆盖测试造成的破坏*，以及*连锁反应的问题*可能要几天、几月甚至几年才能发现。
 
 ### PyLint 会找到它
 
@@ -59,9 +59,9 @@ test.py:8:0: E0102: function already defined line 1
 
 ### 缺点
 
-就像 90 年代的情景喜剧一样，你对 PyLint 了解的越多，问题就越多。对一个库存建模程序来说，以下是完全合理的代码：
+就像 90 年代的情景喜剧一样，你对 PyLint 了解的越多，问题就越多。以下是一个库存建模程序的常规代码：
 
-```python
+```
 """Inventory abstractions"""
 
 import attrs
@@ -84,15 +84,15 @@ R0903: Too few public methods (0/2) (too-few-public-methods)
 
 有没有想过在一个数百万人使用的工具中加入自己未证实的观点？PyLint 每月有 1200 万次下载。
 
-> "如果太挑剔，人们会取消检查" — 这是 PyLint github 的 6987 编号事务，在 2022 年七月 3 号提出
+> “如果太挑剔，人们会取消检查” — 这是 PyLint GitHub 的 6987 号议题，于 2022 年 7 月 3 号提出
 
-对于添加一个可能有许多误报的测试，它的态度是 ... *嗯*。
+对于添加一个可能有许多误报的测试，它的态度是 ... “*嗯*”。
 
 ### 让它为你工作
 
 PyLint 很好，但你需要小心地与它配合。为了让 PyLint 为你工作，以下是我推荐的三件事：
 
-#### 1. 固定它
+#### 1、固定版本
 
 固定你使用的 PyLint 版本，避免任何惊喜！
 
@@ -111,7 +111,7 @@ from unittest import mock
 
 这与以下代码对应：
 
-```python
+```
 # noxfile.py
 ...
 @nox.session(python=VERSIONS[-1])
@@ -129,11 +129,11 @@ def refresh_deps(session):
         )
 ```
 
-#### 2. 默认禁止
+#### 2、默认禁止
 
-禁用所有检查，然后启用那些你认为误报比率高的。（不仅仅是漏报/误报的比率！）（to 校正：这里没理解）
+禁用所有检查，然后启用那些你认为误报比率高的。（不仅仅是漏报/误报的比率！）
 
-```python
+```
 # noxfile.py
 ...
 @nox.session(python="3.10")
@@ -149,11 +149,11 @@ def lint(session):
     )
 ```
 
-#### 3. 检查器
+#### 3、检查器
 
 以下是我喜欢的检查器。加强项目的一致性，避免一些明显的错误。
 
-```python
+```
 checkers = [
     "missing-class-docstring",
     "missing-function-docstring",
@@ -177,7 +177,7 @@ via: https://opensource.com/article/22/9/pylint-good-bad-ugly
 作者：[Moshe Zadka][a]
 选题：[lkxed][b]
 译者：[MjSeven](https://github.com/MjSeven)
-校对：[校对者ID](https://github.com/校对者ID)
+校对：[wxy](https://github.com/wxy)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出