Bon et Mauvais Code : ecire un code de qualité, des exemples en php

Comment écrire un code de qualité ?

Le monde du coding est un monde ou on entre généralement en apprenant beaucoup de choses dans le tas et de manière autodidacte, d'ailleur l'autodidacte ryme bien avec le coding car cela demande de la passion, mais developper une app qui fonctionne correctement ne signifit pas toujours qu'on a écris du code de qualité, c'est à dire du code qui non seulement est lisible, mais maintenable et peut evoluer dans le temps, c'est à dire un code flexible à l'évolution et un code qui est modulaire et scalable. La raison meme d'etre de la OOP/POO(Programmation à Object) est de permettre au developpeur de pouvoir écrire du code de qualité en le calquant à la realité quotideinne fait d'objets qui interagissent entre eux, ainsi en utilisant le paradigme à objet, on peut ecrire un code maintenable en y injectant beaucoup d'abstraction. Les developpeurs à travers le concepte de design pattern, regroupe les methodologies OOP qui ont fait succès et quand on l'applique au quotidien dans nos codes, on reuissit ainsi à le rendre flexible, scalable, maintenable bref ayant toutes les adjectifs qui le rende un code de qualité. Bien que le Design pattern soit un concept beaucoup difficile à machiner pour un débutant, la OOP cependant doit etre absolument compris si on veut faire long chemin dans le coding, j'ai parlé ici en long et en large du concept de la OOP, au quotidien cherché à utiliser la OOP à bon échéant et surtout, cherchez toujours à appliquer les principes SOLID et DRY.

Dans cette rubrique, l'idée est de faire voir des bouts de mauvais codes et  la bonne version dans l'objectif de vous y habituez au fur et à mesure que vous evoluez dans votre chemin du coding, l'exemple d'aujourd'hui s'appui sur PHP mais PHP n'est qu'un exemple la meme chose on l'applique en javascript, c#, java, typsecrip, python etc...

1. Bien nomé ses variables et leur données une description qui correspond exactement  à leur utilité, dans l'exemple  du mauvais code si dessous, on ne sait pas ce que la variable $dt signifit exactement à vu d'oeil, il serait utilise  de le definir de manière qu'on comprenne exactement son role en lisant la ligne de code.

Mauvais code: 

$dt = $moment->format('y-m-d'); 

Bon code: (quand on jette un coup d'oeil sur le code immediatement on sait que $currentDate contient la date courante)

$currentDate = $moment->format('y-m-d'); 

 

2. Ecrire du code lisible et facilement retrouvable si on recherche un mot clé dans le code : 

En tant que developpeur, Nous lirons plus de code que nous n'en écrirons jamais. Il est important que le code que nous écrivons soit lisible et consultable. En ne nommant pas les variables qui finissent par être significatives pour comprendre notre programme, les autres developpeurs qui atterissent dans notre code serint perdus car que vous le voulez ou non, le coding c'est un travail d'equipe donc il faut rendre votre code lisible et intuitif pour un autre developpeur qui le lit.

.

Mauvais code: 

class User
{
    // 7 signifit quoi en fait?
    public $access = 7;
}

// 4 dans ce if veut dire quoi?
if ($user->access & 4) {
    // ...
}

// qu'est ce qu'on a l'intention de faire ici ?
$user->access ^= 2;

Bon code: 

class User
{
    public const ACCESS_READ = 1;

    public const ACCESS_CREATE = 2;

    public const ACCESS_UPDATE = 4;

    public const ACCESS_DELETE = 8;

    // l'utilisateur par defaut peut lire, creer, mettre à jours
    public $access = self::ACCESS_READ | self::ACCESS_CREATE | self::ACCESS_UPDATE;
}

if ($user->access & User::ACCESS_UPDATE) {
   
}

// refuser l'accès
$user->access ^= User::ACCESS_CREATE;

3. Evitez d'écrire beaucoup de If..Else Embriqué les uns après les autres quand on écrit une methode(ou une fonction): 

Trop d'instructions if-else peuvent rendre votre code difficile à suivre. Etre Explicit vaut mieux qu'etre implicite.

Mauvais code: 

function isSchoolOpen($day): bool
{
    if ($day) {
        if (is_string($day)) {
            $day = strtolower($day);
            if ($day === 'friday') {
                return true;
            } elseif ($day === 'saturday') {
                return true;
            } elseif ($day === 'sunday') {
                return true;
            }
            return false;
        }
        return false;
    }
    return false;
}

Bon code:  

function isSchoolOpen(string $day): bool
{
    if (empty($day)) {
        return false;
    }

    $openingDays = ['friday', 'saturday', 'sunday'];

    return in_array(strtolower($day), $openingDays, true);
}

 

 

4. Evitez de faire des mapping mentaux: 

N'ecrivez pas le code en ayant en tete comme si c'est seulement vous qui travaillerez tout le temps sur ce code et du coup traduire une logique qui vous vient en tete dans le code sans explicitement l'écrire dans le code, quand on lit le mauvais code suivant, on ne sait pas exactement ce que le codde veut faire

Mauvais code: 

$l = ['Camerun', 'France', 'Benin'];

for ($i = 0; $i < count($l); $i++) {
    $li = $l[$i];
    doTravels();
    doSomeOtherTravels();
    // ...
    // ...
    // ...
   
    dispatch($li);
}

Bon code:  

$locations = ['Camerun', 'France', 'Benin'];

foreach ($locations as $location) {
   doTravels(); 
    doSomeOtherTravels();
    // ...
    // ...
    // ...
    dispatch($location);
}

 

 

5. Specialement dans PHP 7 utilisez le  "Null coalescing operator": 

L'opérateur ?? a été ajouté  dans PHP 7 comme étant un raccourcit pour verifier si un objet n'est pas null (verifier la nullité de quelque cose) avant son utilisation (d'ailleur cette operateur existe deja dans beaucoup de langage comme java,c#, dart etc..) 

Mauvais code: 

if (isset($_GET['name'])) {
    $name = $_GET['name'];
} elseif (isset($_POST['name'])) {
    $name = $_POST['name'];
} else {
    $name = 'nobody';
}

Bon code:  

$name = $_GET['name'] ?? $_POST['name'] ?? 'nobody';

 

 

6. Evitez de faire des fonctions/methodes avec beaucoup de parametres, cela rend votre code difficile à tester: 

Une fonction avec zero paramètre est le cas optimale, 1 ou deux sont encore acceptables, mais quand on va dejà au dela de 3 parametrès on est entrain d'écrire du mauvais  code, cela signifit en parole simple que votre fonction cherche à faire beaucoup de chose, dans ce cas il faut diviser pour mieux reigner. Dans le mauvais exemple suivant, le constructeur de notre classe Questionnaire contient beaucoup trop de paramètres, cela signifit certainement que cette classe fait beaucoup de chose danc il faut diviser les fonctionalités pour le rendre facilement testatble et lui donné une seule responsabilité (Single Responsability)

 

Mauvais code: 

class Questionnaire
{
    public function __construct(
        string $firstname,
        string $lastname,
        string $patronymic,
        string $region,
        string $district,
        string $city,
        string $phone,
        string $email
    ) {
        // ...
    }
}

Bon code:  

class Name
{
    private $firstname;

    private $lastname;

    private $patronymic;

    public function __construct(string $firstname, string $lastname, string $patronymic)
    {
        $this->firstname = $firstname;
        $this->lastname = $lastname;
        $this->patronymic = $patronymic;
    }

    // getters ...
}

class City
{
    private $region;

    private $district;

    private $city;

    public function __construct(string $region, string $district, string $city)
    {
        $this->region = $region;
        $this->district = $district;
        $this->city = $city;
    }

    // getters ...
}

class Contact
{
    private $phone;

    private $email;

    public function __construct(string $phone, string $email)
    {
        $this->phone = $phone;
        $this->email = $email;
    }

    // getters ...
}

class Questionnaire
{
    public function __construct(Name $name, City $city, Contact $contact)
    {
        // ...
    }
}

 

 

 

7. Donnez des noms auto-descriptf à vos fonctions, chaque fonction doit avoir un nom  qui décrit exactement sa mission: 

Dans le mauvais code suivant que fait effectivement la methode handle? c'est pour lire un email? pour ecrire? pour envoyer? on ne comprend pas exactement sa mission

Mauvais code: 

class Email
{
    //...

    public function handle(): void
    {
        mail($this->to, $this->subject, $this->body);
    }
}

$message = new Email(...);
//que fait effectivement cette methode handle? c'est pour lire, ou ecrire ou envoyez un email?
$message->handle();

 

Bon code:  

class Email
{
    //...

    public function send(): void
    {
        mail($this->to, $this->subject, $this->body);
    }
}

$message = new Email(...);
// c'est claire à present que sa mission est d'envoyer un email
$message->send();

 

8. Evitez d'utiliser les fonctions globales.

Les fonctions globales sont à eviter quand on veut ecrire un code maintenable, car dans la mesure ou il peut arriver que vous integrez des bibliothèques externes à votre code, ces fonctions globales pourraient allées en conflit.

Mauvais code: 

function config(): array
{
    return [
        'foo' => 'bar',
    ];
}

Bon code:  

class Configuration
{
    private $configuration = [];

    public function __construct(array $configuration)
    {
        $this->configuration = $configuration;
    }

    public function get(string $key): ?string
    {
        // null coalescing operator
        return $this->configuration[$key] ?? null;
    }
}

et vous pouvez l'insatnacié quelque part comem ceci:

$configuration = new Configuration([
    'foo' => 'bar',
]);

 voilà 8 petites choses qui ne fera pas de male à tout developpeur et on continuera dans cette rubrique au fur et à mesure qu'on deniche certaines bonne attitute à adopter quand on veut ecrit du code de qualité, on invente rien, on suit les bonnes practiques tel que l'a voulu un des veterants du code "Robert C. Martin's " dans son livre "clean code" que chaque dev devrait avoir dans sa boite à outils pour coder.

A la prochaine surtout abbonnez vous à notre blog pour continuer à avoir des contenus riches en coding

 

---

---

Share

Comments (0)

Leave A Comment

Your Name:
Comment: