Discussion :

[Benjamin Delespierre]

Bonjour à tous,

Je mets dans cette discussion un point de vue intéressant sur la problématique de lisibilité en PHP.

La discussion d'origine se trouve par ici.

Si vous avez un avis sur la question ou que vous souhaitez simplement partager votre expérience sur ce qui est acceptable ou non en termes de lisibilité, n'hésitez pas à intervenir.

message à l'origine du débat

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
foreach($entry as $key => $name){
   if($name === null){
      $entry[$key] = '0';
   }
}

tsss

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<?php
foreach ($entry as & $value)
     $value === null && $value = 0;

[John Blobsmith]

tsss

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<?php
foreach ($entry as & $value)
     $value === null && $value = 0;

Intéressant, complexe, optimisé mais complètement illisible...
Je te renvoi vers les concepts de programmation egoless.

http://en.wikipedia.org/wiki/Egoless_programming

[Bovino]

mais complètement illisible...

Ah bon...

[Benjamin Delespierre]

Je ne pense pas que la légère amélioration proposée soit si complexe. En revanche, elle est clairement plus performante:



Je suis moi aussi engagé dans une optique de simplification du code, tant que c'est possible et surtout pas au détriment des performances. L'objectif est de trouver un compromis acceptable, pas de passer pour un gourou.

[grunk]

Ta solution , va plus vite et fait 3 ligne de moins mais pour le coup j'ai mis plus de temps à la lire que celle de John , pourtant je commence à avoir quelques année de php derrière moi ^^

C'est ce que voulais dire John Blobsmith je pense.

C'est le même principe que la notation ternaire , c'est plus joli mais c'est généralement plus long à lire qu'un simple if else

[John Blobsmith]

Oui, si on développe en équipe, on ne peut pas ce permettre ce genre de syntaxe... bien qu'elle soit optimisé

[Bovino]

Franchement si...

Je ne vois pas ce qu'il y a de compliqué...
Pour la syntaxe du foreach(), elle est plus logique puisque tu souhaites modifier la valeur du tableau parcouru.
Pour ce qui est du pseudo if(), même si tu ne l'as jamais rencontré, il n'est pas compliqué de comprendre comment ça fonctionne...

[John Blobsmith]

L'important n'est pas "Est-ce que mes collègues vont le comprendre ?" mais plutôt "En combien de temps vont-ils le comprendre ?".
J'ai fais le test à l'instant avec 3 collègues, au moin 10 secondes pour comprendre cette syntax contre quasiment 0 pour une syntax classique...

Sur des vieilles applications avec des fichiers de plus de 1500 lignes, ce genre de syntax rend l'appli complètement indébuggable.

Pour moi c'est à banir!

[Benjamin Delespierre]

Personnellement, je n'arrive pas à comprendre comment on peut se dire développeur quand on bloque sur une expression booléenne mais bon... Je veux bien admettre que c'est pas évident pour tout le monde. De là à dire que c'est illisible et à bannir, y'a de la marge.

D'autant que je rappelle que ce genre de syntaxe est énormément utilisée en JS, qui n'a jamais vu:

Code JS :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
function foo () {
  var bar = arguments[0] || "default";
}

Bien entendu que la lisibilité d'un script doit être une priorité, mais je pense qu'on peut tolérer les opérateurs ternaires, les expressions booléennes et autres joyeusetés de ce genre là ou elles sont utiles: i.e. là ou elles permettent une compression de code qui reste lisible.

Je tordrais plus volontiers le cou à ceux qui utilisent à tord et à travers des 'or die' (ce qui au passage est également une expression booléenne mais passons) y compris lors du développement.

[grunk]

Personnellement, je n'arrive pas à comprendre comment on peut se dire développeur quand on bloque sur une expression booléenne mais bon...

C'est pas une question de bloqué sur l'expression. Un if classique , je le lis comme si il était écrit en texte "classique". Du coup la lecture du code est fluide

Avec ton expression , je la comprend , mais j'ai effectivement besoin de m’arrêter une fraction de seconde pour bien comprendre ce que je lis.

Du coup c'est joli à l'oeil , ça va plus vite mais c'est pas agréable à relire.

Après c'est peut être moi qui est le cerveau ralenti par le froid et la neige ^^

PS : Pour moi avec le JS on atteint en général le summum des notations bordélique et des bouilli de code infâme

[rawsrc]

Bonjour,

la solution de Benjamin est très propre mais peut s'avérer piègeuse dans la mesure où $value === null && $value = 0; fait appel à un opérateur d'affectation au sein d'une comparaison.
A noter également que PHP court-circuite l'évaluation du second test (ici une affectation) quand le premier échoue.

C'est comme avec le JS, avec l'habitude on s'y fait sans problème.
Après c'est peut-être plus lisible ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$clean = array_map(function($p) { return ($p === null) ? 0 : $p; }, $data);

[Benjamin Delespierre]

C'est effectivement piégeux car on peut facilement s'emêler les pinceaux avec l'opérateur d'assignation. Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<?php
$a = 123;
isset($a) && $b = $a && $c = $a

Dans cet exemple, $b contiendra true et $c 123. car en réalité, c'est ça qu'il se passe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<?php
$a = 123;
isset($a) && $b = ($a && $c = $a)

Donc, il faut faire attention à la priorité des opérateurs.

A noter également que, contrairement à JavaScript, en PHP une expression booléenne renvoie toujours un booléen, alors qu'en JavaScript, c'est la valeur qui est renvoyée:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// en JS
var a = b || c; // a contiens la valeur de b ou celle de c
 
// en PHP
$a = $b || $c; // $a contiens un booléen

C'est d'ailleurs assez dommage que PHP ne soit pas aligné avec JS sur ce point, c'est 'achement pratique.

Question lisibilité, je n'utilise l'assignation dans des expressions booléennes que lors de cas simples (comme celui exposé ci-dessus), il n'est en aucun cas question que ça ralentisse la lecture du code. Par ailleurs, je ne tolère jamais les instructions qui s'étalent sur plusieurs lignes (ou sur plus de 120 caractères de longueur).

[ABCIWEB]

Je rejoins John Blobsmith (et les autres qui vont dans ce sens) pour dire que ce genre de "chinoiseries" ne favorisent pas la fluidité de la lecture.

Pour ma part je n'utilise l'opérateur ternaire que dans des formes simples et facilement compréhensibles.

La méthode avec array_map donnée en exemple par rawsrc est celle que j'utilise presque systématiquement dans ce cas de figure.

[bannik]

En fait, les deux méthode me conviennent... Dans la mesure ou le code est convenablement commenté (outil très utile pour le développement en équipe). Le première méthode nécessitera simplement plus de commentaires que la seconde.

J'utilise les deux méthodes, la première pour les gros traitements, le seconde pour le code de tous les jour, mais il est clair que je commente toujours beaucoup la première méthode, peut la seconde.

[Benjamin Delespierre]

Concernant la documentation, je suis on ne peut plus d'accord. C'est extrêmement chronophage mais nécessaire !

J'utilise pour ma part la syntaxe doxygen, ce qui me permet de générer automatiquement des manuels techniques de ce genre: http://bdelespierre.github.com/php-axiom/index.html

[grunk]

Concernant la documentation, je suis on ne peut plus d'accord. C'est extrêmement chronophage mais nécessaire !

J'utilise pour ma part la syntaxe doxygen, ce qui me permet de générer automatiquement des manuels techniques de ce genre: http://bdelespierre.github.com/php-axiom/index.html

Dans le même genre y'a APiGen qui est intégré à netbeans (clic droit => generate pour avoir sa doc)

[John Blobsmith]

En fait, les deux méthode me conviennent... Dans la mesure ou le code est convenablement commenté (outil très utile pour le développement en équipe). Le première méthode nécessitera simplement plus de commentaires que la seconde.

J'utilise les deux méthodes, la première pour les gros traitements, le seconde pour le code de tous les jour, mais il est clair que je commente toujours beaucoup la première méthode, peut la seconde.

Pour ma part je ne vois pas l’intérêt de commenter un foreach (dans un cas d'utilisation "classic"), tout le monde sait comment ça fonctionne et de toute façon la documentation php est la pour ça.

Je pense d'autre part que pour l'optimisation du code, la meilleur solution c'est d'utiliser un framework efficace(avec un cache intégré...) et un système de cache comme APC.
De toute façon dans 95% des cas (j'aurai pu dire 99%), quant il y a des problèmes de lenteur le problème vient de la base de donnée ou du framework utilisé... (non non, j'ai oublié aussi le stagiaire qui met une requête sql dans un foreach...)

[Benjamin Delespierre]

[TrollMode]Oui, allons-y ! Codons comme des cochons avec des algos hyper-pas-optimisés-du-tout du style O(n^40), c'est pas grave, y'a un cache [/TrollMode]

Pour l'optimisation, je ne sais pas comment vous faites mais personnellement:

1. j'active le profiler de xdebug (histoire qu'il remplisse ma machine de fichier .profile)
2. je regarde en détail quels sont les instructions les plus gourmandes avec WebGrind
3. si nécéssaire, j'optimise mon MDD et mes requêtes SQL
4. j'essaie de trouver des algos plus efficaces pour les traitements
5. si malgré tout, le temps d’exécution n'est pas satisfaisant, j'utilise un cache

Coté commentaires, il ne s'agit pas non plus de traduire dans sa langue maternelle toutes les instructions qu'on utilise non plus , un peu de discernement.

[Seb33300]

Je trouve également que la premiere solution est bien plus lisible.
Je suis pas vraiment fan du code sans accolade.

Et si la 2eme est plus performante, c'est probablement grace au passage de la variable par référence. Et sur ce point je suis d'accord.
Si on passe la variable par référence dans la première méthode, ya des chances que les perfs soient plus sérrées.

C'est effectivement piégeux car on peut facilement s'emêler les pinceaux avec l'opérateur d'assignation. Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<?php
$a = 123;
isset($a) && $b = $a && $c = $a

Dans cet exemple, $b contiendra true et $c 123. car en réalité, c'est ça qu'il se passe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<?php
$a = 123;
isset($a) && $b = ($a && $c = $a)

Donc, il faut faire attention à la priorité des opérateurs.

Comme je ne suis également pas fan de ne pas mettre de parenthese.
Et j'utilise ls opérateurs textuels 'or' et 'and' plutot que && ou ||, plus naturel à lire.
Par contre la priorité n'est pas la meme entre les 2 versions. Raison de plus d'utiliser des parentheses.

[John Blobsmith]

L'objectif est de trouver un compromis acceptable, pas de passer pour un gourou.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
foreach($entry as & $name){
   if($name === null){
      $name = '0';
   }
}

Ceci me semble être le compromis acceptable entre lisibilité et optimisation.
- Je garde toutes les accolades pour garder une homogénéité dans le code.
- Je laisse le "if" car quant on veux faire une condition on met un "if"...
- j'introduit le & pour passer la valeur par référence, surement la partie la moin optimisé du code de base que j'avais fournis.