Download the PHP package monomelodies/codein without Composer
On this page you can find all versions of the php package monomelodies/codein. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package codein
monomelodies/codein
Code analysis, creation and modification library
Installation
Usage
Codein is a CLI tool to inspect PHP files or directories of PHP files for code smells. It currently works best on classes.
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:
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
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
bootstrapfiles (relative togetcwd(), again). Your project, for instance, may rely on dependency injection, configured in a central file. - A
constructorsobject 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.
