Discussion :

[landry161]

Facile : c'est du code que j'ai écrit, bien sûr . Pour tout développeur qui se respecte, le code des autres est toujours mauvais

Hum je connais des mecs comme ça

Pour ce qui est des commentaires, je ne pense pas qu'ils soient indispensables en règle générale. Un bon code est généralement compréhensible juste en le lisant

Tout à fait mais bon juste pour la forme moi je commente quand même.

[Moubarak Zoure]

Un bon code doit lui même dire ce qu'il fait .

[gabriel.klein]

Un bon code répond avant tout aux besoins de l’utilisateur Il répond aux désirs de l’utilisateur.

Du "quick and dirty" est acceptable dans certains cas! Par exemple pour tester un concept avant de le construire. Parfois c'est totalement pas acceptable - par exemple si on doit contrôler un avion.

Personnellement j'ai plusieurs niveaux de "maturité" dans mes projets - certaines parties du projet sont testées, d'autres faites pour être rapidement remplacées - et c'est comme ça que je gère un bon code.

Certaines parties ne sont pas encore bien définies par l’utilisateur - donc c'est plutôt du "quick and dirty" au niveau qualité. Pouvoir "jouer avec l'application" permet aux utilisateurs de mieux définir ce qu'ils veulent.

[el_slapper]

(.../...)
Tout à fait mais bon juste pour la forme moi je commente quand même.

Tiens, quelqu'un a mis -1 à cela? Tant pis, je prends le risque, mais moi j'ai mis +1 :

(1) un bon code doit être compréhensible sans commentaire
(2) une fois qu'il est compréhensible sans commentaire, on commente quand même. Pour que la relecture et la recherche d'informations soient encore plus efficaces.

[landry161]

Tiens, quelqu'un a mis -1 à cela? Tant pis, je prends le risque, mais moi j'ai mis +1 :

[ustensile]

C'est juste une question de point de vue, pour certaines personnes, un bon code:

- doit être assez complexe pour que le client ne puisse pas le modifier seul
- ne doit évidement pas être commenté, ce serait trop facile (on peut aussi commenter avec des conneries)
- ne doit fonctionner que dans les cas généraux de base décrits par le cahier des charges
- doit fonctionner un minimum au moment de la recette
- ne doit pas forcément être compatible en cas d'upgrade
- doit pourvoir faire l'objet d'un devis pour modification à tout moment
- doit permettre de tester le niveau des stagiaires ou des nouveaux arrivants
- permet de repérer les bons commerciaux

[MikeRowSoft]

Comme il n'y a pas de "standard" pour le déroulement de même algorithme ou de tâches ayant les mêmes caractéristiques il y en a pas de vraiment très bon et très optimisé. Rien qu'a se pencher sur l'étape analyse syntaxique et grammaticale permet de mettre en évidence les multiples redondances qui par la suite finissent par disparaître au linkage si se linker est optimisé pour cela.

[Guikingone]

Pour moi un bon code est une code simple, précis et facile à maintenir, les commentaires passent au second plan.

Le développeur qui me fera maintenir un code illisible n'est pas né (et je doute qu'il voit le jour), sa fonction doit être précise et être comprise sans détour, les commentaires ne sont qu'un "bonus" pour ceux qui veulent plus de détails sur tel ou tel choix.

J'ai déjà vu des codes illisibles qui frôlait la mauvaise foi et à chaque fois, j'ai du reprendre le boulot au départ, à la source de la création, travail au combien fastidieux et inutiles si le code avait été correctement construit.

Au fond, chacun dira que son code est le meilleur et que le reste ne vaut rien, je dirais juste qu'il n'en est rien et que ceux qui se vantent de pondre un code parfait du premier coup sont des crétins.

[Laurent 1973]

Au fond, chacun dira que son code est le meilleur et que le reste ne vaut rien, je dirais juste qu'il n'en est rien et que ceux qui se vantent de pondre un code parfait du premier coup sont des crétins.

Oui, restons très humble et mettons notre orgueil au placard en se qui concerne notre travail de développement: tout le monde est capable de créer un future "legacy code"
On a tous à apprendre des uns des autres, et surtout le nez dans le guidon, on a beaucoup de mal à voir du "code qui pue".
La revue de code est bien pour cela.

[landry161]

Tu confonds "mode" et évolution technologique
Le javascript a énormément évolué au cours des années et il est devenu très performant avec des framework qui permettent de mettre en place une interactivité en temps réel sur les sites web
Cela apporte un vrai plus qu'une gestion par validation de formulaire ne permet pas
De plus, le HTML5 a fini par normaliser et généraliser un peu tout ça

[Nebulix]

Il y a si peu de gens qui pensent que la première qualité d'un code c'est de faire ce qu'il est censé faire ?
La seconde qualité est tout aussi évidente : être assez abscons pour inspirer une sainte terreur au lecteur moyen et ne pouvoir être maintenu que par des surhommes, de préférence bien payés.

[Nebulix]

je donne un exemple simple de test unitaire automatisé dans le transport :[/U]

- Si on fait un trajet Aller-retour, alors le tarif doit être supérieur à un trajet simple.

Le jour où j'ai eu besoin d'un aller simple (Turin-Paris sur Air France), le vendeur m'a expliqué : je vous mets un aller-retour, c'est moins cher !
Récemment les codeurs financiers ont du revoir leurs logiciels en catastrophe pour tenir compte des taux d'intérêts négatifs. La "rationalité' du monde réel n'est pas toujours mathématique.

[Demi Humain]

Bonjour,

Si les principaux critères restent identiques lisibilité, fonctionnel, maintenable, réutilisable, testé et documenté, leur importance peut varier entre un programmeur cobol et un programmeur java.

Je veux dire que la qualité du code va dépendre de l'environnement de développement, c'est à dire des méthodes mises en place, souvent appelées normes de développement.

Par exemple, dans le développement en cobol, on peut voir des programmeurs mettre 50% de lignes de commentaires dans le nombre de lignes écrites dans un programme cobol (cette règle permettait à un non informaticien de pouvoir comprendre le programme : test exigé par certaines normes de développement comme chez IBM, Cap Gemini,...).

Par contre pour un programmeur Java, cela parait incompréhensible d'aller mélanger les commentaires au milieu du code car les commentaires se mettent devant les méthodes (d"ailleurs Eclipse le propose en standard).

On voit bien ici un exemple de normes de développement différentes.

[MABROUKI]

bonjour

TaReumSuceDesBots
Standard, dans le sens où il s'agit de se créer une culture sur le framework sur lequel vous bossez, car dans la pratique beaucoup de choses existent et ne demandent qu'a être utilisés. Le gros problème d'aujourd'hui, à mon avis, c'est le manque de maîtrise des IT vis-à-vis des framework sur lesquels ils bossent

Je suis de ton avis...Le diable est dans les details du Framework avec lequel nous travaillons (l'outil) qu'il faut bien connaitre sinon on recode des choses qui existent deja ou que le Framework n'as pas prevu de prendre en charge ce qui est un contre-sens...
En general comme disait C.Petzold quand on se retrouve à ecrire beaucoup de code pour resoudre un probleme c'est qu'on a fait fausse route...
Pour moi aussi ,un code doit etre clair c.à.d comprehensible dans le cadre du language ou il est ecrit et le framework utilise...
Quant à l'efficacite,cela suppose que le code resout au moins le probleme pour lequel il a ete ecrit sans plus...

[Matthieu Vergne]

Juste pour ceux qui, comme moi, on tendance à lire "code fonctionnel" comme "code qui fonctionne".

Je pense qu'on parle de "fonctionnel" dans le sens qu'il représente explicitement les fonctions qu'il est censé assurer. Par exemple, un code générique se focalise sur les actions à effectuer (e.g. trouver le max d'une fonction), indépendamment de leur contexte (e.g. gestion de budget). Il n'introduit donc aucun concept propre au domaine d'application (e.g. coûts, bénéfices), et n'est donc pas fonctionnel (contrairement à un code qui parle de maximiser des bénéfices). Si un tel code générique devait être utilisé, il faudrait donc qu'il soit utilisé comme une lib (de préférence remplaçable) placée derrière une API qui remplace les concepts génériques (e.g. fonction) par des concepts spécifiques au domaine considéré (e.g. bénéfices) de manière à avoir quelque chose de "fonctionnel" (et non simplement qui "fonctionne").

[Invité]

Je ne sais pas si tous les compilateurs l’acceptent, mais personnellement j’utilise les MAJUSCULES pour les INSTRUCTIONS et les minuscules pour les données. Ce n’est pas grand-chose mais cela apporte un peu de relief et je lis mieux mon code. Évidemment, toutes les données que je manipule sont préfixées. Petit extrait d’un programme d’édition sous Informix :

Code :

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

1
2
3
4
5
6
7
8
9
IF sf_d_debut IS NOT NULL
     THEN LET v_today = sf_d_debut
     ELSE LET v_today = dl_d_debut
…/…

IF DAY(v_today) = 1
THEN PRINT "1er ", v_mois CLIPPED, 1 SPACE, YEAR(v_today) USING "####"
ELSE PRINT DAY(v_today)  USING "<< ", v_mois CLIPPED, 1 SPACE,
           YEAR(v_today) USING "####"

J’exploite également les caractères début/fin de commentaire, pas forcément pour commenter mais pour structurer visuellement, pour habiller le programme afin de le rendre le plus lisible et le plus compréhensible possible. Je parle de structure d’accueil, de canevas, de squelette ou encore de skin.

Lorsque je m’initie à un nouveau langage, il me faut bien deux mois de développement pour créer et affiner mon environnement de développement. Je ne pense pas que cette démarche soit enseignée, en tout cas elle ne l’était pas dans les années 80.

Petit extrait :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
{================================}  DEFINE  {==================================}
{}                                                                            {}
{}    PARAM[1] p_c_bdd         CHAR(1)      { [A]dministratif                }{}
{}                                          { [E]nseignant                   }{}
{}                                                                            {}
{}    PARAM[2] p_selection     CHAR(1)      { [S]ans e-mail                  }{}
{}                                          { [A]vec e-mail                  }{}
{}                                          { [T]out (sans et avec e-mail)   }{}
{}                                                                            {}
{}    VARIABLE v_today         DATE                                           {}
{}                                                                            {}
{==================================}  END  {===================================}

La clause DEFINE participe au commentaire du programme. Pas besoin d’en rajouter. Même principe pour toutes les clauses.

Ma démarche peut sembler contraignante mais les éditeurs de texte sont suffisamment performants pour limiter la saisie. Tous mes programmes ont vécu entre 15 et 20 ans. Je relis mes programmes écrits il y a 40 ans comme si je venais de les écrire. L'extrait ci-dessus vient d'un programme écrit en 1991.

Côté commentaires, j’ai gardé l’habitude COBOL « IDENTIFICATION DIVISION » :

- Programme
- Shell
- Auteur
- Objet
- Date

En fin de programme, j’ajoute le shell en commentaire. Il me sert de sauvegarde car j’ai le Delete/Remove un peu trop facile.

Dans les programmes écrits par d'autres développeurs, j'espère toujours découvrir un fil conducteur, un style, une démarche, une réflexion, une grammaire, une personnalité. J'aime me faire surprendre, apprendre quelque chose que je puisse m'approprier.

Dans les années 70, PAC700 m'avait surpris avec ses zones libellés et structures. Je me suis immédiatement approprié le concept.

… C’était pour apporter un peu de concret dans cette discussion.

[yahiko]

Ah ! Le troll débat sur la typographie !

* Les majuscules pour les mots-clés :

Tous les langages ne le permettent pas (case sensitive). D'ailleurs, la plupart des langages dominants (C, Java, C#, JavaScript, Python, Perl, Ruby, Haskell, et j'en passe...) ne permettent pas cette liberté.
Je ne vois que les langages du style Basic (VB principalement) ou bien Fortran ou Cobol qui permettent de mettre en majuscule les mots-clés. Vraiment une minorité parmi les développeurs (sans sous-entendu péjoratif à leur encontre bien entendu).
Et même si c'est possible en VB, Fortran ou Cobol, compte-tenu du fait qu'un programmeur tiers a de grandes chances d'avoir été habitué à la syntaxe des langages dominants, il est préférable de rester sur des mots-clés en minuscule. C'est le principe du moindre étonnement.

L'usage dominant est de mettre en majuscule en toute lettre les constantes.

* L'habillage du programme via les commentaires :

Il existe plus ou moins une norme de facto dans ce domaine qui est le format JavaDoc et ses variantes.
Ce style est relativement répandu, structure les commentaires, et permet de plus la génération de la documentation (en HTML par exemple) via un outil externe comme Doxygen.

Je ne pense donc pas qu'il soit nécessaire de gaspiller un mois de temps de développeur pour concevoir un environnement de développement à chaque nouveau langage appris.

[welcome_59]

Pour moi un bon code est un code qui est conforme à son cahier des charges, c'est à dire qui:

1. produit les résultats qui en sont attendus et
2. respecte les contraintes qui lui sont imposées (standards de développement, exigences du mandant, etc.).

Ces critères peuvent varier de façon considérable d'un environnement à un autre (Maîtrise d'ouvrage et maîtrise d'oeuvre incluses).

Mon chef actuel, développeur tout aussi "senior", pense que la maintenabilité, la ré-utilisabilité et autres ne sont que de (je cite) "gros mots". Seule la couverture fonctionnelle compte et tant pis pour les effets de bord et (je cite encore) "le jour où nous aurons besoin de le ré-utiliser, nous nous re-pencherons dessus". Mon chef précédent avait le point de vue contraire. Comme quoi ...

Face à du code on s'en fait une opinion qui dépend de nos critères propres, qui eux-mêmes sont très variables d'un environnement à un autre.

[Matthieu Vergne]

Et tu fais comment quand ton cahier des charges ne te dis pas quoi faire ? Il y a 1001 façon interpréter un cahier des charges si celui-ci n'est pas "bon", et il n'a pas vocation à te donner les détails de codage suffisant pour n'avoir qu'à appliquer. Sinon ça fait déjà longtemps qu'on aurait automatisé le codage depuis le cahier des charges.

Ceux qui disent qu'un bon code n'est que le respect du cahier des charges, pour moi, ne cherchent pas à faire un bon code, mais à déléguer leur responsabilité au rédacteur du cahier : "j'ai respecté le CdC, donc si c'est pas bon c'est pas ma faute, c'est le CdC qui a été mal fait.".

[welcome_59]

Et tu fais comment quand ton cahier des charges ne te dis pas quoi faire ?

Premièrement je ne trouve pas beaucoup de raisons de coder (en environnement professionnel) sans "cahier des charges". J'entends par cahier des charges, une description de ce qui est attendu de toi, sur les plans fonctionnel, technique ou autre, par celui qui te mandate pour faire ce code. On peut remplacer le terme "cahier des charges" par celui que l'on veut, cela n'y change fondamentalement rien. J'ai du mal à imaginer qu'un développeur fasse du code sans qu'il lui ait été demandé quoi que ce soit, plus ou moins clairement. Et si le "cahier des charges" ne dit pas, même de manière imprécise et incomplète, quoi (et parfois comment) faire alors il n' y a tout simplement rien à faire, donc pas de code.

Il y a 1001 façon interpréter un cahier des charges si celui-ci n'est pas "bon", et il n'a pas vocation à te donner les détails de codage suffisant pour n'avoir qu'à appliquer. Sinon ça fait déjà longtemps qu'on aurait automatisé le codage depuis le cahier des charges.

Et il y a tout autant de façon d'interpréter l'expression "bon code".
C'est vrai que le cahier des charges n'a pas vocation à te donner les détails de codage suffisant pour n'avoir qu'à appliquer, mais il a vocation à t'en donner suffisamment pour que tu saches ce qui est attendu de toi et avec le moins d'ambiguïté possible ou même sans ambiguïté. Comme je l'ai dit avant, le CdC du développeur (selon moi) ne se limite pas au document contractuel que son employeur a signé avec le client. Il inclut aussi toutes les règles et obligations que son donneur d'ordre direct lui impose (conventions de codage et autres). Ces règles n'automatisent bien entendu pas la production du code mais aident sans aucun doute à systématiser l'observation des critères de qualité que l'on s'est fixés.
Enfin si le cahier des charges au sens où je l'entends n'est pas "bon", alors le développeur utilisera alors des critères de qualité qui lui semblent pertinents et qui, bien entendu ne sont pas si universels que cela.

Ceux qui disent qu'un bon code n'est que le respect du cahier des charges, pour moi, ne cherchent pas à faire un bon code, mais à déléguer leur responsabilité au rédacteur du cahier : "j'ai respecté le CdC, donc si c'est pas bon c'est pas ma faute, c'est le CdC qui a été mal fait.".

Je partage aussi l'idée que le développeur doit assumer la responsabilité de la qualité de son code, mais toute la responsabilité ne peut pas toujours être attribuée au développeur.
Il arrive que le CdC (au sens où je l'entends) soit contraire à nos critères d'un bon code. Si le CdC exige de livrer une seule classe là où mes critères de "bon" code me dise d'en faire 5, alors je pense que je livrerais une seule classe. Et je n'ai pas pris un cas fictif en exemple. Le qualificatif "bon" appliqué au code ou à quoi que ce soit d'autre n'a de sens que par rapport à des critères défini. Chercher à faire du "bon" code, c'est chercher à faire du code qui respecte des critères. Mais qui fixe les critères sachant que ceux-ci ne sont pas universels? Pour moi la responsabilité du bon/mauvais code est très liée au contexte et donc pas automatiquement à imputer au développeur ou au mandant.

Tâchons de ne pas oublier que, souvent, pour les gens qui nous mandatent nos considérations de "bon" code sont très secondaires. Il peut arriver que nos critères de "bon" code résultent pour eux en facteurs de mauvais produit (plus difficile à exploiter, plus tardif, etc). Le produit appartient souvent au client/mandant et les critères de qualité qu'il a fixés ont plutôt tendance à primer les miens.