PHPackages                             monomelodies/codein - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. monomelodies/codein

ActiveLibrary[Utility & Helpers](/categories/utility)

monomelodies/codein
===================

PHP code analysis library

0.2.0(4y ago)017[1 PRs](https://github.com/monomelodies/codein/pulls)proprietaryPHPCI failing

Since Feb 9Pushed 3mo ago1 watchersCompare

[ Source](https://github.com/monomelodies/codein)[ Packagist](https://packagist.org/packages/monomelodies/codein)[ RSS](/packages/monomelodies-codein/feed)WikiDiscussions master Synced 1w ago

READMEChangelogDependencies (5)Versions (4)Used By (0)

monomelodies/codein
===================

[](#monomelodiescodein)

Code analysis, creation and modification library

Installation
------------

[](#installation)

```
$ composer require --dev monomelodies/codein
```

Usage
-----

[](#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
-------

[](#options)

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

Adding checks
-------------

[](#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
---------------

[](#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](https://github.com/simoneast/simple-ansi-colors), with a `"\n"` automatically appended. You can play with the colors; use for something really bad, for a warning etc.

The `codein.json` config file
-----------------------------

[](#the-codeinjson-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.

###  Health Score

31

—

LowBetter than 68% of packages

Maintenance53

Moderate activity, may be stable

Popularity6

Limited adoption so far

Community7

Small or concentrated contributor base

Maturity48

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~819 days

Total

2

Last Release

1471d ago

### Community

Maintainers

![](https://www.gravatar.com/avatar/bce0289662bc7c78014afb3610eb7558b68948a97cb2f9b0efd1755d80dc7c2a?d=identicon)[monomelodies](/maintainers/monomelodies)

---

Top Contributors

[![monomelodies](https://avatars.githubusercontent.com/u/260346?v=4)](https://github.com/monomelodies "monomelodies (52 commits)")

### Embed Badge

![Health badge](/badges/monomelodies-codein/health.svg)

```
[![Health](https://phpackages.com/badges/monomelodies-codein/health.svg)](https://phpackages.com/packages/monomelodies-codein)
```

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)