All Projects → hchasestevens → Bellybutton

hchasestevens / Bellybutton

Licence: mit
Custom Python linting through AST expressions

Programming Languages

python
139335 projects - #7 most used programming language

Projects that are alternatives of or similar to Bellybutton

Swiftlint
Stars: ✭ 15,500 (+7808.16%)
Mutual labels:  linting, linter, static-analysis
unimport
A linter, formatter for finding and removing unused import statements.
Stars: ✭ 119 (-39.29%)
Mutual labels:  linter, static-analysis, ast
codeclimate-eslint
Code Climate Engine for ESLint
Stars: ✭ 86 (-56.12%)
Mutual labels:  linting, linter, static-analysis
Spoon
Spoon is a metaprogramming library to analyze and transform Java source code (up to Java 15). 🥄 is made with ❤️, 🍻 and ✨. It parses source files to build a well-designed AST with powerful analysis and transformation API.
Stars: ✭ 1,078 (+450%)
Mutual labels:  static-analysis, ast, abstract-syntax-tree
addlint
An example linter written with go/analysis for tutorial purposes
Stars: ✭ 49 (-75%)
Mutual labels:  linting, linter, static-analysis
Unimport
A linter, formatter for finding and removing unused import statements.
Stars: ✭ 96 (-51.02%)
Mutual labels:  static-analysis, linter, ast
Editorconfig Checker
A tool to verify that your files are in harmony with your .editorconfig
Stars: ✭ 119 (-39.29%)
Mutual labels:  linter, linting
Ansible Lint Action
GitHub Action for running ansible-lint as part of your workflows! [ https://github.com/marketplace/actions/ansible-lint ]
Stars: ✭ 124 (-36.73%)
Mutual labels:  linter, linting
Bodyclose
Analyzer: checks whether HTTP response body is closed and a re-use of TCP connection is not blocked.
Stars: ✭ 181 (-7.65%)
Mutual labels:  static-analysis, linter
Js Sql Parser
SQL(select) parser written with jison. parse SQL into abstract syntax tree(AST) and stringify back to SQL. sql grammar follows https://dev.mysql.com/doc/refman/5.7/en/select.html
Stars: ✭ 141 (-28.06%)
Mutual labels:  ast, abstract-syntax-tree
Graphql Go Tools
Tools to write high performance GraphQL applications using Go/Golang.
Stars: ✭ 96 (-51.02%)
Mutual labels:  linter, ast
Rstcheck
Checks syntax of reStructuredText and code blocks nested within it
Stars: ✭ 130 (-33.67%)
Mutual labels:  static-analysis, linter
Ts Morph
TypeScript Compiler API wrapper for static analysis and programmatic code changes.
Stars: ✭ 2,384 (+1116.33%)
Mutual labels:  static-analysis, ast
Abaplint
Standalone linter for ABAP
Stars: ✭ 111 (-43.37%)
Mutual labels:  static-analysis, linter
Cgen
C/C++ source generation from an AST
Stars: ✭ 107 (-45.41%)
Mutual labels:  ast, abstract-syntax-tree
Njsscan
njsscan is a semantic aware SAST tool that can find insecure code patterns in your Node.js applications.
Stars: ✭ 128 (-34.69%)
Mutual labels:  static-analysis, linter
Gopherci
GopherCI was a project to help you maintain high-quality Go projects, by checking each GitHub Pull Request, for backward incompatible changes, and a suite of other third party static analysis tools.
Stars: ✭ 105 (-46.43%)
Mutual labels:  static-analysis, linter
Rewrite
Semantic code search and transformation
Stars: ✭ 134 (-31.63%)
Mutual labels:  ast, abstract-syntax-tree
React Ast
render abstract syntax trees with react
Stars: ✭ 160 (-18.37%)
Mutual labels:  ast, abstract-syntax-tree
Cflint
Static code analysis for CFML (a linter)
Stars: ✭ 156 (-20.41%)
Mutual labels:  static-analysis, linter

bellybutton

Build Status PyPI version PyPI - Python Version

bellybutton is a customizable, easy-to-configure linting engine for Python.

What is this good for?

Tools like pylint and flake8 provide, out-of-the-box, a wide variety of rules for enforcing Python best practices, ensuring PEP-8 compliance, and avoiding frequent sources of bugs. However, many projects have project-specific candidates for static analysis, such as internal style guides, areas of deprecated functionality, or common sources of error. This is especially true of those projects with many contributors or with large or legacy codebases.

bellybutton allows custom linting rules to be specified on a per-project basis and detected as part of your normal build, test and deployment process and, further, makes specifying these rules highly accessible, greatly lowering the cost of adoption.

Give bellybutton a try if:

  • You find yourself making the same PR comments over and over again
  • You need a means of gradually deprecating legacy functionality
  • You're looking to build a self-enforcing style guide
  • Your project needs to onboard new or junior developers more quickly and effectively
  • You have Python nitpicks that go beyond what standard linting tools enforce

Installation & getting started

bellybutton can be installed via:

pip install bellybutton

Once installed, running

bellybutton init

in your project's root directory will create a .bellybutton.yml configuration file with an example rule for you to begin adapting. bellybutton will also try to provide additional rule settings based on the directory structure of your project.

Once you have configured bellybutton for your project, running

bellybutton lint

will lint the project against the rules specified in your .bellybutton.yml. Additionally, running

bellybutton lint --modified-only

will, if using git, only lint those files that differ from origin/master.

For adding bellybutton to your CI pipeline, take a look at this repository's tox configuration and .travis.yml as an example.

Concepts

Rules

Rules in bellybutton supply patterns that should be caught and cause linting to fail. Rules as specified in your .bellybutton.yml configuration must consist of:

  • A description description, expressing the meaning of the rule
  • An expression expr, specifying the pattern to be caught - either as an astpath expression or as a regular expression (!regex ...).

Additionally, the key used for the rule within the rules mapping serves as its name.

Rules may also consist of:

  • Settings settings that specify on which files the rule is to be enforced, as well as whether it can be ignored via a # bb: ignore comment
  • An example example of Python code that would be matched by the rule
  • A counter-example instead of an alternative piece of code, for guiding the developer in fixing their linting error.

These example and instead clauses are checked at run-time to ensure that they respectively are and are not matched by the rule's expr.

As an example, a rule to lint for a deprecated function call using an astpath expression might look like:

DeprecatedFnCall:
  description: `deprecated_fn` will be deprecated in v9.1.2. Please use `new_fn` instead.
  expr: //Call[func/Name/@id='deprecated_fn']
  example: "deprecated_fn(*values)"
  instead: "new_fn(values)"

Settings

!settings nodes specify:

  • included paths on which rules are to be run, using glob notation
  • excluded paths on which rules are not to be run (even when matching the included paths)
  • A boolean allow_ignore which determines whether rules can be ignored, providing the line matching the rule has a # bb: ignore comment.

Additionally, at the root level of .bellybutton.yml, a default_settings setting may be specified which will be used by rules without explicit settings. Each rule must either have a settings parameter or be able to fall back on the default_settings.

As an example, a !settings node to lint only a specific module might look like:

my_module_settings: !settings
  included:
    - ~+/my_package/my_module.py
  excluded: []
  allow_ignore: no

Example usage

Check out this repository's .bellybutton.yml as an example bellybutton configuration file, and astpath's README for examples of the types of patterns you can lint for using bellybutton.

Development status

bellybutton is in an alpha release and, as such, is missing some key features, documentation, and full test coverage. Further, bellybutton is not optimized for performance on extremely large codebases and may contain breaking bugs. Please report any bugs encountered.

Known issues:

  • The !chain and !verbal expression nodes are not yet implemented

Contacts

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].