[Coding style] Vos solutions pour un code lisible ?

[Sephi-Chan]

Tien donc, encore un truc où je ne suis pas de cette avis ^^

Les guillemets te font perdre du temps d'exécution.
et mettre un anti-slash ce n’est pas la mort et n'a rien d'horrible ou d'ambigu.

Alors je ne souhaite à personne de coder avec toi (c'est sincère mais pas méchant). Tu n'es pas prêt à coder en groupe ni pour des applications qui seront amenées à être maintenues dans le temps (qui plus est par d'autres que toi).

Ça n'est pas sur la syntaxe que tu gagneras du temps, c'est sur les optimisations de l'algorithme et des accès aux données. Hélas, tu es à l'antipodes de la réalité industrielle.

Entre les deux expressions qui suivent, les deux premières sont infiniment moins lisible que la dernière, tout en étant plus longues.

echo 'Moi j\'aime le '.$food.' !'; // 35 caractères, illisible.

echo 'Moi j\'aime le ' . $food . ' !'; // 39 caractères, à peine plus lisible.

echo "Moi j'aime le {$food} !"; // Le plus lisible, en 32 caractères.

J'ai réalisé des tests en effectuant les blocs séparément, avec du repos entre les lancements : lancée 100 000 fois, la première instruction met en moyenne 0.7641 secondes à être exécuté (moyenne basée sur 10 exécutions). La seconde met en moyenne 0.8094 secondes (toujours basée sur 10 exécutions), soit un gain moyen de 0.0453 secondes en faveur de l'illisible. \o/
Le traitement lisible est 6% plus long.

J'espère pour toi que ton code sera exécuté des milliards de fois, qu'au moins tu sacrifies la lisibilité pour quelque chose. iffle:

Quand aux caractères gagnés par l'accolade, ça augmente la lisibilité de ne pas tout foutre sur une ligne, ainsi que la maintenabilité (tu es sûr de ne jamais générer de bug).

Quand a rajouter des accolade quand il n'y en a pas besoin => rajout de caractères inutiles => lisibilité--

M'enfin comme tu veux

Je pense qu'il s'agit d'une blague (je l'espère) ou d'une preuve de mauvaise foi.

À croire que tu aimes ce qui est illisible et peu maintenable : avec l'échappement et la concaténation, ça fait des caractères en plus mais ça se lit mal. Et là, sans accolades, c'est plus court mais également plus difficile à lire.

Je me doute bien que tu n'écouteras pas ces conseils (et idéalement, j'aimerai que tu expliques point par point pourquoi), mais peut-être que ça pourra profiter à d'autres.


Sephi-Chan

[Argorate]

Je pense que cette histoire de lisibilité est subjective et donc je laisserais chacun décider de ce qui lui plait.

Moi je ne suis pas gêné par la concaténation, c'est vraiment simpliste. C'est peut être que moi... je ne dit pas.
J'ai un ami qui aime beaucoup le VB et l'une des raisons c'est que la syntaxe y est très légère, très simple, et donc le code est lisible. Mettre des accolades pour rien, tu pourras me raconter se que tu veux mais ça rend pas plus lisible a mes yeux, mais je veux bien croire qu'au tien oui.

Sinon je ne vois pas en quoi cela permet de ne pas "genérer de bug". La seule manière de créer un bug quand il n'y a pas d'accolade, ce serait d'avoir besoin de rajouter une ou plusieurs instruction et d'oublier de mettre les accolades.
Si c'est ça que tu appels un meillieur maintient, je rigol^^
Si tu créé un bug de la sorte, c'est juste que tu es mauvais programmeurs OU inatentif (ce qui arrive même au meillieur). Et même si ça arrive - bien que ça ne devrait pas - c'est loin d'etre grave comme "bug".

PS: merci, je ne savais pas en plus que je gagner 6% en temps d'exec (ce qui est beaucoup pour une si petite chose)^^

[Zamentur]

Ben je ne suis pas d'accord Sephi, quand il n'y a qu'une instruction mettre les accolades ne s'envisage que dans le cas ou on sait qu'on mettra d'autre instruction.

Pour ce qui est de la visibilité des blocs, c'est l'indentation qui est la plus lisible et non l'accolade.

Avec l'indentation tu sais tout de suite repérer visuellement les blocs, pas avec les accolades.

Bref que tu les mette ou non çà ne change rien si ce n'est un code plus long en hauteur. Or certains algorithme prennent plus d'un écran, et pourtant on voudrait bien pouvoir les regarder dans leur ensemble sans scroller.

Sinon pour l'histoire des textes, je suis de l'avis de NicoMSEvent, avec un bon système de gestion de texte (indispensable à la lisibilité du code), on a pas besoin d'avoir du texte dans un code.

Bref pour moi ce genre de trucs ne se pose que dans mes fichiers textes qui sont généré automatiquement.

Enfin aucune variable ne devrait être inséré ainsi à mon sens "Moi j'aime le {$food} !"; il vaut mieux utiliser une méthode qui a recours à sprintf, c'est plus évolutif.

La position des accolades et l'histoire des guillemets c'est un troll!


Enfin pour coder en groupe, la règle est simple: il faut adopter les conventions définit et c'est tout!

[naholyr]

Je cite un lead de chez XDepend : "le code est propre à partir du moment où toute l'équipe peut le lire sans difficultés".

Il n'y a pas de règles objectives, et elles ne peuvent pas exister. L'important est d'avoir des règles et de s'y tenir pour assurer un code homogène facilitant sa relecture.

ça c'est bien pour l'un :

Code PHP :

<?php 

if ($test)

  echo 'oui';

else

  echo 'non'; 

[Sephi-Chan]

Bien sûr, le risques d'oublier de mettre les accolades est minime et pas si grave, mais à quoi bon se donner du travail supplémentaire (et à celui qui nous relit) alors qu'en mettant systématiquement le nécessaire (à savoir des accolades), on est sûr que ça ne sera cassé par aucun boulet (ça inclut soi-même, dans un moment de fatigue) ?

Si vous souhaitez créer du code moins robuste, après tout, c'est votre choix. Mais vous ne pourrez pas dire que vous n'avez pas été prévenu.

Si vous aimez jouer les gagne petit en écrivant un code bruyant, bourré de \' ' mais qui va 6% plus vite sur 100 000 itérations (comme si il n'y avait que ça dans le code). Tous les 4 millions de pages chargées, tu vas gagner l'équivalent d'une page, super !

Pour moi ce sont ce genre de petits choses qui font d'un développeur un mauvais développeur : faire du code peu robuste et peu lisible. Je trouve ça honteux et révoltant.


Sephi-Chan

[Roworll]

Ca ressemble fort à un raccourci que de lier la qualité du développeur à la lisibilité de son code.

Un développeur qui fait un code merdique (procédural, répétitif, pas optimisé) mais très lisible est-il pour autant un bon développeur ?

Quand à cette histoire de \' ' c'est tout de même un faux problème. Avec un éditeur potable supportant correctement la colorisation syntaxique, le code n'a rien d'illisible amha.

C'est très (trop) subjectif la notion de propreté du code. Rien que la question "faut-il mettre l'accolade ouvrante sur la même ligne que le if" divise les développeurs.
Je rejoins donc la vision de naholyr. Tant que le reste de l'équipe peut appréhender le code sans difficulté, on peut le considérer comme propre. Le reste est une affaire de tolérance et d'adaptation.

[NicoMSEvent]

une petite règle que je respecte de plus en plus est de nommer mes blocs de code

un petit exemple?

Code :

for($i;$i<10;$i++){ //for parcours lignes
    for($j;$j<10;$j++){ //for parcours colonnes

    }//end for parcours colonnes
}//end for parcours lignes

ça a l'avantage que même si le code est mal indenté, avec tout plein d'accolades dans tous les sens, d'être beaucoup plus lisible

[Sephi-Chan]

Bien sûr, il faut un code homogène entre les intervenants.

Ca ressemble fort à un raccourci que de lier la qualité du développeur à la lisibilité de son code.

Un développeur qui fait un code merdique (procédural, répétitif, pas optimisé) mais très lisible est-il pour autant un bon développeur ?

Je dis juste que ça y contribue.

Quand à cette histoire de \' ' c'est tout de même un faux problème. Avec un éditeur potable supportant correctement la colorisation syntaxique, le code n'a rien d'illisible amha.

Ouais, mais ça sert à rien. Tu peux utiliser les guillemets doubles. Bonne coloration ou non, ça reste visuellement bruyant, ces \' '. …


Sephi-Chan

[wild-D]

merci roworll
aujourd'hui le reformatage de code/l'auto-indentation/isoler un bloc/etc ça fait partie du minimum syndicale d'un bon IDE. Donc j'avoue que perdre son temps là-dessus, c'est franchement pas le plus glorieux.

sephi je vois pas en quoi "\" serait plus lisible que '\' ???
les singlequote, doublequote ou heredoc ont chacun leurs petites spécificités, l'intelligent c'est d'utiliser le plus adapté.


Un bon code c'est un code qu'à pas besoin de commentaire.(parce que perso si à la coloration syntaxique en passant les commentaires en transparent, ça rend le code illisible, c'est que y a un soucis).
Finalement, je pousserais la logique un peu plus loin que naholyr. Dans le monde merveilleux de Tux, un code est sensé être compréhensible non seulement pour le codeur (ou l'équipe); mais aussi pour le membre qui rejoint l'équipe ou une nouvelle équipe si le projet change de main, ou n'importe quel autre contributeur potentiel.

[Sephi-Chan]

sephi je vois pas en quoi "\" serait plus lisible que '\' ???

Ah non, je dis que la B est plus lisible que la A dans le cas présenté :

echo 'Moi j\'aime le '.$food.' !'; // A

echo "Moi j'aime le {$food} !"; // B

La A) ajoute beaucoup de chose désagréable à l'œil : autant ne pas s'embêter et utiliser les guillemets doubles.
Je ne suis pas contre les guillemets simples, j'aime simplement aller au plus lisible.

Et dans l'exemple qui suit, si je devais en choisir une, j'hésiterais car les deux sont pénibles à lire (mais si j'avais le choix, j'utiliserais un sprintf) :

echo "Hier, j'ai vu le film \"{$film}\". !"; // A

echo 'Hier, j\'ai vu le film "'.$film.'" !'; // B

Sephi-Chan