Home

Roadmap

Rules

• Useless assignments
• Unused arguments
• Shadowed argument
• Shadowing outer variable
• Duplicated method
• Unneeded private method
• Unreachable code
• Redundant .with_index, .with_object, each_with_index, each_with_object
• Expression in a void context
• Unnecessary return
• Unnecessary if-else/return true/false
• Rules for checking specs
• Security checks https://github.com/veelenga/ameba/issues/79
• ...

Changes / additions / improvements

• Show end location of the error (node.end_location)
• Add an option to display affected code in DotFormatter
• Add severity error/warning/refactoring etc.
• Rename Error and source.errors to the entity that fits better (i.e. Issue, source.issues)
• Use namespaces for rules, i.e. Lint, Style etc.
• Autocorrect issues #34
• Semantic analysis
• Built-in watcher
• Rule property to filter by filetypes/wildcards
• Ameba extensions
• Website (better documentation + blog)
• ...

Integrations

• Emacs ameba.el

• SublimeText SublimeLinter-contrib-ameba

• Atom atom-linter-ameba

• VSCode extension vscode-crystal-ameba

• Vim

  • vim-crystal via Syntastic
  • via Ale

• Scry / lsp. See #37

• Code Climate

• Codacy. See codacy-ameba

Extensions

Would be really cool to make ameba more extensible. Let's say if someone would need the linting of config/*.yml or *.ecr files, he would just create a third-party project, register its own "rules" through Ameba's interface and use it together with the main "engine".

So the runner/formatters/config etc. will remain the same and the developer will need to take care of his own "rules".