pylint

Show lint errors in a file

$ pylint [path/to/file.py]

$ pylint [package_or_module]

$ pylint [path/to/directory]

$ pylint --rcfile [path/to/pylintrc] [path/to/file.py]

$ pylint --disable [C,W,no-error,design] [path/to/file]

pylint [options] ...
Example: pylint my_script.py
Example: pylint my_package

--rcfile=
    Specifies an alternative configuration file instead of the default .pylintrc or pyproject.toml.

--output-format=
    Sets the output format, such as text, json, or parseable.

--disable=
    Disables a specific message ID (e.g., C0301) or an entire category of messages (e.g., C for convention).

--enable=
    Enables a specific message ID or category that might be disabled by default or in the configuration.

--score=
    Controls whether the overall code quality score is displayed after analysis (default: y).

--reports=
    Controls whether the historical reports are displayed at the end of the run (deprecated in favor of other output formats).

--init-hook=
    Python code executed once before the analysis begins, useful for setting up paths or environments.

pylint is a highly configurable static code analysis tool for Python. It checks for programming errors, helps enforce a coding standard, sniffs for bad code smells, and offers suggestions on how to improve code quality.

It analyzes Python source code and reports on issues such as syntax errors, style violations (e.g., PEP 8), potential bugs (e.g., unused variables, unreachable code), and complexity. By automating code review, pylint assists developers in writing cleaner, more maintainable, and bug-free Python code, making it an essential tool in CI/CD pipelines and development workflows. It assigns a score to the analyzed code, providing a quantitative measure of its quality.

• Opinionated Defaults: pylint often enforces strict coding standards (e.g., PEP 8), which may require significant configuration to align with specific team styles.
• False Positives: Like many static analysis tools, it can occasionally produce false positives, leading to noise that needs to be filtered or addressed.
• Performance: For very large codebases, pylint can be relatively slow, though performance has improved in recent versions.
• Configuration Complexity: Its extensive configurability can be daunting for new users, requiring time to master the .pylintrc file.

pylint is highly configurable via a .pylintrc file or a pyproject.toml file in the project root or user's home directory. This allows users to enable/disable specific checks, set thresholds, and define project-specific coding standards tailored to their needs.

pylint categorizes its messages with specific IDs:

• C: Convention (style recommendations)
• R: Refactor (suggestions for code improvement)
• W: Warning (potential problems, not necessarily bugs)
• E: Error (likely bugs or serious problems)
• F: Fatal (errors that prevent pylint from running, e.g., parsing errors)

It's commonly integrated into development environments (IDEs like VS Code, PyCharm), pre-commit hooks (using tools like pre-commit), and CI/CD pipelines to automate code quality checks, ensuring consistent code quality across development teams.

pylint was initially developed by Logilab (hence its historical dependency on logilab.astng) and first released in 2003, making it one of the earliest and most comprehensive static analysis tools for Python. Over the years, it has evolved significantly, incorporating new features, improving performance, and adapting to changes in Python versions and coding standards. Its maintenance was later taken over by the Python Code Quality Authority (PyCQA), ensuring its continued development and community support. It remains a widely used tool for ensuring code quality in Python projects.

flake8(1), black(1), isort(1), mypy(1)