# 👨🏾💻 Coding Standard
The coding standard exists as good practice for keeping the syntax cohesive as possible.
# Casing
PascalCase
for classes and interfacesSCREAMING_SNAKE_CASE
for constantscamelCase
for everything else
# Code Style
Code style is provided using EasyCodingStandard (opens new window), defined at the ecs.php (opens new window) file, which extends ecs-chevere.php (opens new window).
# Implement in your project
To implement the code style is simple as get the ecs-chevere.php
file then create your own ecs.php
file inheriting the base defined by Chevere.
# Installing assets
Install ECS with composer.
composer require symplify/easy-coding-standard --dev
Install chevere/code-style (opens new window) remote repository as code-style
in your project root using GIT.
git remote add code-style git@github.com:chevere/code-style.git
# ecs.php
You will need to create an ecs.php
configuration (opens new window) file in your project root.
<?php // ecs.php
declare(strict_types=1);
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;
return static function (ContainerConfigurator $containerConfigurator): void {
$containerConfigurator->import(__DIR__ . '/ecs-chevere.php');
// extra config here
};
# Retrieving assets
Fetch code-style
to download the ecs-chevere.php
file (or any of its changes).
git fetch code-style
Merge code-style
changes into your working branch (for example, main
).
git merge code-style/main --allow-unrelated-histories
✔ The chevere-ecs.php
file will be available in your project root, repeat fetch & merge to keep it updated.
# Custom header comment
Use a file named .header
in your project root to define the header comment for your .php
files.
Example
Use the following contents as an example for your project.
This file is part of projectName.
(c) My Name <user@email-hostname>
For the full copyright and license information, please view the LICENSE
file that was distributed with this source code.
# Typing
# Type Hinting
- All parameters, properties and return expressions should be type hinted
# Code comments
Comments in logic are very discouraged and it should be used only in the following cases:
@codeCoverage
tags- Type hinting (for example, in loops)
# DocBlocks
DocBlock content should be short as possible, relevant and omit the obvious.
- Use markdown
@throws
must be provided for all known exceptions@param
and@return
should be avoided (prefer typed code)