Discussion :

[Lucas Brazi]

Un bon code est un code qui est comprehensible et maintenable par un tiers.

Si des ecarts sont fait ou le code est trop complexe, trois mots : commenter, commenter, commenter !

Si la maintenance ne peut pas etre faite par un tiers : réécriture.

Normalement, un semblant d'architecture doit preceder le code meme pour les petits projets : le fait de realiser un petit diagramme de sequence aide a attribuer des roles aux classes et le code qui en decoule est plus simple à comprendre. Et ca peut aussi servir a documenter .

[el_slapper]

Un bon code est un code qui est comprehensible et maintenable par un tiers.

Si des ecarts sont fait ou le code est trop complexe, trois mots : commenter, commenter, commenter !

Si la maintenance ne peut pas etre faite par un tiers : réécriture.

Normalement, un semblant d'architecture doit preceder le code meme pour les petits projets : le fait de realiser un petit diagramme de sequence aide a attribuer des roles aux classes et le code qui en decoule est plus simple à comprendre. Et ca peut aussi servir a documenter .

Pas totalement d'accord. Le commentaire abondant ne doit pas masquer l'illisibilité du code. Le commentaire doit servir, à mon sens, à expliquer le "quoi", pas le comment.
*Si j'ai un pavé qui me dit "lecture des données client" et que je cherche un bug sur la date paramètre, je sais que je peux sauter. C'est un commentaire utile.
*Si le pavé me dit aussi "Appel de la base X"(juste avant un call X), "traitement du client non trouvé" (avant un IF X-CLIENT-NON-TROUVE), "remplissage du type CLIENT" (avant d'alimenter la donnée TYPE-CLIENT), c'est du bruit.

Et si le code ne me permet pas de déterminer que j'alimente le type client, c'est qu'il est mal écrit. ça n'est pas au commentaire de se substituer. C'est au code d'être lisible. Seuls des cas rarissimes peuvent justifier de décrire le "comment" dans un commentaire, généralement quand on a pas trouvé de moyen "propre" de faire(3 fois en 10 ans en ce qui me concerne). C'est un dernier recours, pas un systématique.

[Gluups]

Il m'est arrivé de suivre le cheminement inverse.
A la relecture, je dois préciser que je veux dire inverse de ce que décrit Sara, et que je suis sur la même ligne que Lucas, ci-dessus.

J'ai été appelé pour améliorer le fonctionnement d'un code, j'ai commencé par passer trois jours à comprendre comment ça fonctionne, en me disant "voyons voir, comment ça marche ce truc, et qu'est-ce que ça doit faire ?"

Et c'est une fois que j'ai décortiqué tout ça que j'ai compris que la personne qui avait codé ça n'avait pas connaissance de la notion de fonction, et pour cette raison faisait des goto systématiquement vers le même point en faisant ensuite des tests sur un compteur.

Le seul contexte où je me vois coder comme ça est en prévision de confier le programme à "obfuscateur", pour avoir le maximum de certitude (vous noterez que je n'ai pas dit une certitude absolue) que personne sur terre, même pas moi, n'ait une chance de comprendre comment fonctionne ce truc en voyant le résultat de la décompilation -il est vrai que dans ce cas je pousserais vraisemblablement le bouchon plus loin.

Le fait est qu'une fois le code réécrit avec dix lignes au lieu de cent dans le module principal, et en appelant des fonctions aux noms explicites, l'utilisatrice était capable de modifier le résultat à la demande en fonction des évolutions des règles métier.

Bon alors ce n'est pas pour gonfler les chevilles : j'ai appris, lui pas.

[Gluups]

Au demeurant, je dois confesser qu'il m'est arrivé, par surmenage, de faire du mauvais boulot, de ne pas avoir le temps d'écrire en tête de chaque module les infos standard telles que qui qu'a fait ça, quand, pour quoi faire ...
Les règles étaient bonnes, mais je ne les ai pas appliquées, alors le résultat était mauvais.
Peut-être suis-je mal placé pour demander si le stress induit par le client était ou pas du bon boulot, et permettait ou pas de prendre le temps de sortir un code propre et bien commenté.

[mlezzoum]

Un développeur est :
soit chevronné - professionnel
soit initié
soit débutant

Etre chevronné professionnel et porter un jugement de valeur sur un développeur
débutant c'est une remise en cause du chevronné lui même.

Etre débutant et porter un avis négatif sur le code d'un chevronné, c'est un long parcours qui lui reste à faire le débutant, surement il changera de métier au cours de route.

Etre initié c'est regarder au dessus le chevronné avec un respect de l’élève qui apprend, et présenter un sagesse en baissant le regard pour voir les premiers pas du débutant.

Le secret de l'expert est de garder le silence et aider les autres et par modestie l'expert est désigné par la troisième personne du singulier.

que delphi soit avec vous. ( mes respects pour delphiprog au passage)

[akiniva]

Personnellement non. Je me dis toujours qu'un code peut-toujours être améliorer mais le code parfait n'existe pas, et puis il y a tellement de manière de coder qu'on ne peut être objectif en regardant un code éditer d'une manière différente !

[fredop]

Comment faites-vous pour protéger votre réputation en livrant vos sources ?

Si vous travaillez sur un projet avec plusieurs personnes, je ne connais que deux solutions :
1-vous surveillez votre code en surveillant à chaque commit contre :
a-les modifications des autres
b-vos propres modifications! (effet de bord...)
2-vous designer des tests unitaires qui agissent comme un contrat de vos spécifications (le bouclier de SHuryu pour les intimes ) lancés automatiquement à chaque build. Le 1er qui casse le contrat à le droit à:
a-un email l'avertissant
b-un message jabber avec Build Failed (merci hudson!) au méchant et à tous les autres de l'équipe si nécessaire

Sinon vos faites comme de nombreuses personnes (ingénieur informatique compris) qui trouve que cela
- ne sert à rien les tests automatisés(normal au début le projet est tout simple)
- les tests c'est pas pour les super codeurs que vous êtes
.. jusqu'au jour où soit:
1-une grosse refonte est demandé et vous craignez de casser toucher du code d'un autre (qui n'est plus là bien sur) et craignez le syndrome de la patate chaude (si !! vous savez la fameuse règle implicite qui dit que "quiconque touche et commit un code, ce dernier devient le sien")
2- un bug est trouvé en prod. 3mois plus tard et qu'il faut 2 jours pour le débugger car aucun test n'a été fait pour bloquer la fonctionnalité et que cela aurait pu être trouvé avant en 10 minutes.

Et là la MOA tape sur la table, le chef de projet aussi & là il décide qu'il faudrait des tests unitaires mais le projet est devenu une hydre (chaque bug trouvé en révèle un autre) et certains auteurs du code ont disparu avec les spécifications dans leurs têtes (normal la documentation fonctionnelle ça ne sert à rien pensiez vous au début).

Alors a chaque itération vous avez le droit à une semaine de tests manuels ( Super vous refaites parfois les mêmes tests à chaque livraison, bonjour l'ennui !)

Ensuite bonne chance pour savoir qui a fait le bug :
-si la personne est un brin bourrin, elle va accusé l'auteur du code alors que ce n'est pas forcément vrai.


Et du haut de ma faible expérience, je ne vous dis pas le nombre de fois que
j'ai évité que quelqu'un brise mon code. Je ne compte plus. Et je défies quiconque de lancer environ 1200 tests manuels tous les jours (nombre moyen de tests automatiques lancés chaque jour sur un projet d'un 6 mois) sauf si vous avez une armée de testeurs en inde...


Par ailleurs, je recommande à tous la lecture du livre "clean code" appelé en français "coder proprement". Il est parfois extrémiste mais c'est l'un de ces livres qui sera toujours d'actualité même dans 10 ans sur l'art de la poésie technologique (comprenez la programmation)

[bifur]

je pense qu'il est impossible de faire un code qui soit facilement compréhensible par autrui (en tout cas j'en suis incapable) a moins de faire un tas de commentaire dans la source

j'essaye de décrire le plus précisément chaque mini procédure ou fonction avec les registres uttilisé, ainsi que les variable. c'est le minimum lorsque que l'on veut pouvoir reprend un programme abandonner depuis quelques mois (et je ne parle même pas de travailler en équipe)

je ne juge pas trop les codes des autres, je considère que mes programme sont toujours améliorable, qu'il faut toujours reécrire un bout ou rajouter une fonction. il me faut minimum 3 version avant de considéré un programme comme aboutit

l'important c'est que le programme fonctionne, vite et bien

[mayeulak]

j'ai longtemps crus que j'étais fou à ne pas aimer le travail des autres développeurs que je trouve la plus part du temps médiocre ^^.
non mais, parfois on ne support plus les indentations mal appliquées de ses collègues :-D. alors allez savoir s'il s'agissait d'une erreur dans le code lui même hahaha. ça va chier!

merci de m'avoir rassurer que tout va bien

[duboisa]

je suis assez s'accord avec _skip
c'est vrai qu'un code écrit par un débutant peut être difficile à lire (et à valider) idem par un débutant + 2 (qui essaie de factoriser à mort)
mais avec l'expérience on reconnait le genre d'auteur, et on s'adapte.
la revue de code est un exercice.

[atc666]

quand je lit vos commentaires je me dit que pour vous la chose la plus importante c est que ça soit facile a lire ...
donc si je vous comprend bien , si le code est lent et totalement dépourvu de toutes formes d optimisation , mais qu'il est facile a lire et simple a comprendre c est top ?
j ai vu parmi vos commentaires quelqu’un qui écrit que si il trouve un code qui est top rapide mais difficile a comprendre , elle le jetterai a la tête de celui qui l as "pondu" ... mais pourquoi ne pas au contraire justement faire l'effort de comprendre ce code et d en tirer des leçons pour améliorer la vitesse de son propre code ?
je pense que beaucoup se place uniquement de leur point de vue et jamais de celui du client.
le code "spaghetti" je comprend qu on aime pas ca car c est rarement rapide comme code voir meme je pense jamais

[ymoreau]

C'est un vaste débat que tu ouvres, mais je dirais que dans l'opinion générale le cout de développement est bien plus cher que le cout d'exécution. Avec les machines qu'on a de nos jours les optimisations au niveau code (et pas au niveau architecture ou conception) sont, je pense, négligeables en gain d'exécution. Alors que la compréhension du code peut faire gagner beaucoup temps pour ceux qui devront le faire évoluer, et ce temps là coute cher (au client aussi d'ailleurs).

[Klaim]

L'explication requiert en fait un peu plus de bon sens basé sur l'expérience et des faits :

- un code facile à comprendre est plus facile à modifier parcequ'on comprends l'intention et donc on peut l'ajuster en maintenant cette intention;
- un code difficile à lire est source de problèmes parcequ'on ne comprends pas facilement l'intention, ce qui est rééllement voulu;
- par conséquent, il est plus facile d'avoir un code lisible au départ et de le rendre illisible pour régler des soucis de performance, si il y en a;
- de plus, la lisibilité du code n'est pas forcément lié à la rapidité de celui-ci : il y a des tas d'exemples de code qui sont plus rapide quand ils sont écrit simplement, parceque comme ils sont plus facile à lire aussi pour le compilateur ou l'interpreteur, il devient plus facile à optimiser (parceque connaitre les intention permet de déterminer ce qu'on considère comme acquis, les invariants).

Donc en gros, l'idée c'est de toujours écrire le plus lisiblement possible, en pensant au mec (qui peut être soit-même) qui reviendra sur ce code dans 3 mois et qui ne saura rien dessus. (Oui, vous aurez oublié).

Comme ça, il aura de meilleures chances de modifer le code dans le bon sens, de rendre potentiellement le code plus performant si c'est le but de la modification.

Et enfin, ceux qui rejettent le code pas clair même si plus performant ont raison sauf si la performance est requise pour le code en question. Cela dit, je n'ai jamais vu de code très performant qui ne pouvait pas être un peu plus clair que sa version "brute". Ya toujours moyen de rendrre plus clair sans changer les instructions finales. Seulement ça requiert certainement plus d'expérience.

[Paul TOTH]

quand je lit vos commentaires je me dit que pour vous la chose la plus importante c est que ça soit facile a lire ...
donc si je vous comprend bien , si le code est lent et totalement dépourvu de toutes formes d optimisation , mais qu'il est facile a lire et simple a comprendre c est top ?
j ai vu parmi vos commentaires quelqu’un qui écrit que si il trouve un code qui est top rapide mais difficile a comprendre , elle le jetterai a la tête de celui qui l as "pondu" ... mais pourquoi ne pas au contraire justement faire l'effort de comprendre ce code et d en tirer des leçons pour améliorer la vitesse de son propre code ?
je pense que beaucoup se place uniquement de leur point de vue et jamais de celui du client.
le code "spaghetti" je comprend qu on aime pas ca car c est rarement rapide comme code voir meme je pense jamais

tout dépend du contexte, si c'est pour gagner 1/2 seconde sur une appli de gestion dont la force est dans la gestion de données techniques particulièrement complexes, oui il faut jeter le code ultra optimisé qui rend les choses incompréhensibles.

maintenant si le temps de réaction de l'application est critique, effectivement on sacrifiera la lisibilité pour gagner les précieuses millisecondes dont on a besoin.

mais dans 90% des cas c'est l'algorithme et les hypothèses de départ qui sont à revoir, pas les lignes de code.

[SirDarken]

Pour ma part, je suis toujours entrain de raler sur le code que j'ai moi même pondu.

Ca fait deux ans que je code, et pourtant chaque jour j'apprend des trucs, donc je suis plutot cool face au code de mes confrères/consoeurs même si il m'arrive de m'arracher les cheveux à reprendre le code.

[Klaim]

Des tas de gens avec 10 ou 20 ans d'experience disent pareil. On finiras pas d'apprendre dans ce métier (et quelque part, tant mieu).

[zaventem]

quand je lit vos commentaires je me dit que pour vous la chose la plus importante c est que ça soit facile a lire ...

Ce qui compte, c'est qu'il soit le plus facile à lire possible.

donc si je vous comprend bien , si le code est lent et totalement dépourvu de toutes formes d optimisation , mais qu'il est facile a lire et simple a comprendre c est top ?

Étrangement, tous les codes lents et non-optimisés que j'ai vu étaient tout sauf clairs, structurés et faciles à comprendre. Les codes faciles à comprendre sont (en règle générale) issus d'une vraie réflexion sur les algorithmes utilisés, sur une bonne compréhension de la problématique et lorsqu'un passage plus tricky est nécessaire des quelques mots de commentaires qui disent ce que fait le code et pourquoi.