写Python的代码人，迟早会跟代码检查工具打交道。检查不是工具因为你爱它，而是代码因为某个深夜，你被一个缩进错误折磨了两个小时，检查最后发现是工具混用了空格和Tab。那一刻，代码你会明白工具的检查意义。

Pylint是工具最老牌的那个。它像一位严厉的代码语文老师，不仅抓语法错误，检查还会对你的工具命名风格、注释缺失、代码甚至代码行数过长指指点点。检查有次我写了个函数，工具功能正常，测试通过，结果Pylint甩过来一个7.2分（满分10）。我盯着那个分数，心里很不服气，但打开详细报告——它指出我有两个未使用的变量，一个函数太复杂建议拆分。仔细想想，它说得对。那晚我重构了代码，第二天调试新功能时，节省了至少半小时。

但Pylint的缺点是嗓门太大。默认配置下，它会对一切发出警告，包括那些你根本不在乎的风格问题。新项目里第一次跑它，输出几百条消息，你根本分不清哪些重要。这时候Flake8就显出优势了。它更安静，更专注，只检查语法错误、未使用的导入和明显的逻辑问题。Flake8像一位高效的同事，不多废话，直接指出“这行超过79个字符了，拆一下”或者“你导入了os但没用”。

还有个工具叫Black，它不检查，它直接改。Black是代码格式化器，风格激进——它认为所有Python代码都应该长得一样。你写a = [1,2,3]，它改成a = [1, 2, 3]。你写def f(x: int)->str:，它改成def f(x: int) -> str:。刚开始用Black的人都会有种被冒犯的感觉——凭什么你说了算？但用了一周后，你会发现团队代码review时的争论少了一大半。以前有人喜欢单引号，有人喜欢双引号，现在统统由Black说了算。省下来的时间，够你多喝两杯咖啡。

说到团队协作，还有个场景值得提。你接手一个遗留项目，里面全是那种几百行的大函数，变量名是a、b、tmp，注释几乎没有。这时候跑一下pylint --errors-only，先过滤掉风格问题，只看真正的错误。然后配合radon工具检查圈复杂度——如果某个函数的复杂度超过20，基本可以断定它需要重构。这不是玄学，高复杂度意味着那个函数有太多分支和循环，人脑很难跟踪所有路径。

别把所有检查工具都堆在本地跑。本地跑完，同事的电脑上可能因为Python版本不同、依赖版本不同，结果就不一样。正确做法是把检查集成到CI/CD流程里，每次push代码自动跑一遍。GitHub Actions或者GitLab CI里加个步骤，运行flake8和pytest，不通过就不允许合并。这听起来像给自己找麻烦，但实际效果是——你的代码库永远保持健康状态，没人会偷偷提交一段烂代码进去。

我自己常用的组合是：写代码时用Black自动格式化，保存时用Flake8检查基本错误，提交前跑一遍Pylint看有没有遗漏的坏味道。偶尔遇到Pylint报出的一些奇怪警告，比如“protected-access”，我会加一行# pylint: disable=protected-access注释。这不是逃避，而是明确告诉后来者：我知道这里违反了规则，但我有意为之，因为访问这个私有方法比复制粘贴它的实现更安全。

工具只是辅助，真正重要的是你对代码的敏感度。用久了这些工具，你会发现自己写代码时就开始注意变量命名、函数长度、注释质量——因为你知道检查工具会盯着你。这就像开车时知道路边有测速摄像头，你会不自觉放慢速度。时间久了，慢速驾驶成了习惯，摄像头反而没那么重要了。