Open Source Python Linters

An extremely fast Python linter, written in Rust. Ruff aims to be orders of magnitude faster than alternative tools while integrating more functionality behind a single, common interface. Ruff can be used to replace Flake8 (plus dozens of plugins), isort, pydocstyle, yesqa, eradicate, pyupgrade, and autoflake, all while executing tens or hundreds of times faster than any individual tool. Ruff is extremely actively developed and used in major open-source projects. Ruff can be configured through a pyproject.toml, ruff.toml, or .ruff.toml file (see: Configuration, or Settings for a complete list of all configuration options). Ruff supports over 500 lint rules, many of which are inspired by popular tools like Flake8, isort, pyupgrade, and others. Regardless of the rule's origin, Ruff re-implements every rule in Rust as a first-party feature.

Pylint is a static code analyzer for Python 2 or 3. The latest version supports Python 3.7.2 and above. Pylint analyses your code without actually running it. It checks for errors, enforces a coding standard, looks for code smells, and can make suggestions about how the code could be refactored. Projects that you might want to use alongside pylint include flake8 (faster and simpler checks with very few false positives), mypy, pyright or pyre (typing checks), bandit (security-oriented checks), black and isort (auto-formatting), autoflake (automated removal of unused import or variable), pyupgrade (automated upgrade to newer python syntax) and pydocstringformatter (automated pep257). Pylint isn't smarter than you: it may warn you about things that you have conscientiously done or checks for some things that you don't care about. During adoption, especially in a legacy project where pylint was never enforced.

Ansible Lint is a command-line tool for linting playbooks, roles and collections aimed towards any Ansible users. Its main goal is to promote proven practices, patterns and behaviors while avoiding common pitfalls that can easily lead to bugs or make code harder to maintain. Ansible lint is also supposed to help users upgrade their code to work with newer versions of Ansible. Due to this reason we recommend using it with the newest version of Ansible, even if the version used in production may be older. As any other linter, it is opinionated. Still, its rules are the result of community contributions and they can always be disabled based individually or by category by each user. ansible-lint checks playbooks for practices and behavior that could potentially be improved. As a community-backed project ansible-lint supports only the last two major versions of Ansible.

PyChecker is a static analysis tool for finding bugs in Python source code. It finds problems that are typically caught by a compiler for less dynamic languages, like C and C++. It is similar to lint.

A collection of tools for checking the validity and consistency of PO and POT files.

JavaScript Lint is a development tool that validates JavaScript code for best coding practices, finding common mistakes without actually running the script or opening the web page.

This linter plugin for SublimeLinter provides an interface to ESLint. It will be used with "JavaScript" files, but since eslint is pluggable, it can actually lint a variety of other files as well. SublimeLinter will detect some installed local plugins, and thus it should work automatically for e.g. .vue or .ts files. If it works on the command line, there is a chance it works in Sublime without further ado. Make sure the plugins are installed locally colocated to eslint itself. T.i., technically, both eslint and its plugins are described in the very same package.json. Configuration of the plugins is out-of-scope of this README. Be sure to read their README's as well. (If you just installed a plugin, without proper configuration, eslint will probably show error messages or wrong lint results, and SublimeLinter will just pass them to you.)

This repository is for the GitHub Action to run a Super-Linter. It is a simple combination of various linters, written in bash, to help validate your source code. The super-linter finds issues and reports them to the console output. Fixes are suggested in the console output but not automatically fixed, and a status check will show up as failed on the pull request. The design of the Super-Linter is currently to allow linting to occur in GitHub Actions as a part of continuous integration occurring on pull requests as the commits get pushed. It works best when commits are being pushed early and often to a branch with an open or draft pull request. There is some desire to move this closer to local development for faster feedback on linting errors but this is not yet supported. There is no need to set the GitHub Secret as it is automatically set by GitHub, it only needs to be passed to the action.

The web lint checks HTML and XHTML pages for possible markup problems. It attempts to find problems with your code that an HTML validator does not.

Welcome to the strictest and most opinionated Python linter ever. wemake-python-styleguide is actually a flake8 plugin with some other plugins as dependencies. Ensures consistency - no matter who works on it, the end product will always be the same dependable code. Helps avoid potential bugs - strict rules make sure that you don't make common mistakes. Efficient code reviews - each piece of code has a similar familiar style and syntax. If it passes all the checks, there's little left to review! Fewer code revisions - strict linting ensures that you don't have to re-write the codebase again and again. Reduce code redundancy - Sometimes we write complex code as we are thinking in a certain way about a problem. The linter offers suggestions that can help simplify the code and eliminate redundant statements. The ultimate goal of this project is to make all people write exactly the same Python code.