I hope you're not suggesting I didn't read past the first couple of paragraphs. The last line in my original post explicitly refers to the antepenultimate para

I hope you're not suggesting I didn't read past the first couple of paragraphs. The last line in my original post explicitly refers to the antepenultimate paragraph in the article. The author's problem comes directly from not using pylint, then introducing it to a large, established project. You simply can't get a list of 20,000 style issues when you first run this kind of checker, if you use it from the start of your project. If you introduce lint later on, the proposed approach of whitelisting and ramping up is OK, and probably a good idea to start with if you are really swamped, but once you have done a bit of ramping up, you should switch to blacklisting and ramping down. IMO, unless you have tonnes of violations evenly distributed across all the different types of violations, then blacklisting and ramping down is a better approach. Blacklisting is better than whitelisting in this case for a few reasons: * By disabling all, you will miss out on any new rules you didn't know about (e.g. from plugins or new versions of pylint) * Whitelisting requires you to think about all the possible violations, and work out if they matter to you; Blacklisting allows you to just look at the individual high-frequency violations in your codebase, and work out if those particular ones matter to you. * Blacklisting allows you to knock off the low-hanging-fruit where there are just a few instances of a particular violation, and keep that aspect clean as you go. Whitelisting ignores anything you have personally deemed unimportant, possibly saving up a big cleanup for later. Looking at one of the linked examples - there are disabled warnings that can introduce quite subtle bugs and maintainability problems (e.g. dangerous-default-value), some that are rarely seen and simple to fix (e.g. unnecessary-semicolon), some that are syntax errors in more recent Pythons (e.g. duplicate-argument-name). Even in an older project, nothing is gained by disabling these warnings and you just end up with noise in your pylintrc file. Pylint produces a report that shows the counts of the different violations, in frequency order. Start at the top and work your way down to either produce a blacklist or fix the problems.