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 next/return
• Unnecessary if-else/return true/false
• Rules for checking specs
• Security checks #79
• Raise in finalize
• Excessive allocations, see comments #385
• ...

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
• VSCode extension — vscode-crystal-ameba
• Vim
  • vim-crystal via Syntastic
  • via Ale
• Scry / lsp — #37
• Code Climate
• Codacy — codacy-ameba
• pronto

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".