[Coding style] Vos solutions pour un code lisible ?

[Ter Rowan]

et ben moi je vais mettre tout le monde d accord ^^


si pas de ' dans le texte je fais :

Code PHP :

<?php 

echo 'toto est '.$toto; 

[Argorate]

Je pense que toujours négliger tout c'est pas bon.

Négliger un gain de 6% c'est pas très sage.

imaginons (cas extreme):
Si tu créer un programme supposer lutter contre un virus de la mort qui va pirater l'armée et prendre le controle des silos nucléaires et que tu négliges des petites choses comme ça, la différence se fera peut etre sur le fait que ton programme sera plus rapide que le virus... ou pas!
C'est un exemple extreme je le sais bien, mais si on gagne 6% ici, et 2% sur une autre merdique chose de la sorte et encore quelque % ailleur... bin au final on gagne pas mal...

Enfin bon, chacun sa vision

[Zamentur]

Personnelement je sacrifie volontiers la rapidité et l'optimisation extrème contre l'évolutivité de mon programme.

Si mon jeu rame, je mettrais en œuvre un hébergement plus adapté. Mais au moins je ne perdrais pas de temps à faire évoluer quelques choses qui a évolué n'importe comment.
Il vaut mieux quoi un jeu qui coute un peu plus cher en hébergement, ou un jeu qui est arrêté car on ne peux plus le maintenir et répondre à sa propre demande et à celle de ses joueurs?

La lisibilité fait partit de l'évolutivité à mon sens.

Cependant cette histoire d'apostrophe ne se pose pas dans mon cas et quand elle se pose je fais comme Ter Rowan, ou alors je vais tout de suite chercher mes classe de gestion de texte.

[Argorate]

Normalement, si on code bien dès le départ, on n'a pas a "perdre du temps" a optimiser ces choses là après...
Je vois pas en quoi ce principe va contre l'évolutivité d'un programme? ce n'est pas necessairement incompatible.

[Sephi-Chan]

Si tu crois développer bien dès le départ, c'est que tu n'évolues pas. Si tu évolues, tu vas très rapidement avoir un œil très critique sur ton propre code. Or, faire du code peu lisible sous peine d'optimiser des conneries, c'est mauvais.

Si tu veux un vraie preuve de code peu évolutif, je peux te citer ton exemple sur Petite solution pour alléger le code de certains. C'est une catastrophe du point de vue de la maintenabilité et de l'évolutivité.

Une bonne solution, c'est d'utiliser une base de données : avec le coût des bâtiments dans la table bâtiments. Ce genre de table est quasiment statique puisqu'elle ne contient que les bâtiments existants.

Cette table est mise en cache dans un fichier un fichier (JSON, XML ou YAML) ou grâce à Memcached. Et tu y accèdes de manière totalement transparente en faisant toujours des :

@building = Building.find(3)

@user = current_user



# Ah ben rien ne change, tout est encapsulé dans le modèle User !

if @user.has_enought_resources_for?(@building)

  # ...

else

  # ...

end

C'est bien plus simple, élégant, maintenable, évolutif, etc. Et c'est là que les frameworks entrent en jeu : ils te permettent de faire tout ça de manière transparente, de changer très simplement de technique de cache, etc. Et même sans framework, seulement en jouant un peu avec l'orienté objet et l'abstraction, tu ferais déjà un pas en avant.

Ton problème, c'est vraiment de ne croire qu'en toi, alors que quand je lis le post cité plus haut, le débat sur les exceptions, etc. je me dis que tu progresserais si tu écoutais les autres.

Enfin bref, faut évoluer un peu, comme un petit Pokémon !


Sephi-Chan

[naholyr]

Heu, c'est loin d'être 6% ce qu'on gagne avec le changement de quotes... On gagne encore plus
Mais ça n'a aucun intérêt, parce que ce n'est jamais les "echo" le goulot d'étranglement.

Tiens, j'ai trouvé ça sur dvp :

Source: http://blog.developpez.com/julienpauli/p...s-et-autr/

Wahou ! plus de 50% de gagné ? Enooooorme. Ouais sauf que ça me fait gagner 18 ms sur 10'000 echo... Dans une appli si on en a 200 ou 300 c'est déjà le bout du monde. Sur une grosse page qui met 250 ms à se charger, avec ses 300 echo on pourra passer de 0.1 ms à 0.05 ms, soit un gain de 0.05 ms. Un gain de 0.05 sur 250 ça fait 0.02% d'amélioration globale.
Oui, ce gain de 50% sur les echo est absolument négligeable, et donc inutile.


Optimisez les index de vos requêtes, le stockage des sessions (essayez de les stocker dans une table MEMORY, ou encore mieux en mémoire avec memcached), etc... Là on a des vrais goulots d'étranglement qui valent le cout de gagner 10%, 20%... Gagner même 75% sur les "echo", ça n'a aucun intérêt.


[edit]On me répondra "oui peut-être que l'amélioration globale est
négligeable, mais cette optimisation est gratuite". Oui est elle est gratuite tant que tout le monde dans l'équipe trouve que l'un comme l'autres sont aussi lisibles. Sinon c'est un coût en confort pour un gain négligeable.[/edit]

[Findel]

Je pense que vous vous emballez pour pas grand chose, dans le fond choisir telle ou telle convention n'engage que vous et votre équipe, ne cherchez pas à convaincre à tout prix ceux qui ne sont pas d'emblée d'accord avec vous. Je ne crois pas qu'il y ait de solution universelle.

Concernant les échos, je ne peux m'empecher de rebondir : a mon avis vous ne vous posez pas la bonne question. Quand on écrit du code, il faut surtout se demander ce que cela signifie. Voir ce que cela va générer comme tâches lorsque ce code sera executé. Le but étant de donner le moins de travail inutile au serveur, tout en restant lisible pour maintenance je l'accorde. Je vais illustrer cela en piochant dans vos exemples :


echo 'Moi j\'aime le '.$food.' !';
Signifie :
- concatèner la constante 'Moi j\'aime le ' avec le contenu de la variable $food
- concatèner dans cette zone mémoire la constante ' !'
- renvoyer le résultat vers la sortie standard

Ce qui pèche dans cette instruction est donc les deux concaténations inutiles.

echo "Moi j'aime le {$food} !";
Signifie :
- Analyser la chaine pour remplacement éventuel de variables
- Remplacer la variable $food par son contenu
- renvoyer cette zone mémoire vers la sortie standard

Ce qui pèche dans cette instruction est le temps perdu à l'analyse de la chaine de caractère et l'opération de remplacement inutile.

echo 'Moi j\'aime le ', $food, ' !';
Signifiant :
- Envoyer la constante 'Moi j\'aime le ' vers la sortie standard
- Envoyer ensuite le contenu de la variable $food
- Envoyer ensuite la constante ' !'

Aucune opération de concaténation, ni analyse de chaine superflue. pas d'utilisation de mémoire (à moins bien sur d'avoir activé ob_start, mais c'est une autre histoire)

Les gains de quelques milisecondes peuvent vous paraître dérisoires, mais si on se souvient que le serveur traite des tonnes de pages en parallèle (encore plus vrai sur un hébergement mutualisé ou un virtualisé) si chacune est un poil plus optimisé au final ça peut faire une grosse différence.

Concernant le côté lisible, il me semble difficile de trancher de manière objective entre les trois écritures. En général je préfère les simple quote que les guillemets pour la simple raison que vu que ça ne change pas grand chose à la lecture et que ça change beaucoup dans le travail demandé au serveur...

[wild-D]

c'est un peu en marge du débat^^
mais dans le domaine de la maintenabilité et de l'évolutivité; je suis pas sûr que le tout en un s'impose (ie tout peut/doit être fait uniquement à l'intérieur de l'interface du jeu/admin).

@sephi, puisque tu remets l'ex d'arogate sur le tapis ici; y a un truc qui me laisse perplexe: tu fais l'équilibrage dans ta base de donnée ?
me semble que y a d'autre outils plus adapté (tableur, logiciel statistique).

à partir de là tu peux tout autant exporter en csv pour une base de donnée si tu veux donner un accès permettant des requête en lecture (quoi que à ce qui parait R peut travailler directement avec une bdd, mais jamais testé); voir directement lire depuis une feuille de tableur. Quitte à stocker un cache plus rapide sous yaml, ou en memcach.

Ce serait pour un éditeur de quête ou autre élément ou on veut privilégié le travail communautaire en ligne ou dans le cas d'un système dont ces données de bases sont dynamiques alors oui.
Mais sur ce coup là les données de bases servant à l'équilibrage du jeu statique, je rejoins arogate: la bdd ne me paraît pas la solution la plus pertinente. (pourquoi développer des outils dont on a pas besoin car existant en bien mieux ailleurs. -bon avec un framework et du scaffolding y a pas automatiquement bcp à développer - )

+1 findel
si il s'agit d'un echo direct, j'essaie d'utiliser la 3e. La motivation est que le code fait ce que je veux qu'il fasse est juste ça. (j'utilise aussi bcp dans les "templates" ?>mon texte <?php echo $texte;?> )
Pour la compréhension du code, je considère que la lisibilité absolue d'une chaine de caractère est pas le plus primordial; C'est de comprendre que le programme va afficher un contenu qui prime, et accessoirement de facilement repérer les variables utilisées (ce qui dans mon esprit incombe à la coloration syntaxique avant tout).

[Sephi-Chan]

Ouais bon, pour le coup de la concaténation, c'était juste pour montrer la lisibilité d'une notation avec point (ou virgule).

echo 'Moi j\'aime le ',$food,' !';
echo 'Moi j\'aime le '.$food.' !';
echo "Moi j'aime le {$food} !";

Concernant l'exemple d'Argorate, l'idée est d'abstraire la source de données pour la manipuler comme bon nous semble.


Sephi-Chan

[Fnor]

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.