monomelodies/codein

PHP code analysis library

Maintainers

Details

github.com/monomelodies/codein

Source

Issues

Installs: 14

Dependents: 0

Suggesters: 0

Security: 0

Stars: 0

Watchers: 1

Forks: 0

Open Issues: 0

0.2.0 2022-05-08 12:44 UTC

Requires

Requires (Dev)

proprietary 9e9067be299c8f24c088dbea7df18c6ae891c535

  • Marijn Ophorst <marijn.woop@sensimedia.nl>

This package is auto-updated.

Last update: 2024-04-08 17:15:36 UTC

README

Code analysis, creation and modification library

Installation

$ composer require --dev monomelodies/codein

Usage

Codein is a CLI tool to inspect PHP files or directories of PHP files for code smells. It currently works best on classes.

$ vendor/bin/codein [OPTIONS] path/to/file/or/directory

If the supplied argument is a PHP file, just that file is analysed. If it is a directory, all PHP files in it are scanned.

Options

-r|--recursive Recursively iterate underlying directories --check=name/of/check One or more names of things to check

Adding checks

By default, Codein only scans for PHP parsing errors (hopefully, your editor is already set up to do that!). To make it more useful, one should add plugins.

Why plugins one might ask? Well, my coding style isn't going to be yours, and what I consider a code smell (missing return type hint, for instance) might be perfectly valid in your codebase (because you need to support legacy PHP versions, for instance).

Let's add a check for those return type hints:

$ composer require --dev monomelodies/codein-typehints
$ vendor/bin/codein --check=monomelodies/codein-typehints path/to/file

Writing plugins

Each plugin should extend Sensi\Codein\Check. The grunt of the work is done in the check method. It takes a single argument (the name of the file to check) and returns a Generator. Every time your plugin encounters a code smell, it should yield a string containing an error message. You can use the builtin extractClass method to get the name of the class contained in the file, allowing you to inspect.

Codein auto-appends the classname Check to the namespace specified in the --check=... option. Normal namespace resolution rules are applied:

  • forward slashes are replaced with backward slashes;
  • each part starts with a capital letter;
  • dashes are converted to snakeCase.

E.g., monomelodies/codein-typehints resolves to the class Monomelodies\CodeinTypehints\Check.

Look at existing plugins to get a feel for this.

The yielded messages are formatted using simple ansi colors, with a "<reset>\n" automatically appended. You can play with the colors; use for something really bad, for a warning etc.

The codein.json config file

Codein looks for a codein.json config file in the current working directory. It allows you to specify a few things:

  • A default array of checks. The checks are run no matter what --check=... options you specify. Handy, because with multiple plugins typing them all out each time quickly becomes old.
  • A string or array of bootstrap files (relative to getcwd(), again). Your project, for instance, may rely on dependency injection, configured in a central file.
  • A constructors object containing a key/value store of classnames with an array of the arguments to be used during construction when inspecting. Note that these arguments are verbatim; e.g. a string should be written as "'this is a string'" (note the nested quotes). This is because some classes will expect an instantiated object in their constructor arguments, allowing you to specify something like "new FooBar" as well.