Most teams don't pick a linter once and move on — they end up running a different one for every language in the stack, plus a couple of specialized ones for infrastructure and accessibility. That's the right instinct. A linter tuned for one language's idioms catches far more than a generic one-size-fits-all rule set ever will. Here's a practical rundown of the strongest options across the languages and use cases teams ask about most.
C# linters
The .NET SDK ships Roslyn analyzers built in, so a huge amount of linting now happens automatically as part of a normal build — no separate tool to install. On top of that baseline, most C# teams add:
- StyleCop Analyzers — enforces consistent formatting and style conventions, integrated directly into the Roslyn analyzer pipeline.
- Roslynator — a large collection of additional analyzers and refactorings beyond what ships by default.
- ReSharper / Rider inspections — IDE-integrated analysis that catches redundant code, possible null references, and dozens of other patterns as you type.
PHP linters
PHP's built-in php -l only checks for syntax errors, which is a low bar — real linting in PHP comes from a small set of mature, widely adopted tools:
- PHP_CodeSniffer (phpcs) — checks code against a defined coding standard (PSR-12 is the common default) and can auto-fix many violations with its companion tool,
phpcbf. - PHPStan — static analysis that finds real bugs, not just style issues: undefined methods, type mismatches, and dead code, at configurable strictness levels.
- Psalm— similar territory to PHPStan, with particularly strong type-inference analysis for codebases that lean on PHP's type system.
Java linters
Java's linting ecosystem splits between style enforcement and bug-finding, and most serious projects run more than one:
- Checkstyle— enforces formatting and structural conventions against a configurable rule set (Google's and Sun's style guides are common starting points).
- PMD — flags suspicious patterns like empty catch blocks, unused variables, and overly complex methods.
- SpotBugs — the modern successor to FindBugs, analyzing compiled bytecode for actual bug patterns rather than just style.
- Error Prone — a Google-maintained compiler plugin that catches common mistakes at build time, before the code ever runs.
Python linters, including a python linter online
Python has three tools most teams choose between: pylint, the most thorough and most opinionated option; flake8, a lighter combination of style and basic error checking; and ruff, a newer linter written in Rust that reimplements most of flake8's and several plugins' rules at dramatically faster speed, which has made it the default choice for a lot of new projects. If you just want to paste in a snippet and check it without installing anything — a quick sanity check, a teaching example, or a one-off script — a browser-based python linter online running these same engines under the hood is often the fastest path, with no environment setup required.
JavaScript linters, including a javascript linter online
ESLintis the standard for JavaScript and TypeScript, configurable down to individual rules and extensible with plugins for React, accessibility, imports, and virtually every framework in common use. For a javascript linter online with zero setup, ESLint's own official playground at eslint.org/play runs the real engine in the browser against pasted code or a live config, which is a safer bet than a third-party clone since it's maintained by the ESLint team itself.
Kubernetes manifests: kube-linter
Application-language linters don't help with the YAML that actually deploys your application. kube-linter fills that gap — it statically analyzes Kubernetes manifests and Helm charts for configurations that tend to cause real incidents: containers running as root, missing resource requests and limits, no liveness or readiness probes, and privilege-escalation settings left at their (unsafe) defaults. It runs entirely offline against your YAML, so it fits naturally into a pre-commit hook or a CI step, well before anything reaches a cluster.
Accessibility linters: axe, axe Linter, and axe DevTools
Accessibility issues are some of the easiest bugs to ship unnoticed, because they only show up for users on assistive technology. An accessibility linter closes that gap by checking for missing alt text, poor color contrast, incorrect ARIA usage, and unlabeled form fields as part of normal development, not as a separate audit months later. axe-core, from Deque Systems, is the engine behind most of the ecosystem, including the axe DevTools browser extension that scans a rendered page. Deque also ships axe Linter specifically, which analyzes JSX and HTML source code statically — catching accessibility issues in a pull request before the page is ever rendered, the same way ESLint catches a style violation before the app runs. Pairing it with eslint-plugin-jsx-a11y covers the React-specific patterns that a general accessibility linter can miss.
A linter tells you the rule was broken — not why it matters
Every tool above is excellent at what it's designed for: enforcing a fixed, well-defined rule consistently, on every commit, without getting tired or skipping a file. What none of them do is reason about your specific code the way a reviewer would — a linter can't tell you that a permission check is missing on a new endpoint, that a database migration will lock a table under production load, or that a function handles an edge case incorrectly. Those require understanding what the code is trying to do, not just whether it matches a pattern. That gap is exactly why lint-clean code still needs a real review before it ships.