Chevere

# Coding Standard

The coding standard exists as good practice for keeping the syntax cohesive as possible.

# Casing

  • PascalCase for classes and interfaces
  • SCREAMING_SNAKE_CASE for constants
  • camelCase 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)

← Immutability →