JeuWeb - Crée ton jeu par navigateur
[Coding style] Vos solutions pour un code lisible ? - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Coding style] Vos solutions pour un code lisible ? (/showthread.php?tid=4309)

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17


RE: [Coding style] Vos solutions pour un code lisible ? - Anthor - 04-09-2009

Ça existe encore les echo ? Big Grin


RE: [Coding style] Vos solutions pour un code lisible ? - pascal - 04-09-2009

Gagner 6% sur des lignes concernant 3% du code, c'est optimiser ?

Arrêtez de vous prendre la tête et concentrez vous sur le cache, l'utilisation d'un framework, la compression des images et des fichiers statiques à la place, c'est plus rentable.

A+

Pascal


RE: [Coding style] Vos solutions pour un code lisible ? - NicoMSEvent - 04-09-2009

(04-09-2009, 04:30 PM)Anthor a écrit : Ça existe encore les echo ? Big Grin

tu utilises quoi? ^^


(04-09-2009, 04:47 PM)pascal a écrit : Gagner 6% sur des lignes concernant 3% du code, c'est optimiser ?
D'une certaine manière oui Wink ça peut en valoir la peine (surtout dans des boucles)
(04-09-2009, 04:47 PM)pascal a écrit : Arrêtez de vous prendre la tête et concentrez vous sur le cache, l'utilisation d'un framework, la compression des images et des fichiers statiques à la place, c'est plus rentable.
Pour ma part, j'ai compressé tous les fichiers JS (prototype, scriptaculous, ...), j'ai quand même bien gagné en bande passante dessus
Scripts (8 files) 68 KB (288 KB uncompressed) :p
Je devrais encore faire un petit travail sur les images, il me semble que je peux encore gagner facilement 20 à 25%
Par contre, pour le temps d'exécution, c'est 100x plus rapide sur les serveur d'OVH que sur mon dual core 2GHz ^^ (j'avais déjà fait un grand travail sur les index, et la production d'images, j'ai été bluffé par les temps d'exécution d'OVH Wink )


RE: [Coding style] Vos solutions pour un code lisible ? - guile - 04-09-2009

Faites vous même les tests de 10000 echo truc avec apostrophes, guillemets... allez y ...

Les conseils qui ont été donnés sont :
- basés sur des tests avec php4 ... on est normalement en php5 ...
- prodigué par des comptes .... énormes comme Google (ah bah oui, 10000 echo on gagne 14ms ils vont prendre!)

Il est bien d'avoir de bonnes pratiques pour coder.
Les bonnes pratiques sont :
- faire un code qui fonctionne vite et bien
- faire un code qu'on comprend
- faire un code qu'on peut reprendre
- faire un code qui peut être corrigé dans un temps optimal

Pour information, en utilisant simplement un gestionnaire de buffer de sortie on gagne 75% de temps de réponse. Ce n'est pas la solution miracle, mais juste un exemple illustrant la question de la performance.

Pour exemple sur un code lisible : j'ai été impressionné par la commande php list(), l'ai testée, et l'ai aussitôt abandonnée.
Pourquoi : parce que si ça me définit X variables en une ligne, c'est également une commande totalement étrange quand on pense "C" : utiliser une fonction comme valeur à gauche d'un opérateur d'affectation, et qui tape sur plusieurs variables.
A lire en une traite, ce n'est pas le genre de chose qu'on capte tout de suite.

Quand on debug du code, on se retrouve à devoir comprendre rapidement du code. Et là il est préférable de respecter les canons.


RE: [Coding style] Vos solutions pour un code lisible ? - Argorate - 04-09-2009

Pour ce quie st des apostrophes dans les echo:

(04-09-2009, 07:22 PM)guile a écrit : Il est bien d'avoir de bonnes pratiques pour coder.
Les bonnes pratiques sont :
- faire un code qui fonctionne vite et bien : comme indiquer c'est plus rapide
- faire un code qu'on comprend : un programmeur qui ne comprend pas une concatenation n'est pas un programmeur a mon sens
- faire un code qu'on peut reprendre : je vois pas en quoi mettre un antislash irait a l'encontre de reprendre le code. Surtout qu'une fois le texte défnit c'est rarement "reprit".
- faire un code qui peut être corrigé dans un temps optimal Pour corriger du texte, il n'y a pas de compétance particulière a avoir et etre géner par une concaténation c'est vraiment désatreux pour un programmeur...

Je pense sinsérement que ce n'est pas incompatible ni avec la lisibilité, ni aucun des points évoqués ci-dessus.

Après, chacun juge et chacun choisis ça methode. Ce qui est bien en prog c'est qu'on est relativement libre et qu'il y a rarement une façon de faire les choses (mais certaines son plus rapides... :p)


RE: [Coding style] Vos solutions pour un code lisible ? - Zamentur - 04-09-2009

(04-09-2009, 02:19 PM)Fnor a écrit : Pour les virgules dans un echo, je trouve que ça restreint l'évolutivité du code.

Le gain de temps est négligeable (25% de moins qu'une concaténation, de mémoire), mais le code n'est plus valable que pour un echo.

Il m'est déjà arrivé d'avoir codé un script avec des virgules, pour ensuite changer d'avis et vouloir transmettre ces données. Et il m'a fallu transformer toutes les virgules en points... Depuis, je n'utilise plus les virgules.

Une autre solution aurrait pu être d'utiliser ob_start(), mais çà se comprend moins bien à la lecture car echo est souvent synonyme de sortie sur la page généré pour de nombreux codeur.

Citation :
Citation :Ça existe encore les echo ?
tu utilises quoi?
Ben perso j'utilise les systeme de template notamment celui du wiki.

Donc j'utilise les short tag quand ils sont activés sinon je génère les echo à a place.

Résultat il n'y a pas de echo.


RE: [Coding style] Vos solutions pour un code lisible ? - guile - 05-09-2009

(04-09-2009, 11:04 PM)Argorate a écrit : Pour ce quie st des apostrophes dans les echo:

(04-09-2009, 07:22 PM)guile a écrit : Il est bien d'avoir de bonnes pratiques pour coder.
Les bonnes pratiques sont :
- faire un code qui fonctionne vite et bien : comme indiquer c'est plus rapide
- faire un code qu'on comprend : un programmeur qui ne comprend pas une concatenation n'est pas un programmeur a mon sens
- faire un code qu'on peut reprendre : je vois pas en quoi mettre un antislash irait a l'encontre de reprendre le code. Surtout qu'une fois le texte défnit c'est rarement "reprit".
- faire un code qui peut être corrigé dans un temps optimal Pour corriger du texte, il n'y a pas de compétance particulière a avoir et etre géner par une concaténation c'est vraiment désatreux pour un programmeur...

Je pense sinsérement que ce n'est pas incompatible ni avec la lisibilité, ni aucun des points évoqués ci-dessus.

Après, chacun juge et chacun choisis ça methode. Ce qui est bien en prog c'est qu'on est relativement libre et qu'il y a rarement une façon de faire les choses (mais certaines son plus rapides... :p)

C'est drôle, on dirait que tu as pris mes remarques pour toi là où rien ne s'adressait à toi. Le fait de reprendre les points que j'ai cités pour énumérer des arguments à la limite de la tautologie me font penser que tu te sens visés.
De plus, fait attention quand tu réponds à qqn en lui disant "ouai ceux qui disent ce que tu dis sont des mauvais programmeurs" ... Sur ce coup, je crois qu'une majorité de personne s'offusquerait.

Je m'en tapait de vos débats idiots sur la concaténation, les apostrophes, les machins, les trucs.

Voir ce sujet : http://forum.jeux-web.com/index.php?topic=85.new#new

C'est clair, sur 100000 itération je n'ai pas trouvé de différence flagrante.

+1 à Zamentur qui a "techniqué" mes propos sur les gestionnaires de buffer de sortie.


RE: [Coding style] Vos solutions pour un code lisible ? - Argorate - 05-09-2009

Je ne faisais que faire remarqué que mes propos n’étaient pas incompatibles a ce qui semble être les bons ingrédients pour bien programmer.
Pour le coup j'ai l'impression que pour le coup, c'est toi qui t'es sentis "offusquais" comme tu dis. C'était juste un simple rapprochement Wink

Bref, pour reprendre un peu plus le chemin du topic, je serais curieux de savoir ce que certains pensent vis a vis des commentaires dans le code?

Je crois avoir lu qq'un qui disais qu'un bon code n'avais pas besoin de commentaire, hors j'ai tendance a pensé l'inverse:
Mettre des commentaires est très bénéfique même quand le code et déjà simplifié et lisible, cela ne peut qu'être un plus.
Et cela permet en même temps, d'assurer une meilleure compréhension et donc que meilleure maintenance du code (d'autant plus sur les projets avec plusieurs codeurs).


RE: [Coding style] Vos solutions pour un code lisible ? - Allwise - 05-09-2009

J'ai lu ça aussi sur les commentaires, mais j'avais trouvé l'article trop catégorique. Les commentaires sont indispensables, ne serait-ce que pour documenter la signature des fonctions, sauce phpDoc, d'autant plus que PHP n'est pas un langage typé et que quand on lit function getAgadou($maVar, $var2, $blablabla), on connait pas le type des arguments ni celui du retour.

Ensuite, pour ce qui est des commentaires au sein même des fonctions tout ça, je dirais que ça dépend du public qui est susceptible de mettre les mains dans le code source, de la complexité du code. Par exemple si je tombe sur un algo qui fait des calculs sur les bits, vu que j'en fais jamais, je serai un peu paumé et j'aimerais bien avoir des ptits commentaires sur des lignes que "je" trouve complexes. Pareil pour un code source qui utiliserait une extension php, ou une lib exotique. Mais pour le reste, si le code n'a pas été tapé à la gitanos, il est généralement assez parlant pour sa compréhension et il ne raconte que ce qu'il fait Smile


RE: [Coding style] Vos solutions pour un code lisible ? - guile - 05-09-2009

Il y a la pratique de l'Extreme Programming (si un code a besoin de commentaire c'est qu'il peut être réécrit). Pour ça, de toutes façon il faut être dans une équipe qui pratique l'XP et (je n'ai jamais pu expérimenter) ce doit ne pas être gênant.

Il y a ensuite la pratique naïve :

$compteurDeBaballes++; // on incrémente le compteur de baballes de 1
if ($compteurDeBaballes > 10) // si le compteur de baballe est plus grand que 10
...
Là c'est clair que c'est non non et non pour ce type de commentaire qui n'apporte rien

Et il y a une approche classique qui cherche à décrire le choix qui a été fait dans le code pour en arriver à telle ligne. J'ai toujours fait ainsi : on pense que son collègue qui cherche pourquoi une telle ligne (mais pourquoi il fait $truc = $trac ici?), qui cherche à comprendre rapidement le code (les petits commentaires décrivant la macro fonction d'un groupe de code peut aider)... Bref, des commentaires permettant une lecture en diagonale du code.

Une remarque que m'a donné un professionnel : les commentaires ne sont pas maintenus. En pensant à ça, on réfléchit aux commentaires à mettre et ceux qui peuvent éventuellement être susceptible de changer avec le code...