└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Linter Community Wiki 2 | 3 | Welcome! 4 | 5 | # What is a linter? 6 | 7 | Originally, `lint` was a tool for scanning C code for potentially risky lines of code. 8 | 9 | The C compiler already includes some checks for risky code, such as scanning to making sure that function signatures match. And unit testing adds dynamic checks to verify the behavior of a running program. Beyond these checks, `lint` adds even more checks, that neither the compiler nor the tests scan. 10 | 11 | By *statically* analyzing the code itself before compilation, programmers could maintain a higher level of code discipline, increasing the reliability of the code in multiple compilers and environments. 12 | 13 | As time went on, static code analysis was nearly eclipsed in attention, by dynamic analysis: [unit tests](https://en.wikipedia.org/wiki/Unit_test), that examine how code behaves for different inputs and corner cases. But the linting practice has restored, and spread to more languages--C++ and beyond. 14 | 15 | Today, linters are used to supplement unit tests, serving primarily as low priority style checkers. Linters are being written for many programming languages and document formats, detailed below. 16 | 17 | [Wikipedia:List of tools for static analysis](http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis) 18 | 19 | This document often interprets the term "linter" in a wide sense, to include resources for SAST, SCA, memory management validators, code formatters, and style guides. 20 | 21 | # Linters 22 | 23 | Many compilers include an option like `-Wall` to turn on warnings, `-Wextra` for even more warnings, and also `-Werror` to treat warnings as errors, preventing dirty code from compiling. 24 | 25 | ## * 26 | 27 | [actionlint](https://github.com/marketplace/actions/actionlint) identifies quirks in GitHub Actions CI/CD jobs. 28 | 29 | [anorack](https://github.com/jwilk/anorack) is a specialized spell-checker that finds incorrect indefinite articles. 30 | 31 | [astyle](http://astyle.sourceforge.net/) can help enforce a uniform coding style in a large software project. 32 | 33 | [check-all-the-things](https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/plain/doc/README) is a command-line tool for automatically running many static analysis and similar tools over packages and upstream codebases. 34 | 35 | [checkov](https://www.checkov.io/) scans cloud resources for CVE's, including Kubertes and Terraform projects. 36 | 37 | [cicada](https://github.com/mcandre/cicada) scans environments for software components at risk of falling off of LTS security support timelines. 38 | 39 | [conan](https://conan.io/) provides an audit subcommand to scan C/C++ projects for security vulnerabilities. 40 | 41 | GitHub provides [Dependabot](https://docs.github.com/en/code-security) and [CodeQL](https://codeql.github.com/) (opt-in) to scan GitHub repositories. 42 | 43 | GitLab provides [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) and [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) to scan GitLab repositories. 44 | 45 | [Code Climate](https://codeclimate.com/) is a paid web service for automatically generating code quality reports. 46 | 47 | [eclint](https://github.com/jedmao/eclint) can derive the code style used in a project, and save it as a dotfile for use in other projects. 48 | 49 | [driftwood](https://github.com/trufflesecurity/driftwood) looks up private keys in common registries. 50 | 51 | [editorconfig](http://editorconfig.org/) is an editor-agnostic configuration system for code styling. 52 | 53 | [editorconfig-cli](https://github.com/amyboyd/editorconfig-cli) is a Go-based editorconfig linter. 54 | 55 | [editorconfig-tools](https://www.npmjs.com/search?q=editorconfig-tools) is a command line linter against editorconfig rules. 56 | 57 | [dotenv-linter](https://github.com/wemake-services/dotenv-linter) finds errors and stylistic violations in `.env` files. 58 | 59 | [KICS](https://kics.io/) scans Docker and Kubernetes resources. 60 | 61 | [lint-spaces](https://github.com/schorfES/node-lintspaces) checks line endings and indentation. 62 | 63 | [pfff](https://github.com/facebook/pfff/) is a collection of tools by Facebook for analyzing code style, with support for multiple programming languages. 64 | 65 | [proselint](https://github.com/amperser/proselint/) is a linter for usage and style errors in English prose. 66 | 67 | [Snyk](https://snyk.io/) provides SCA capabilities to report known vulnerabilities for projects, across a wide variety of programming languages and frameworks. 68 | 69 | Note that Snyk Open Source neglects to scan `requirements-dev.txt` and similar industry conventional configurations for tracking development environment dependencies. 70 | 71 | Note that Snyk Open Source neglects to scan JAR files, Ivy, or Ant projects. 72 | 73 | [Sonarqube](http://www.sonarqube.org/) is a cross-programming language linting system. 74 | 75 | [Phabricator Contributing Guide](http://www.phabricator.com/docs/phabricator/article/Contributor_Introduction.html#suggested-reading) offers coding standards generally, as well as for PHP, and JavaScript code specifically. 76 | 77 | [google-styleguide](https://code.google.com/p/google-styleguide/) is a collection of documents detailing Google's preferred code style, for a variety of programming languages and data formats. 78 | 79 | [Hemingway](http://www.hemingwayapp.com/) is a software application for improving the readability of English text. By using Hemingway, we can make our documentation more understandable for others. 80 | 81 | [Mozilla Coding Style](https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style?redirectlocale=en-US&redirectslug=Mozilla_Coding_Style_Guide) is a document detailing Mozilla's preferred coding style. 82 | 83 | [MSDN Library: Coding Techniques and Programming Practices](http://msdn.microsoft.com/en-us/library/aa260844(v=vs.60).aspx) offers general tips for coding. 84 | 85 | [Microsoft patterns & practices](http://pnp.azurewebsites.net/en-us/) are recommended for .NET projects. 86 | 87 | [MSDN Library: Design Guidelines for Class Library Developers](http://msdn.microsoft.com/en-us/library/czefa0ke%28VS.71%29.aspx) presents guidelines for .NET library developers. 88 | 89 | [sunshine](https://github.com/mcandre/sunshine) validates chmod permissions, such as for SSH files. 90 | 91 | [trufflehog](https://github.com/trufflesecurity/trufflehog) reports credential exposure. 92 | 93 | [Vale](https://github.com/errata-ai/vale) validates English text against a wide variety of prebuilt style guides, and is easily and highly configurable. 94 | 95 | [vuls](https://vuls.io/) scans assorted computing environments for CVE's. 96 | 97 | [Web Package Update Checker](https://github.com/fulldecent/web-puc) validates web projects to ensure they use the latest available versions of web packages (like Bootstrap, Font Awesome, JQuery). 98 | 99 | [write-good](https://github.com/btford/write-good) validates english prose with the aim of helping developers write better code. 100 | 101 | ## SLOC 102 | 103 | [sloccount](http://www.dwheeler.com/sloccount/) is an older line counter. 104 | 105 | [cloc](https://github.com/AlDanial/cloc) is a newer line counter with support for more programming languages. 106 | 107 | [wc](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/wc.html) is a line counter for UNIX systems. 108 | 109 | ## .NET 110 | 111 | The [dotnet](https://dotnet.microsoft.com/en-us/) build system features built-in SCA capability to warn on vulnerabilities in project dependencies. The project setting `Project.PropertyGroup.AnalysisMode` (e.g. value `All`) enables SAST. Setting `Project.PropertyGroup.TreatWarningsAsErrors` to `true` enforces these checks. 112 | 113 | ## Android 114 | 115 | [lint](http://developer.android.com/tools/help/lint.html) is a tool for static analysis of Android projects. 116 | 117 | ## Awk 118 | 119 | [gawk](http://www.gnu.org/software/gawk/manual/gawk.html) has a `--lint` flag that enables some portability checks. 120 | 121 | ## BitTorrent 122 | 123 | [torrentcheck](https://sourceforge.net/projects/torrentcheck/) verifies file download hashes against .torrent files. 124 | 125 | ## C 126 | 127 | [splint](http://lclint.cs.virginia.edu/) has largely replaced the old `lint` tool, offering the same old checks, as well as additional security checks. 128 | 129 | [lint](https://en.wikipedia.org/wiki/Lint_%28software%29) the original C static analysis tool. 130 | 131 | [gcc](http://gcc.gnu.org/) offers additional warnings, through its `-Wall` and `-Wextra` options. 132 | 133 | [clang](http://clang.llvm.org/) offers even more warnings, through its `-Wall`, `-Wextra`, `-Wmost`, and `-Weverything` options. 134 | 135 | [vera++](https://bitbucket.org/verateam/vera/wiki/Home) is a static analysis tool for C/C++ code. 136 | 137 | [banned.h](https://cloudblogs.microsoft.com/microsoftsecure/2012/08/30/microsofts-free-security-tools-banned-h/) helps C/C++ programmers identify deprecated, unsafe dependencies. 138 | 139 | [sparse](https://sparse.wiki.kernel.org/index.php/Main_Page) is designed to find potential sources of program faults, especially in kernel code. 140 | 141 | [pclint](http://www.keil.com/pclint/) is a classic, non-free C/C++ linter. 142 | 143 | [Misra C CodeCheck](http://www.abxsoft.com/misra/misra-index.html) is a demo C linter. 144 | 145 | [uno](http://spinroot.com/uno/) is a simple C linter. 146 | 147 | [Infer](http://fbinfer.com/) is a static program analyzer for Java, C, Objective-C, and Swift, written in OCaml. 148 | 149 | ## C++ 150 | 151 | [cppcheck](http://cppcheck.sourceforge.net/) is an older linter with frequent regressions around suppressing spurious warnings. Not particularly well suited to cross platform development. cppcheck offers a `--addon=misra` check, although it seems to target only C(99) code. 152 | 153 | g++, part of [gcc](http://gcc.gnu.org/), offers additional checks through its `-Wall` and `-Wextra` options. g++ also includes a `-Weffc++` option to check against rules in Effective C++. 154 | 155 | [cpplint](https://pypi.python.org/pypi/cpplint/) is provided as part of the `google-styleguide`. Note that cpplint is a Python tool, which means you would also want to run Python SCA tools on all environments that install cpplint. 156 | 157 | [nsiqcppstyle](https://code.google.com/p/nsiqcppstyle/) is a South Korean C++ style checker. 158 | 159 | [flint++](https://github.com/L2Program/FlintPlusPlus) is a cross-platform, zero-dependency port of [flint](https://github.com/facebook/flint) - a linter developed at Facebook. 160 | 161 | [C++ Coding Standards](http://www.gotw.ca/publications/c++cs.htm) is a textbook documenting recommended C++ code style. 162 | 163 | [Bjarne Stroustrup's C++ Style and Technique FAQ](http://www.stroustrup.com/bs_faq2.html) is another document detailing Bjarne Stroustrup's C++ code style. 164 | 165 | [Effective C++](http://www.aristeia.com/books.html) details recommended patterns in C++ code. 166 | 167 | [Boost Library Requirements and Guidelines](http://www.boost.org/development/requirements.html) is a document detailing community standards for C++ code style. 168 | 169 | ## C# 170 | 171 | [StyleCop](https://github.com/StyleCop/StyleCop) is a C# linter that enforces style guidelines. 172 | 173 | [Gendarme](http://www.mono-project.com/docs/tools+libraries/tools/gendarme/) is a .NET Static analysis tool created by the mono team. Gendarme enforces best practices, and compatibility with the mono runtime. 174 | 175 | [FxCop](https://en.wikipedia.org/wiki/FxCop) is a .NET Static analysis tool created at microsoft. FxCop enforces best practices. 176 | 177 | [roslyn-analyzers](https://github.com/dotnet/roslyn-analyzers) is a collection of static analyzers developed by Microsoft with the Roslyn APIs. 178 | 179 | [C# Coding Conventions](http://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx) is a document detailing Microsoft's recommended patterns for C# code. 180 | 181 | [patterns & practices Guidance Explorer](http://guidanceexplorer.codeplex.com/) presents a graphical checklist of Microsoft style rules. 182 | 183 | ## Chef 184 | 185 | [foodcritic](http://www.foodcritic.io/) offers built-in rules for identifying potential problems with Chef cookbooks. 186 | 187 | ## Clojure 188 | 189 | [core.typed](https://github.com/clojure/core.typed) offers annotations for type safety. 190 | 191 | [eastwood](https://github.com/jonase/eastwood) provides a Leiningen plugin for linting Clojure code. 192 | 193 | [kibit](https://github.com/jonase/kibit/) also provides a Leiningen plugin for linting Clojure code. 194 | 195 | ## CoffeeScript 196 | 197 | [coffeelint](https://github.com/clutchski/coffeelint) for Coffee files. 198 | 199 | ## Common Lisp 200 | 201 | [lisp-critic](http://www.mail-archive.com/gardeners@lispniks.com/msg00372.html) is an old analyzer of arbitrary CL code. 202 | 203 | [xref](http://www.cs.cmu.edu/Groups/AI/lang/lisp/code/tools/xref/0.html) is an old static analysis tool for CL code. 204 | 205 | ## Conf 206 | 207 | Linux .conf configuration files may vary in format, but many popular services offer a way to check the syntax of their particular configuration files. 208 | 209 | ### Apache 210 | 211 | `apache2 -t` 212 | 213 | ### Exim 214 | 215 | `exim -bV` 216 | 217 | ### CUPS 218 | 219 | `cupsd -f -t` 220 | 221 | ### dhcpd 222 | 223 | `dhcpd (-t -cf) | (-T -lf)` 224 | 225 | ### Homebrew 226 | 227 | `brew doctor` 228 | 229 | ### Lighttp 230 | 231 | `lighttpd -t` 232 | 233 | ### MySQL 234 | 235 | `mysqld --help --verbose --skip-networking` 236 | 237 | ### Nagios 238 | 239 | `nagios -v` 240 | 241 | ### named 242 | 243 | `named-checkconf` 244 | 245 | `named-checkzone` 246 | 247 | ### Nginx 248 | 249 | `nginx -t` 250 | 251 | ### ntp 252 | 253 | `ntpd -n | -d` 254 | 255 | ### pf 256 | 257 | `pfctl -n` 258 | 259 | ### Postfix 260 | 261 | `postfix check` 262 | 263 | ### proftpd 264 | 265 | `proftpd -t` 266 | 267 | ### rsyslogd 268 | 269 | `rsyslogd -c4 -N 1` 270 | 271 | ### Samba 272 | 273 | `testparm -v` 274 | 275 | ### slapd 276 | 277 | `slapd -Tt` 278 | 279 | ### SQL (PostgreSQL, MySQL, MSSQL, ...) 280 | 281 | * SQL implementations tend to include an `EXPLAIN`... statement which can validate syntax for individual statements. 282 | * [prql](https://github.com/mcandre/prql) is a command line SQL syntax validator for SQL scripts. 283 | 284 | ### Squid 285 | 286 | `squid -k (check | parse)` 287 | 288 | ### sshd 289 | 290 | `sshd -t | -T` 291 | 292 | ### syslogd 293 | 294 | `syslogd -d` 295 | 296 | ### tcpd 297 | 298 | `tcpdchk -a | -d | -i | -v` 299 | 300 | ### Upstart 301 | 302 | ``` 303 | eval `dbus-launch --auto-syntax` && 304 | find . -type f -name '*.conf' -print | 305 | xargs -n 1 init-checkconf 306 | ``` 307 | 308 | ### varnishd 309 | 310 | `varnishd -C` 311 | 312 | ### vsftpd 313 | 314 | `vsftpd -olisten=NO` 315 | 316 | ## Ansible 317 | 318 | [ansible-later](https://ansible-later.geekdocs.de/) checks Ansible playbooks. 319 | 320 | [ansible-lint](https://ansible-lint.readthedocs.io/) is a classic Ansible linter. 321 | 322 | [Lockdown](https://www.lockdownenterprise.com/) provides recommendations for securing Ansible playbooks. 323 | 324 | [steampunk-spotter](https://pypi.org/project/steampunk-spotter/) offers additional checks for Ansible playbooks. 325 | 326 | ## Arch 327 | 328 | [arch-audit](https://github.com/ilpianista/arch-audit) generates CVE reports for Arch Linux. 329 | 330 | ## BSD 331 | 332 | [pkg-audit](https://man.freebsd.org/cgi/man.cgi?query=pkg-audit&sektion=8&n=1) generates CVE reports for FreeBSD, DragonflyBSD, and HardenedBSD. 333 | 334 | [pkg_admin](https://man.netbsd.org/pkg_admin.1) provides an `audit` subcommand for generating CVE reports on NetBSD. 335 | 336 | ## Coq 337 | 338 | [Coq](http://coq.inria.fr/) is a proof assistant, requiring all programs to be logically valid. 339 | 340 | ## CSS 341 | 342 | [csslint](https://github.com/stubbornella/csslint) for CSS files. 343 | 344 | [minify](https://npmjs.org/package/minify) can help compress, CSS, JS, and HTML files. 345 | 346 | [csstidy](http://csstidy.sourceforge.net/) can help compress CSS files. 347 | 348 | ## CSV 349 | 350 | [csv-validator](https://github.com/digital-preservation/csv-validator) verifies CSV data against a given CSV schema. 351 | 352 | ## D 353 | 354 | [gdc](http://dlang.org/) offers a built-in `-Wall` flag for additional warnings. 355 | 356 | ## Dart 357 | 358 | `pub publish` offers a `--dry-run` option. 359 | 360 | ## Debian packages 361 | 362 | [Lintian](https://lintian.debian.org/) checks for bugs and policy violations in .deb packages. 363 | 364 | ## DNS 365 | 366 | [Dlint](http://freecode.com/projects/Dlint) analyzes DNS records. 367 | 368 | ## Docker 369 | 370 | [Docker](https://www.docker.com/) features a `docker scout cves -e ` command to scans images for vulnerabilities. As a bonus, `docker scout cves fs://` recursively scans the given file path for artifact files with known vulnerabilities. 371 | 372 | [Docker First Aid Kit](https://github.com/mcandre/docker-first-aid-kit) provides performance and general advice for Docker newbies. 373 | 374 | [dockerlint](https://www.npmjs.com/package/dockerlint) 375 | 376 | ## Elisp 377 | 378 | [elisp-lint](https://github.com/nschum/elisp-lint) 379 | 380 | [elint](http://repo.or.cz/emacs.git/blob/HEAD:/lisp/emacs-lisp/elint.el) 381 | 382 | ## ePUB 383 | 384 | [epubcheck](https://github.com/IDPF/epubcheck) analyzes .epub files for errors. 385 | 386 | ## Erlang 387 | 388 | [erl_tidy](http://www.erlang.org/doc/man/erl_tidy.html), a library that comes with Erlang, attempts to automatically change unidiomatic code. 389 | 390 | [ehrlich](https://github.com/mcandre/ehrlich) provides a safer linter that does NOT automatically change your code. 391 | 392 | [dialyzer](http://www.erlang.org/doc/man/dialyzer.html), a tool that comes with Erlang, helps detect type errors. 393 | 394 | [elvis](https://github.com/inaka/elvis) is an Erlang style checker. 395 | 396 | [eqWALizer](https://github.com/WhatsApp/eqwalizer) is an Erlang type checker. 397 | 398 | ## F# 399 | 400 | [fantomas](https://github.com/dungpa/fantomas) 401 | 402 | ## File systems 403 | 404 | [fslint](http://www.pixelbeat.org/fslint/) can identify and correct errors in file systems. 405 | 406 | [Disk Utility](https://support.apple.com/kb/HT1782) can repair HFS/HFS+ partitions. 407 | 408 | [gParted](http://gparted.sourceforge.net/) can check for errors in several file systems. 409 | 410 | [fixmbr Windows](http://web.archive.org/web/20171024104649/http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/bootcons_fixmbr.mspx?mfr=true) is a DOS tool for repairing boot sectors, available in Recovery mode in Windows installation media. 411 | 412 | [fixmbr Linux](https://launchpad.net/~lenski/+archive/ms-sys/+packages) is a Linux tool for repairing boot sectors, part of the ms-sys package. 413 | 414 | ## Fortran 415 | 416 | [fortranlint](http://stellar.cleanscape.net/products/fortranlint/) 417 | 418 | ## GIF 419 | 420 | [buttery](https://github.com/mcandre/buttery) is a GIF loop editor, with an option to validate basic GIF format file integrity. 421 | 422 | ## Go 423 | 424 | The standard `go` command offers `go fmt` and `go vet` for styling and checking package integrity. 425 | 426 | The standard [govulncheck](https://go.dev/blog/govulncheck) utility scans for vulnerabilities among dependencies and among programming language versions. Note that the tool hides vulnerable packages by default, focusing narrowly only on vulnerabilities triggerable by application code, unless the option `-scan package` is provided. 427 | 428 | [deadcode](https://go.dev/blog/deadcode) identifies code snippets that appear to be unused, generally recommended for removal. 429 | 430 | Note that deadcode has an implicit assumption that at least one `main` application package is present, or at least one unit test is present and the `-test` flag is supplied to deadcode. This may not always interact well with Go projects that act as simple convenience wrappers around CLI tools. 431 | 432 | [errcheck](https://github.com/kisielk/errcheck) identifies unchecked errors. In particular, the `-blank` flag (disabled by default) identifies errors assigned to `_`. 433 | 434 | [goimports](https://godoc.org/golang.org/x/tools/cmd/goimports) supplements `go fmt` by organizing imports. 435 | 436 | [golint](https://github.com/bytbox/golint) was an early stage Go linter, since deprecated in favor of revive + staticcheck. 437 | 438 | [golang/lint](https://github.com/golang/lint) 439 | 440 | [gosimple](https://github.com/dominikh/go-tools/tree/master/cmd/gosimple) recommends more idiomatic code forms. 441 | 442 | [megacheck](https://github.com/dominikh/go-tools/tree/master/cmd/megacheck) runs staticcheck, gosimple, and unused. 443 | 444 | [nakedret](https://github.com/alexkohler/nakedret) identifies named returns, which often present unexpected behavior that can obfuscate error messages. Recommended usage: `nakedret -l 0 ./...` 445 | 446 | [opennota/check](https://github.com/opennota/check) includes linters for reducing in-memory and in-transit struct size; identifying unused struct fields; and identifying unused global variables and constants. 447 | 448 | [revive](https://revive.run/) checks for unused variables and undocumented public API members. 449 | 450 | [staticcheck](https://staticcheck.io/) adds additional checks compared to the built-in `go vet` tool. 451 | 452 | [unconvert](https://github.com/mdempsky/unconvert) detects redundant conversions. 453 | 454 | [unused](https://github.com/dominikh/go-tools/tree/master/cmd/unused) reports some unused Go code elements. 455 | 456 | ## Groovy 457 | 458 | [CodeNarc](http://codenarc.sourceforge.net) 459 | 460 | ## Haskell 461 | 462 | [GHC](http://www.haskell.org/platform/), the official Haskell compiler, is renown for producing correct programs, though its strict type system. 463 | 464 | [hlint](https://github.com/ndmitchell/hlint) displays a refactored version of your code, helping users more quickly resolve warnings. 465 | 466 | ## HTML 467 | 468 | [W3C Validator](http://validator.w3.org/) is an online service for linting HTML, XML, and CSS data. 469 | 470 | [tidy](http://tidy.sourceforge.net/) can lint HTML files. 471 | 472 | [linklint](http://linklint.org/) checks hyperlinks. 473 | 474 | ## Java 475 | 476 | [Android lint](http://tools.android.com/tips/lint) checks Android source files for potential bugs and optimization improvements for correctness, security, performance, usability, accessibility, and internationalization. 477 | 478 | [CheckStyle](http://checkstyle.sourceforge.net/), with decent CLI support, as well as decent Maven support, through [maven-checkstyle-plugin](http://maven.apache.org/plugins/maven-checkstyle-plugin/). Checkstyle also supports identifying undocumented code, through its [JavaDoc](http://checkstyle.sourceforge.net/config_javadoc.html) settings. 479 | 480 | [Error-prone](https://github.com/google/error-prone) catches common Java mistakes as compile-time errors. 481 | 482 | [FindBugs](http://findbugs.sourceforge.net/) is an old Java linter, but has kept up with Java advances (for example, by offering a standard Gradle plugin). 483 | 484 | [google-java-format](https://github.com/google/google-java-format) formats Java code according to the Google Style Guide. 485 | 486 | [Infer](http://fbinfer.com/) is a static program analyzer for Java, C, and Objective-C, written in OCaml. 487 | 488 | [javac](http://www.oracle.com/technetwork/java/javase/downloads/index.html) offers a `-Xlint` option to print additional warnings. The [maven-compiler-plugin](https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html) can be configured to automatically pass `-Xlint` to the underlying Java compiler every time a project is built. 489 | 490 | In Java 8, javac will feature an `-Xdoclint` option to identify undocumented code. 491 | 492 | [PMD](http://pmd.sourceforge.net/) detects flaws and duplicated code. 493 | 494 | ## JavaScript / ECMAScript / Node.js / altJS 495 | 496 | [npm](https://www.npmjs.com/) includes automatic SCA security scans. 497 | 498 | [yarn](https://yarnpkg.com/) provides a `yarn npm audit --all --recursive` SCA command. 499 | 500 | [CLosure Compiler](https://developers.google.com/closure/) refactors code to improve performance. 501 | 502 | [Closure Linter](https://pypi.python.org/pypi/closure_linter/) checks JavaScript for conformance to the Google Style Guide. 503 | 504 | [Code Conventions for the JavaScript Programming Language](http://javascript.crockford.com/code.html) is a document detailing community standards for JavaScript code style. 505 | 506 | [CoffeeScript](http://coffeescript.org/) is a compiles-to-JavaScript language designed to enforce good JavaScript coding habits at compiler level. 507 | 508 | [ESLint](http://eslint.org) is a pluggable and configurable javascript linter that aims to fix the non-extensibility issues of JSHint and JSLint. 509 | 510 | [JSHint](http://jshint.com/) is far and away the best modern linter available. It's simultaneously easy to use, and highly customizable; offering global and directory specific `.jshintrc` files for rule configuration; and global and directory specific `.jshintignore` files for ignoring certain files and directories, trimming down `jshint`'s output to exactly what you want to see. 511 | 512 | [JSLint](http://jslint.com/) helps coders match the code style described in [JavaScript: The Good Parts](http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/). 513 | 514 | [JSLint Errors](http://linterrors.com/js) explains warnings you may see from JSHint or JSLint. 515 | 516 | [npm-package-json-lint](https://github.com/tclindner/npm-package-json-lint) is a configurable linter to enforce standards in npm package.json files. 517 | 518 | [periscope](https://github.com/mcandre/periscope) warns on unscoped NPM packages. 519 | 520 | [rslint](https://rslint.org/) is a fast JavaScript linter. 521 | 522 | [standardjs](https://standardjs.com/) is a JavaScript linter and formatter. 523 | 524 | ## JPEG 525 | 526 | [jpegtran](http://jpegclub.org/jpegtran/) manipulates .jpg files. 527 | 528 | ## JSON 529 | 530 | [json.py](http://docs.python.org/2/library/json.html) is a built-in Python module, offering a `-mjson.tool` option for linting JSON files. 531 | 532 | [jq](http://stedolan.github.io/jq/) isn't a linter per-se, but jq can prettify JSON for creating more readable code examples. 533 | 534 | [jsonschemalint](https://github.com/nickcmaynard/jsonschemalint) verifies JSON data against a given JSON schema. 535 | 536 | ## LaTeX 537 | 538 | [lacheck](http://manpages.ubuntu.com/manpages/xenial/en/man1/lacheck.1.html) comes with LaTeX. 539 | 540 | [style-check.rb](http://www.cs.umd.edu/~nspring/software/style-check-readme.html) is a LaTeX checker written in Ruby. 541 | 542 | ## Lua 543 | 544 | `luac` offers a `-p` option to skip output file generation, useful for checking syntax without altering any files. 545 | 546 | [luac](http://www.lua.org/manual/4.0/luac.html) offers a built-in `-p` option for syntax validation.. 547 | 548 | [luacheck](https://github.com/mpeterv/luacheck) is a Lua linter. 549 | 550 | [lualint](https://github.com/philips/lualint) is an early Lua linter. 551 | 552 | [lua-checker](https://code.google.com/p/lua-checker/) is another old Lua linter. 553 | 554 | [luainspect](http://lua-users.org/wiki/LuaInspect) is yet another dead linter. 555 | 556 | ## Make 557 | 558 | make offers a `-n` dry run option, though sometimes commands are still printed. Use `make -n 1>/dev/null` to suppress this output. Of course, this represents UNIX sh syntax, so redirect stdout to the null device in Windows syntax with `1>NUL` when in Windows. 559 | 560 | GNU make offers an additional `--warn-undefined-variables` flag to check for... undefined variables. 561 | 562 | [unmake](https://github.com/mcandre/unmake) is a POSIX makefile linter focusing on portability. 563 | 564 | ## Markdown 565 | 566 | [markdownlint](https://github.com/DavidAnson/markdownlint) enforces standards for Markdown and CommonMark files via Node.js or [Ruby](https://github.com/markdownlint/markdownlint) 567 | 568 | [remark](https://github.com/remarkjs/remark-lint) checks Markdown files for various errors. 569 | 570 | ## MP3 571 | 572 | [mp3check](https://code.google.com/p/mp3check/) analyzes .mp3 files for errors. 573 | 574 | ## Objective C 575 | 576 | [clang](http://clang.llvm.org/) offers built-in options `-Wall`, `-Wextra`, `-Wmost`, and `-Weverything` for showing additional compiler warnings. 577 | 578 | [OCLint](http://oclint.org/) can lint ObjC, C, and C++ code. 579 | 580 | [Infer](http://fbinfer.com/) is a static program analyzer for Java, C, and Objective-C, written in OCaml. 581 | 582 | ## OCaml 583 | 584 | [mascot](http://mascot.x9c.fr/) 585 | 586 | ## Pascal 587 | 588 | [fpc](http://www.freepascal.org/) offers a `-vw` flag to show additional warnings. 589 | 590 | ## Perl 591 | 592 | [cpan-audit](https://metacpan.org/dist/CPAN-Audit/view/script/cpan-audit) scans Perl projects for CVE's. 593 | 594 | [perl](http://www.perl.org/) offers extra warnings through the `use warnings;` (`#!/usr/bin/env perl -w`) and `use strict;` options. 595 | 596 | [perltidy](http://perltidy.sourceforge.net/) generates a recommended refactored version of your code. 597 | 598 | [perlcritic](https://metacpan.org/pod/perlcritic) applies rules based on O'Reilly Perl Best Practices. 599 | 600 | [Perl Best Practices](http://shop.oreilly.com/product/9780596001735.do) is a textbook of recommended Perl coding conventions. 601 | 602 | ## PHP 603 | 604 | [php](http://php.net/) comes with a built-in `-l` option to check for valid syntax. 605 | 606 | [Composer](https://getcomposer.org/) includes SCA with `composer audit`. 607 | 608 | [PHPMD](http://phpmd.org/) is a configurable frontend for static checks. 609 | 610 | [PHP Code Sniffer](http://pear.php.net/package/PHP_CodeSniffer) checks .php, .js, and .css code for style. 611 | 612 | [PSR-Huh?](http://net.tutsplus.com/tutorials/php/psr-huh/) is a document detailing community standards for PHP code style. 613 | 614 | [PEAR Coding Standards](http://pear.php.net/manual/en/standards.php) is a collection of documents detailing community standards for PHP code style. 615 | 616 | [CodeIgniter General Style and Syntax](http://ellislab.com/codeigniter/user-guide/general/styleguide.html) is another document offering PHP code style tips. 617 | 618 | ## pkgsrc 619 | 620 | [pkglint](https://github.com/rillig/pkglint) checks `pkgsrc` projects, including BSD makefiles, embedded shell commands, and pkgsrc conventions. 621 | 622 | ## PNG 623 | 624 | [pngcheck](http://www.libpng.org/pub/png/apps/pngcheck.html) analyzes .png files for errors. 625 | 626 | ## PostgreSQL 627 | 628 | [pgsanity](https://github.com/markdrago/pgsanity) verifies the correctness of PostgreSQL query syntax. 629 | 630 | ## Puppet 631 | 632 | [puppet-lint](http://puppet-lint.com/) checks Puppet scripts for proper style. 633 | 634 | [vulnerability](https://forge.puppet.com/modules/enterprisemodules/vulnerability/readme) checks for Puppet CVE's. 635 | 636 | ## Python 637 | 638 | [bandit](https://github.com/openstack/bandit) security focused Python static analyzer. Your mileage may vary, regarding the usefulness of its warnings. (For example, if your application intends to open an SSH connection, then it is not particularly helpful for bandit to complain about open SSH connections.) 639 | 640 | [dlint](https://github.com/dlint-py/dlint)) is another security focused analyzer. 641 | 642 | [flake8](https://pypi.python.org/pypi/flake8) is a meta linter for Python, including PyFlakes, pep8, and McCabe. 643 | 644 | [flake8-quotes](https://github.com/zheller/flake8-quotes) is a plugin for flake8 that enforces single vs double quotes. 645 | 646 | [pep8](https://pypi.python.org/pypi/pep8/) checks Python code for PEP8 conformance. 647 | 648 | [pep257](https://pypi.python.org/pypi/pep257/) checks Python code for PEP257 docstring conformance. 649 | 650 | [PyChecker](http://pychecker.sourceforge.net/) requires executing code in order to analyze it. 651 | 652 | [PyLint](http://www.pylint.org/) is fast and customizable. 653 | 654 | [PyFlakes](https://pypi.python.org/pypi/pyflakes) offers few configuration options. 655 | 656 | [Python Style Guide](http://www.python.org/doc/essays/styleguide/) is a collection of documents for community standards for Python code style. 657 | 658 | [refurb](https://github.com/dosisod/refurb) recommends Python idioms. 659 | 660 | [wemake-python-styleguide](https://github.com/wemake-services/wemake-python-styleguide) is the strictest and most opinionated python linter ever. 661 | 662 | ## R 663 | 664 | CRAN has a [lint](http://cran.r-project.org/web/packages/lint/index.html) package. 665 | 666 | ## Racket 667 | 668 | [Typed Racket](http://docs.racket-lang.org/ts-guide/index.html) offers additional checks for type safety. 669 | 670 | ## RPM 671 | 672 | [rpmlint](http://linux.die.net/man/1/rpmlint) checks .rpm packages for errors. 673 | 674 | ## Ruby 675 | 676 | [bundler-audit](https://github.com/rubysec/bundler-audit) scans dependencies for known vulnerabilities. 677 | 678 | [contracts.ruby](http://egonschiele.github.io/contracts.ruby/) provides a dynamically enforced type safety system. 679 | 680 | [reek](https://github.com/troessner/reek) has an extensive list of checks for improving your code. 681 | 682 | [flay](https://github.com/seattlerb/flay) looks for repeated code patterns, recommending ways to reduce boilerplate and increase reliability. 683 | 684 | [roodi](https://github.com/roodi/roodi) is an old design pattern linter. 685 | 686 | [cane](https://github.com/square/cane) applies code quality checks, and can be used to fail a build on encountering poor quality code. 687 | 688 | [excellent](https://github.com/simplabs/excellent) is easy to use and configure. 689 | 690 | [rubocop](https://github.com/bbatsov/rubocop) can help users update Ruby 1.8 style code to Ruby 1.9/2.0. 691 | 692 | [heckle](http://ruby.sadi.st/Heckle.html) performs mutation testing. 693 | 694 | [saikuro](https://github.com/metricfu/Saikuro) examines code complexity. Saikuro is currently incompatible with Ruby 1.9/2.0. 695 | 696 | [brakeman](https://github.com/presidentbeef/brakeman) is a linter for [Ruby on Rails](http://rubyonrails.org/) projects. 697 | 698 | [fasterer](https://github.com/DamirSvrtan/fasterer) provides performance tips. 699 | 700 | [flog](http://ruby.sadi.st/Flog.html) identifies the most complex code in your codebase. 701 | 702 | [churn](https://github.com/danmayer/churn) looks at version control history to look for frequently changing code, often a sign of poor coding. 703 | 704 | [laser](https://github.com/michaeledgar/laser) provides basic detection for logic errors. 705 | 706 | [metric_fu](https://github.com/metricfu/metric_fu) scans with a suite of Ruby linters. 707 | 708 | [laser](https://github.com/michaeledgar/laser) is a slightly out of date Ruby linter. 709 | 710 | [ruby-style-guide](https://github.com/bbatsov/ruby-style-guide) is a document describing community standards for Ruby code style. 711 | 712 | [rails_upgrade](https://github.com/rails/rails_upgrade) helps Rails 2 code upgrade to Rails 3. 713 | 714 | [ruby-lint](https://github.com/YorickPeterse/ruby-lint) relies on the pure Ruby [parser](https://rubygems.org/gems/parser), so it may lag behind in supported Ruby version syntaxes. 715 | 716 | [rubycritic](https://github.com/whitesmith/rubycritic) provides HTML and CLI linting. 717 | 718 | [sorbet](https://sorbet.org/) is a Ruby type checker. 719 | 720 | [standard](https://github.com/testdouble/standard) provides a Ruby formatter. 721 | 722 | ## Rust 723 | 724 | The Rust package manager provides a `cargo check` command as a faster, surface level check than full app compilation. 725 | 726 | [crev](https://github.com/crev-dev/cargo-crev) assists with dependency reviews. 727 | 728 | [rustc](http://www.rust-lang.org/), the Rust compiler, offers a `-Wall` option for additional warnings. 729 | 730 | [clippy](https://github.com/rust-lang-nursery/rust-clippy) is a Rust linter. 731 | 732 | [cargo-audit](https://crates.io/crates/cargo-audit) scans Rust dependencies for vulnerabilities. 733 | 734 | [rustfmt](https://github.com/rust-lang/rustfmt) for styling. 735 | 736 | ## Sass 737 | 738 | [sass-lint](https://github.com/sasstools/sass-lint) is a Sass/SCSS linter. 739 | 740 | [scss-lint](https://github.com/brigade/scss-lint) is a Sass/SCSS and CSS linter. 741 | 742 | ## Scala 743 | 744 | The [scalac](http://www.scala-lang.org/old/sites/default/files/linuxsoft_archives/docu/files/tools/scalac.html) compiler offers optional `-Xlint` and `-deprecation` warnings. 745 | 746 | [Scalastyle](http://www.scalastyle.org/) offers CLI, SBT, and Maven interfaces to a flexible, extensible Scala linter. 747 | 748 | [Wartremover](https://github.com/puffnfresh/wartremover) is a flexible Scala code linting tool. 749 | 750 | [Scapegoat](https://github.com/sksamuel/sbt-scapegoat) is a compiler plugin for static code analysis. 751 | 752 | [Abide](https://github.com/scala/scala-abide) is a library for quick scala code checking and validation by the compiler developers. 753 | 754 | [Linter](https://github.com/HairyFotr/linter) is a static analysis compiler plugin which adds various compile-time checks. 755 | 756 | ## sh / shell / bash 757 | 758 | Many shells offer a `-n` option for validating syntax, e.g. `bash -n`, `zsh -n`, `ksh -n`, ... 759 | 760 | Note that `sh -n` on many systems actually expands to `bash -n`, `ksh -n`, etc. as `/bin/sh` is usually symlinked to superset shells. Observers keen to guarantee that their portable sh scripts are pure POSIX and not bash scripts, can either run `sh -n` on a system with a bare bones `/bin/sh`, such as Alpine Linux, Busybox, etc., either on bare metal or Docker. 761 | 762 | [beltaloada](https://github.com/mcandre/beltaloada) is a convention for writing build systems in pure (POSIX) sh, that enables deeper linting of shell code compared to make and other non-shell build systems. 763 | 764 | [slick](https://github.com/mcandre/slick) is a cross-platform POSIX `-n` checker. Substitute for `sh -n` for more reliable linting! 765 | 766 | [shlint](https://github.com/duggan/shlint) is a meta-linter, which runs `-n` checks, for any shells available, as well as `checkbashisms`. 767 | 768 | [Shellcheck](http://www.shellcheck.net/) is a bash linter written in Haskell. 769 | 770 | [checkbashisms.rb](http://manpages.ubuntu.com/manpages/xenial/en/man1/checkbashisms.1.html) is an unmaintained sh linter that reports bashisms. Because it is unmaintained, it features an inverted ROC curve. 771 | 772 | [bashate](https://pypi.python.org/pypi/bashate/) is a pep8-like linter for bash scripts. Note that bashate is a Python tool, which means you would also want to run Python SCA tools on all environments that install bashate. 773 | 774 | [shfmt](https://github.com/mvdan/sh) provides consistent styling for shell scripts. 775 | 776 | [stank](https://github.com/mcandre/stank) offers several utilities for A) identifying POSIXy shell scripts among large directories of source files and B) warnings for oddities such as shebang mismatches. 777 | 778 | ## Smalltalk 779 | 780 | [SmallLint](http://c2.com/cgi/wiki?SmallLint) integrates with the OmniBrowser to lint Smalltalk code. 781 | 782 | ## Snort 783 | 784 | [pulledpork](https://github.com/shirkdog/pulledpork) helps manage Snort rulesets. 785 | 786 | ## Swift 787 | 788 | [swiftlint](https://github.com/realm/SwiftLint) encourages better Swift style 789 | 790 | ## Terraform 791 | 792 | `terraform validate` provides built-in suport for basic syntactical correctness. 793 | 794 | [terrascan](https://runterrascan.io/) scans Terraform CVE's. 795 | 796 | [tflint](https://github.com/terraform-linters/tflint) checks Terraform plans. 797 | 798 | [tfsec](https://github.com/aquasecurity/tfsec) scans Terraform CVE's. 799 | 800 | ## Travis 801 | 802 | [travis-lint](https://github.com/travis-ci/travis-lint) checks `.travis.yml` for errors. 803 | 804 | ## Typescript 805 | 806 | [TSLint](https://palantir.github.io/tslint/) checks your TypeScript code for readability, maintainability, and functionality errors. 807 | 808 | ## XML 809 | 810 | [xmllint](https://en.wikipedia.org/wiki/Libxml2) is provided as part of the `libxml2` package. 811 | 812 | ## YAML 813 | 814 | [yamllint](https://github.com/adrienverge/yamllint) is a syntax checker and linter for YAML source. Note that yamllint is a Python tool, which means you would also want to run Python SCA tools on all environments that install yamllint. 815 | 816 | # Continuous Integration 817 | 818 | A [Jenkins](http://jenkins-ci.org/) server can generate HTML linter reports for each new code commit. 819 | 820 | [Guard](http://guardgem.org/) + [guard-shell](https://github.com/guard/guard-shell) can monitor local code files, automatically outputting linter warnings as the programmer edits his code, simulating a local continuous integration server. 821 | 822 | A [make](https://www.gnu.org/software/make/) task can bundle several linters together (e.g. `csslint`, HTML `tidy`, `jshint`), to lint different kinds of files all at once. 823 | 824 | [git hooks](http://git-scm.com/book/en/Customizing-Git-Git-Hooks) can be added to a git repo, preventing a programmer from submitting his work until it passes a configured suite of linters. 825 | 826 | # See Also 827 | 828 | * [Awesome Linters](https://github.com/caramelomartins/awesome-linters) 829 | * [mcandre/testing-frameworks](https://github.com/mcandre/testing-frameworks) 830 | * [Wikipedia List of tools for static code analysis](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis) 831 | --------------------------------------------------------------------------------