La semaine dernière, j'ai posé la question sur X pour savoir si vous alignez ou pas les opérateurs dans votre code.

Ami(e)s développeurs et développeuses, dans votre code, vous êtes plutôt :

1⃣ = ou => non alignés

2⃣ = ou => alignés

et pourquoi ?

— Jimmy Klein (@frjimmyklein) Janvier 12, 2024

Au cas où le tweet ci-dessus ne s'affiche pas, voici les deux propositions :

1. Opérateurs non alignés :

$author = [
    'title' => 'M.',
    'lastname' => 'Doe',
    'firstname' => 'John',
    'age' => '40',
];

2. Opérateurs alignés

$author = [
    'title'     => 'M.',
    'lastname'  => 'Doe',
    'firstname' => 'John',
    'age'       => '40',
];

Je tiens à remercier tous ceux qui ont donné leur avis à ce sujet. Les réponses ont été assez partagées :

• Ceux qui militent pour la réponse 2 indiquent que cela facilite la lecture du code.
• Ceux qui militent pour la réponse 1 mettant en avant que la réponse 2 posent des problèmes de versioning de fichier.
• Et pour finir ceux qui n'ont pas de préférence.

Il est temps de donner mon avis

Je préfère quand les opérateurs sont non alignés (réponse 1). J'ai travaillé pendant 10 ans dans une entreprise où la norme était de ne pas aligner les opérateurs et cela ne m'a posé aucun problème de lisibilité du code.

Je pense que c'est tout simplement une question d'habitude.

Je viens de rejoindre il y a 2 mois une entreprise où la norme est d'aligner les opérateurs. Très bien, le linter s'en occupe automatiquement pour moi.

Mais je voulais quand même indiquer deux points qui me posent problème avec la version "Opérateurs alignés".

Lisibilité du code

Là où j'ai quand même du mal à comprendre pour la solution 2, c'est en quoi c'est plus lisible... Si je prends l'exemple d'un fichier de traduction qui comprend de nombreuses clés :

$traductions = [
    'cle_1_a'                                           => 'ma valeur 1',
    'cle_2_aa'                                          => 'ma valeur 2',
    'cle_3_aaa'                                         => 'ma valeur 3',
    'cle_4_a'                                           => 'ma valeur 4',
    'cle_5_aaaa'                                        => 'ma valeur 5',
    'cle_6_aa'                                          => 'ma valeur 6',
    'cle_7_aaa'                                         => 'ma valeur 7',
    'cle_8_aa'                                          => 'ma valeur 8',
    'cle_9_aaaa'                                        => 'ma valeur 9',
    'cle_10_a'                                          => 'ma valeur 10',
    'ma_super_cle_super_longue_de_la_mort_qui_tue_trop' => 'ma valeur 11',
    //...
];

En quoi c'est plus lisible d'aller chercher tout à droite de l'écran la valeur d'une toute petite clé, avec le risque de se tromper de ligne... C'est bien plus lisible comme ça non :

$traductions = [
    'cle_1_a' => 'ma valeur 1',
    'cle_2_aa' => 'ma valeur 2',
    'cle_3_aaa' => 'ma valeur 3',
    'cle_4_a' => 'ma valeur 4',
    'cle_5_aaaa' => 'ma valeur 5',
    'cle_6_aa' => 'ma valeur 6',
    'cle_7_aaa' => 'ma valeur 7',
    'cle_8_aa' => 'ma valeur 8',
    'cle_9_aaaa' => 'ma valeur 9',
    'cle_10_a' => 'ma valeur 10',
    'ma_super_cle_super_longue_de_la_mort_qui_tue_trop' => 'ma valeur 11',
    //...
];

(ou alors c'est parce que j'ai l'habitude...)

Versionning avec git

Autre point relevé dans les commentaires qui étaient pour la solution 1, c'est que l'alignement des opérateurs est un calvaire pour les diff git. Nous avons par exemple des fichiers de traductions assez long en format PHP qui contient simplement un tableau associatif avec un très grand nombre de clé / valeurs. Et là où ça devient problématique, c'est quand on rajoute une ligne dans le tableau avec une clé qui a une longueur plus grande que les autres.

Exemple avec le fichier à l'origine :

$traductions = [
    'label.author.lastname'  => 'Nom',
    'label.author.firstname' => 'Prénom',
    'label.author.age'       => 'Age', 
];

Je veux rajouter la ligne 'label.address.first_line' => 'Adresse 1'

$traductions = [
    'label.author.lastname'  => 'Nom',
    'label.author.firstname' => 'Prénom',
    'label.author.age'       => 'Age',
    'label.address.first_line' => 'Adresse 1',
];

les => ne sont désormais plus alignés, il faut donc les aligner (ou le linter le fait tout seul pour vous)

$traductions = [
    'label.author.lastname'    => 'Nom',
    'label.author.firstname'   => 'Prénom',
    'label.author.age'         => 'Age',
    'label.address.first_line' => 'Adresse 1',
];

Ça paraît anodin comme ça, mais quand vous travaillez avec des fichiers versionnés, ça va vous faire un diff sur tout le tableau ! On a l'impression que tout le tableau a été modifié.

• La review devient vite pénible, à chercher ce qui a été modifié (on doit surement pouvoir demander d'ignorer les diff de modifications d'espace vide dans l'outil de review mais bon)
• Le git blame devient n'importe quoi ! Si on veut savoir quand une ligne a été rajoutée ou vraiment modifiée, on se retrouve avec comme dernier commit, un commit d'alignement d'opérateurs... trop content !
• Sans parler de la peur des conflits git entre développeurs, car on a modifié tout le fichier...

Et donc si on veut éviter ça, voici la solution qu'on m'a donnée : rajouter une ligne vide et ajouter la clé après, comme ça avec la configuration mise en place, ça ne réalignera pas tout :

$traductions = [
    'label.author.lastname'  => 'Nom',
    'label.author.firstname' => 'Prénom',
    'label.author.age'       => 'Age',

    'label.address.first_line' => 'Adresse 1',
];

Bof bof... on se retrouve avec un fichier énorme (car bon là mon exemple fait 4 lignes) avec plein de sauts de lignes partout, avec juste comme raison d'éviter de reformater tout le fichier.

Je pense qu'on a plus de valeurs ajoutées ailleurs qu'à gérer ce genre de problématique, non ?

Alors, vous l'aurez compris, je milite pour la version 1 : opérateurs non alignés.

(PS 1 : mais bon, je respecte le choix fait par l'entreprise que j'ai rejoint 😉)

(PS 2 : je vous aime quand même, même si vous préférez aligner les opérateurs 😘)