Open Source Frameworks

golangci-lint is a fast Go linters runner. It runs linters in parallel, uses caching, supports yaml config, has integrations with all major IDE and has dozens of linters included. ⚡ Very fast: runs linters in parallel, reuses Go build cache and caches analysis results. Yaml-based configuration. Integrations with VS Code, Sublime Text, GoLand, GNU Emacs, Vim, Atom, GitHub Actions. A lot of linters included, no need to install them. Minimum number of false positives because of tuned default settings. Nice output with colors, source code lines and marked identifiers.

Container Image Linter for Security, Helping build the Best-Practice Docker Image, Easy to start. You can install dockle with the asdf version manager with this plugin, which automates the process of installing (and switching between) various versions of github release binaries. With asdf already installed, run commands to install dockle. You can scan your built image with Dockle in Travis CI/CircleCI. Though, you can ignore the specified target checkpoints by using .dockleignore file. Or, if you just want the results to display and not let the test fail for this, specify --exit-code to 0 in dockle command.

Bootlint is a tool that checks for several common HTML mistakes in webpages that are using Bootstrap in a fairly "vanilla" way. Vanilla Bootstrap's components/widgets require their parts of the DOM to conform to certain structures. Bootlint checks that instances of Bootstrap components have correctly structured HTML. Optimal usage of Bootstrap also requires that your pages include certain <meta> tags, an HTML5 doctype declaration, etc.; Bootlint checks that these are present. Bootlint assumes that you are using Bootstrap's default class names in your webpage, as opposed to taking advantage of the "mixins" functionality of Less or Sass to map them to custom class names. If you are using mixins, Bootlint may report some false-positive warnings. However, there are some Bootlint checks that are applicable even if you are using mixins pervasively.

gts is Google's TypeScript style guide, and the configuration for our formatter, linter, and automatic code fixer. No lint rules to edit, no configuration to update, no more bike shedding over syntax. No configuration. The easiest way to enforce consistent style in your project. Just drop it in. Automatically format code. Just run gts fix and say goodbye to messy or inconsistent code. Catch style issues & programmer errors early. Save precious code review time by eliminating back-and-forth between reviewer & contributor. Opinionated, but not to a fault. We recommend you use the default configuration, but if you need to customize compiler or linter config, you can. Under the covers, we use eslint to enforce the style guide and provide automated fixes, and prettier to re-format code.

Ethlint (Formerly Solium) analyzes your Solidity code for style & security issues and fixes them. Standardize Smart Contract practices across your organization. Integrate with your build system. Deploy with confidence! Solium does not strictly follow Solidity Style Guide. The practices it enforces by default are best practices for the community at large. If you’re using vim with syntastic, and prefer to use a locally installed version of Solium (rather than a global version), you can install syntastic local solium to automatically load the local version in packages that have installed their own. Solium does not strictly adhere to Solidity Style Guide. It aims to promote coding practices agreed upon by the community at large. You can specify rules or plugins to apply as command line options. If you specify one, it overrides its corresponding configuration in the soliumrc file.

The most opinionated Go source code linter. go-critic is a collection of checks that detect style, and performance issues as well as some common programming errors. We provide as many useful checks as possible. We’re prototyping and experimenting here. When specific check implementation is mature and proven useful, propose it’s integration into other linter. If a good checker can’t find a better home, it stays here. Almost 100 diagnostics that check for bugs, performance and style issues. Extensible without re-compilation with dynamic rules. Includes #opinionated checks with very strict and specific requirements. Self-documented: gocritic doc <checkname> gives a checker description. Usage of gocritic: gocritic [sub-command] [sub-command args...] Run gocritic without arguments to get help output.