看看 buildbot，一旦迁移到 python 3 完成，就可以进行检查。

http://docs.buildbot.net/latest/manual/configuration/steps/pylint.html

我通常争取在 PyLint 上至少达到 8/10，这可能需要一些工作才能达到，但从长远来看会更好。

pylint 的风险/好处是什么（我从未使用过它 – 只是用谷歌搜索了一下）
一篇文章引述：’Why Pylint is both useful and unusable’ seemed percentent

Linuxcnc 没有编码的硬性标准——一般来说，首选遵循原始代码风格。
我不认为我们有因为风格而放弃代码的奢侈。

pylint 帮我省的大事是名称隐藏和可变上下文。您可以自定义它以忽略某些错误，例如格式化、不属于包的模块、不可订阅的变量。在我运行的原始格式中，它绝对没有用。但随后必须由某个人或某个团体来决定社区不想检查的内容以及他们想要检查的内容。

EG 在 qt_action 中有一个 nfile 变量在某些情况下没有被分配，我在 pylint 上看到它，但是当我试图保存名称中有 2 个句点的文件时才成为问题。（本来想为修复添加一个 pr，但最终只是在我的 GUI 上修复了它）

TL;DR
好处 – 代码质量、错误捕获、
风险 – 还需要维护一件事，需要决定初始配置

另一个风险是提供的代码不被接受，作者放弃尝试将其放入。（即使没有代码标准，我们也会遇到这个问题）

而且我们不得不为代码标准而战:)（我发现 PEP8 对某些事情有点太挑剔了）

我个人认为，在进行此类操作之前，我们需要更多活跃的开发人员。

哦，我会对在 qt_action 中发现的错误感兴趣….

我的意思是我们不一定需要拒绝上面的代码。如果我们能得到正面的代码，人类通常会争取更高的评级。它只是激励增加数量。而且每次添加几乎不会影响它，我认为 LCNC 大约有 130 万行代码 iirc，所以每一小行几乎不会影响实际评级

真的。如果我继续努力并试图让它的评级更高一点，它会反对吗？我的意思是尽管它很自私，但我倾向于只触及我最终为我的工厂和界面提取的代码库的一部分。

今天早上我一上班，我就可以为它申请 PR。（PR 983，你有时间再看看吗？(:)

要么开发者在它被提供时修复它，要么在它被接受之前要求作者修复它，要么像你这样的人来一次修复一堆东西。
第一个需要我们没有的人力。
Seconds依赖于作者愿意并且有能力修复。
第三个导致大的合并问题（当一大堆文件一次完成时）。
我不知道最好的答案是什么。

需要明确的是，我们希望错误修复和干净的代码更好——通常只有在添加/修复其他内容时才修复代码风格更好。
如果样式更改很大，则应该分开；如果很小，则可以将其包含在内。

我们已经走了这么远——如果你有更多的代码更改，那就去做吧——我们很少有人感兴趣
我已经完成了 PEP8 审核并修复了 QtVCP，但那是在代码正式包含在 linuxcnc 之前，所以它没有惹恼了太多人。

PR 983 – 是的，很抱歉延迟

我要回到这里，因为我必须再次审查我自己的 CI 测试，并最终重新设置我自己的计算机。如果我再次开始这个过程，是首选较小的提交还是一次一个文件？

我肯定想删除的一件事是影子名称。例如。格式是一种被用作变量的想法，但它也是一个字符串函数。

我建议我们添加检查但不强制执行。开发人员往往是喜欢优化事物的人。如果我看到一个指标，我想让它成为一个更好的分数，如果我降低它，它会有点侮辱。

添加对影子名称的检查似乎是一个很好的测试添加 – 我是游戏。