Discussion :

[befalimpertinent]

Bof. Je partage les scepticisme de certains sur ces règles, il y en a des plus importantes à mes yeux.

Au passage, je suis d'accord avec ceux qui pensent qu'un code bien écrit n'a pas besoin de commentaires (sauf pour l'Intellisense à la limite). Le problème des commentaires c'est qu'ils ne sont jamais maintenus (puisque non compilés ils sont zappés par la plupart des devs) et donc très souvent deviennent faux avec le temps. Des noms de variables et de fonctions parfaitement choisies ont un bien meilleur effet sur la qualité du code et souffrent moins de cet inconvénient.

R1: Inutile aussi. Ma règle en la matière c'est plutôt "ne doit être dans un fonction que ce qui est susceptible de d'être appeler plusieurs fois". Sinon le risque c'est de devoir embarquer tout le contexte à chaque fois et se retrouver avec des fonctions à 10 paramètres. Non merci.

R3: Pourquoi pas mais pas sur 6 mois. Ok pour n'utiliser que les bases au début, mais un débutant est quand même capable d'intégrer au fur et à mesure des spécificités plus avancées du langage.

Mes Règles d'or (entre autres):
Respecter une localité du code (la ligne courante doit être juste par simple contrôle des 10 lignes qui la précèdent et des 10 lignes qui suivent) , ne pas recycler des variables, s'interroger en permanence sur le coût mémoire et CPU de ces actions... J'en oublie

[olaxius]

Bonjour à tous ,
Toutes ces règles sont biens belles (voir utopistes), mais qd un jeune développeur rentre dans une boite , il doit PRODUIRE ! Il faut pisser du code très très vite car on attend de lui un truc qui marche. Peu importe comment ça marche !!!
Même si après on se fait C..R pour maintenir !
C'est certain si tout était commenté et documenté à bon escient ça serait le rêve !

[Guilp]

Tu penses cela en tant qu'étudiant mais tu changeras certainement d'avis une fois dans le monde professionnel si tu travailles dans une boite sérieuse au niveau développement

Au contraire, tout comme Ivelios, moi c'est à l'Université qu'on m'a appris ces règles de bases de programmation. Alors que dans le monde professionnel (les entreprises par où je suis passé), m'a démontré que ces règles n'étaient jamais utilisées... C'est même extrêmement difficile d'imposer ces règles de base quand la plupart des services informatiques des sociétés françaises (pour ne parler que de ce que je connais), ne prônent que la rustine dans un code lourd, mal conçu, mais "qui marche"...

Ah si je pouvais repartir de zéro dans mes projets professionnels, et ainsi vraiment appliquer ces règles apprises à l'Université... C'est beau de rêver!

----

Je rajouterais une règle : ne développer que ce qui est nécessaire et demandé. Jamais quelque chose "qui pourrait être utile plus tard".

[hegros]

Bonjour à tous ,
Toutes ces règles sont biens belles (voir utopistes), mais qd un jeune développeur rentre dans une boite , il doit PRODUIRE ! Il faut pisser du code très très vite car on attend de lui un truc qui marche. Peu importe comment ça marche !!!

Justement en suivant un certain nombre de règles il produira plus vite et surtout mieux. Il ne faut pas confondre vitesse et précipitation

[RomainVALERI]

Six, le débutant doit éviter l'abstrait, et toujours opter pour le concret.

Je crois que même si ça avait un sens, je ne serais pas d'accord.

Non, mais franchement quoi...
Attends moi aussi j'en ai des comme ça...

Un vrai programmeur doit programmer "lumineux" et pas "ténébreux".
Un vrai programmeur doit programmer "odorant" et pas "nauséabond".

Au bout d'un moment, ce genre de métaphore hyper large, c'est un peu trop.... abstrait, non ?

[Thorna]

@Bourgui : Essayes de maintenir du code qui a 36 ans d'âge(fait en 2008 sur du code de 1972 par moi-même), et tu comprendras à quoi ça sert, les commentaires. Surtout pas à dire comment marche le programme. Mais bel et bien à dire ce que fait tel morceau - ce qui permet de trouver ce que l'on cherche sans tout lire.
2 lignes avant un bloc qui dit "determination du type de courrier, TIP, Chèque, Virement ou autre; Techniquement, on ne peut pas afficher plus de 1M€ sur le TIP", ça m'aurait fait gagner une bonne semaine de boulot, parceque le code derrière était particulièrement complexe. Bon, peut-être moins si il avait été bien écrit, mais déjà j'aurais su à quoi ça faisait référence, et surtout pourquoi il y avait ce putain de 100000000 en dur dans le code.
Et non, une procédure qui s'appelle DeterminationTypeCourrierEntreTipChequeVirementAutreAvecLimiteA1MillionPourLesTips, désolé, mais non, je refuse(et puis en cobol on est limité à 32 caractères, mais même si j'en avais assez, je refuserais quand même).

On sent le vécu, parce que c'est exactement ça !
Et il n'y a pas besoin de remonter à du code écrit 30 ans plus tôt : dans les grosses boites, les équipes projet changent tous les ans ou tous les 2 ans et le code évolue pendant toute la vie de l'appli, soit de 2 à... 30 ans . Il y a toujours du vieux code à reprendre et si les noms de variables clairs et judicieusement choisis améliorent la lisibilité du code, ce qui intéresse en premier et avant tout, c'est la lisibilité du programme et de son organisation ! Deux commentaires négatifs pour cette réponse, c'est plutôt grave pour ceux qui font le boulot !

[Jerem1052]

Je vais être un peu extrême, mais pour moi la règle N° 1 serait plutôt de ne JAMAIS mettre de commentaires, sauf évidemment les commentaires style Javadoc par exemple pour des API publiques (et uniquement si nécessaire).

Le code doit se suffire à lui-même et être suffisamment expressif. Des commentaires, c'est quasiment du code en double, moins précis, envahissant, et qu'il faut maintenir en même temps que le code pour éviter qu'il ne "mente" et induise en erreur.

Les commentaires à l'intérieur d'une méthode/fonction pour expliquer des évidences ou des choses tordues qui auraient pu être mieux écrites sont un crime syntaxique et je pense qu'il faut absolument cesser d'enseigner cette pratique. Il vaut mieux appuyer au maximum sur le fait d'apporter du soin et de la clarté au code :
- nommage correct des variables, méthodes, classes etc,
- pas de mélange de niveaux d'abstraction dans une même méthode
- méthodes les plus courtes possibles, qui ne font qu'une seule "chose" et la font bien

Ça peut paraître utopique, mais avec ça la majorité des commentaires deviennent totalement inutiles.

[abriotde]

Il manque les commentaires très vital surtout quand on débute et que trois lignes sont difficiles à relire.

Et j’objecte qu'un débutant se doit de copier/coller un code d'un autre à une seul condition c'est que sa tâche première soit de le comprendre. Et d'une cela forme et évite des âneries. Et de deux cela permet de progresser.
Je m'explique. Prenons l'exemple d'un code C qui doit lire un fichier... Si un débutant s'embarque il va oublier de traiter les cas d'erreur de lecture et oublier de refermer le flux. S'il copie colle il devrait assez vite le comprendre et surtout comprendre que ce sont des choses importantes à ne pas oublier que l'on retrouve partout.

[Aiekick]

Le nombre de lignes dépend du langage. 10 lignes pour des langage évolués comme python, RUBY ou java à la limite sont suffisante. En C ou C++ ça fait en effet un peu juste .

Ha bon le c++ n'est pas un langage aussi évolué que le python, ruby, ou java ?

Tu rigole..........

c'est sur que en c++ faut savoir ce que l'on fait, mais si tu code bien ça prendra moins de place que les langages que tu cite..

Evolué, java je veux bien, mais python ou ruby, laisse moi rire.

De plus on parle du langage la pas du framework qui est livré avec !

[Guardian]

Paul Vick, un développeur reconnu et spécialisé dans les bases de données et les langages, a travaillé sur plusieurs produits Microsoft dont SQL Server, Visual Basic ou le runtime .NET.

L'avis d'un gars qui a bossé sur VB ne me semble pas pouvoir constituer une référence

[elmcherqui]

D'apres mon experience , ils doit y avoir le minimum de commentaires possible dans le code , Deja parceque c'est sale , et que souvent c'est inutile.

Rien qu'avec l'indentation , le nom des variables , et le nom de la methode ainsi que les if et while qui pour nous developpeurs sont tres parlants . on peut comprendre le code en le survolant avec nos yeux . bien sur pour des gens qui savent utiliser le langugage pour le rendre expressif .

Le seul endroit ou je tolere les commentaires c'est pour un algorithme personnalisé qui necessite quelques minutes pour qu'il soit compris . donc j'ecris des commentaires pour que la comprehension soit plus rapide .

sinon pour moi l'ideal c'est 6lignes pour le corps d'une fonction que je depasse rarement .
Une fonction ne doit faire qu'une chose .
La classe ne doit s'occuper que d'elle meme et non du travail qu'elle ne devrais pas censé faire .

Et le plus important respecter les niveau d'abstraction dans les classes , il ne faut pas qu'on ai du code bas niveau et haut niveau en meme temps , c'est tres important parceque a mon sens sa prouve que l'architecture est mauvaise .

[pmithrandir]

Effectivement, les commentaires, je sui moyennement pour dans les cas "normaux".
J'en met dans certains cas un peu tordus, par exemple quand ca fait 2 mois que le code est fait, defait, refait encore, et ainsi de suite parce que quelqu'un l'utilise pour quelque chose qui ne correspond pas, et change bien sur cette méthode pour arriver a son résultat. J'ai eu le cas plus d'une fois et c'est lourd de voir le travail fait et refait... donc parfois, une ligne de commentaire genre :

Code :

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

1
2
//J'ai fait ca pour ca, ne pas utiliser cette methode qui produit cette erreur, si question, contactez ...

ca permet de gagner du temps et d'éviter des refactoring et des erreurs répétitives

En revanche je suis d'accord avec la regle 6. Si vous demandez a un débutant de faire une API sans lui expliquer de cas concrets, il aura un mal de chien a bien la faire(déjà que c'est pas un truc évident...)

Mais n'oublions pas que ca dépends de la criticité du projet. On demandera beaucoup plus de réactivité, quitte a perdre de la qualité a un site web de présentation simple, qu'a un système bancaire qui gère des milliards d'euros.

Je rebondit sur une remarque par contre :
Oui, un débutant peut être en entreprise. Croire que seul l'état a pour mission de former les salariés est je pense une connerie. Tous les acteurs qui entourent un salarié participent a sa formation, depuis bien sur ses anciens profs, mais aussi ses chefs, l'entreprise à qui fournit des formations internes ou externes ou l'expérience, et les collègues par l'entraide dans une équipe.

C'est de croire le contraire qui fait que les jeunes sont maintenant avec d'énormes problèmes de chômage parce qu'on répète depuis des années que c'est normal que l'on apprenne tout à l'université(ou plus généralement durant les études) et que l'on doit être opérationnel dés le premier jour de travail. C'est faux.
C'est a cause de ce genre d'idée que l'on entends...

Ah, vous parlez anglais couramment après 1 an et demi a l'étranger, vous avez un master... C'est tout ? Vous n'avez qu'un seul master.

Je précise que ce commentaire était pour une personne de 25 ans...

[Squisqui]

Étant moi-même un p'tit noob en développement (6 mois à tout casser) et étudiant de surcroit. Je me rappelle parfaitement de mes débuts.

Les commentaires étaient plutôt vitaux pour des instructions que je juge maintenant simples et naturelles. Aujourd'hui, je me contente d'expliquer comment utiliser une fonction (valeurs retournées, etc...) dont le nom indique clairement ce qu'elle fait.
Aujourd'hui encore, je me surprends toujours a écrire des lignes et des lignes sur un truc mal pensé dès le départ. Si je devais faire une règle d'or se serait sans hésiter :

"Du papier et un stylo pour définir parfaitement ce que l'on veut et comment l'organiser."

Il faut bien avouer que lire une fonction de plus d'une centaine de lignes à plus d'une demi-douzaine d'indentations est franchement désagréable.

J'ai appris le C par moi-même en lisant des trucs un peu partout (tutos, bouquins, copains) et j'en suis bien content. Dans le cas de mon université (dans une filière non-IT) : les variables c1, c2... fleurissent, conio est largement utilisée et le gaspillage de mémoire parait normal. Comme quoi, les codes pourris ne sont pas prêts de disparaitre.

R1 : C'est plutôt à prendre dans le sens où il faut se poser des questions "est-ce que mon code est bien foutu ? "

R2 : Une chose à la fois, c'est fondamental.

R3 : Il peut-être intéressant de re-inventer la roue un moment pour se familiarisé avec tout un tas de notions. Mais si des fonctions existent, c'est tout aussi bon d'apprendre à lire le manuel qui va avec... Au delà de soi-même, pouvoir lire le code des autres c'est bien aussi.

R4 : C'est en pratiquant qu'on apprend, non ? Loin de moi l'idée d'utiliser des fonctionnalités inconnues en production, mais pour apprendre (donc, pour le débutant), c'est tout simplement indispensable. Il faut faire des conneries en temps d'apprentissage pour apprendre à se servir d'un langage...

R5 : Je ne vois pas où est le problème à copier un morceau de code si le débutant l'étudie de fond en comble pour assimiler de nouvelle méthode de travail. Comme R4, le faire sans le lire est suicidaire en production, je pense.

R6 : On va pas pondre du code naïf toute notre vie quand même ? Si une méthode complètement tordue existe pour diviser la charge CPU par 2 ou plus pour le même résultat, il faut le faire ! Les codes les plus tordus permettent de découvrir des fonctionnalités du langage beaucoup moins courantes.

R7 : Pourquoi s'arrêter d'appliquer ces règles lorsqu'on en a la possibilité ?

Voilà mon point de vu, après 6 mois, je ne suis, pour l'instant, capable de pondre que du code dégueulasse et non-recyclable. Mais plus ça va, mieux c'est.
Travailler sous un système Unix aide pas mal aussi, je trouve (côté manuel surtout).

[DrHelmut]

Personnellement, je recommande à mes juniors :

1 - de planifier leur code en amont, en planifiant via des commentaires la création des méthodes et des variables.
2 - de choisir des noms intelligents quitte à ce qu'ils soient un peu long. L'auto-complétion des IDE permet largement de compenser ce choix. C'est con mais pour moi si un méthode "fait quelque chose avec ses bras", bah je l'appelle "doSomethingWithHisArms" et je cherche pas un raccourci incrompéhensible comme j'en ai trop vu.
3 - un raccourci des règle de base : indentation, (IDE powa) méthodes de moins de 20 lignes autant que faire se peux (30 dans la pratique c'est déjà bien), règle de nommage Java...
4 - l'anglais, ils maîtrisent pas tous et c'est chiant. On essaie des les y pousser, mais en tout cas je leur interdit le Franglais !
5 - si tu sais pas ou si t'as un doute : pose la question, va sur des forums, mais ne fais rien dont tu ne sois sûr !

faire des TU et utiliser maven, ce serait un réél progès, sauf que dans ma boite les chefs de projet appliquent tous la méthode allarach' donc c'est pas gagné...

[omar24]

ça reste un avis mais quand même un avis d'un expert et je trouve qu'il a raison puisqu'il encourage à faire travailler le cerveau qui est la source de la logique ce qui est important dans la programmation.

[Faiche]

Comment, après tout ce temps, on peut encore dire autre chose que :

règle numéro 1 : tester

C'est tout. Tout en découle.

T'as une méthode de 1000 lignes qui a 200 cas fonctionnels, tu vas devoir écrire 200 tests sur cette méthode. Du coup, tu vas vouloir en faire plein de petites.

Tu tires des dépendances de malade dans toutes tes méthodes (genre une méthode static de lecture dans un fichier), tu vas tellement galérer pour tester ça que tu vas vite revoir ta conception (merci le dependency injection)

Tu te dis "ça me coute cher de tester à 100% mon code". La il y a deux écoles : tu abandonnes le test ou tu passes au TDD. (ps : si tu abandonnes à cause de ta boite, change de boite, si tu abandonnes parce que tu as la flemme, change de métier).

Pour ce qui est des commentaires :
si tu éprouves le besoin de mettre un commentaire, c'est parce que tu penses que ton code n'est pas clair.
Etape 1 : est ce qu'il n'y a pas moyen de rendre ce code plus clair ?
Etape 2 : est ce que tes tests unitaires ne suffisent pas à la compréhension ?
Etape 3 : vraiment ? bon ben laisse le ce commentaire alors.

Pour drHelmut : plutot que de leur demander de planifier en amont, fait leur faire du TDD : un cas, un test, un bout de code. ça prends autant de temps que la conception que tu leur fais faire, mais bonus : le code est valide du premier coup

[OsoNet]

Avant de créer de nouvelles règles, il faudrait déjà appliquer l'état de l'art de ce qu'il ce fait.

Il faut RAISONNER! C'est la seule et unique règle à respecter.

On a la chance en tant que développeur d'être dans un domaine en évolution permanente où la pratique n'est pas encore théorisé. Il n'y a pas de solution miracle, de théorie miracle ou de règle miracle. Par conséquent, il faut savoir être humble, remettre en question perpétuellement son savoir, ses capacités, ses acquis et toutes autres choses qui nuisent à l'évolution de notre compréhension.

Quand l'expérience s'engrange, on s'aperçoit très vite des lacunes théoriques pas des développeurs, mais du développement au sens large.
Le développement logiciel est une pratique "adolescente". Pendant toute sa jeunesse elle a utilisé les pratiques d'autres domaines, un jour, elle sera adulte et aura ses propres pratiques en adéquation avec ses règles de l'art.

On observe ce glissement vers l'age adulte depuis une dizaine d'année avec l'apparition des pratiques agiles, de l'open source, des logiciels libres etc. etc. mais l'adolescence n'est pas terminée.

Il faut bien reconnaitre que même si le développement de par sa nature adolescente est perfectible, ses "parents" feraient bien de se remettre en cause aussi:
- Une entreprise s'étonne qu'un débutant ne sait pas développer; mais c'est normal, il est débutant! Prenez un développeur expérimenté, et payez le en tant que tel. En plus il pourra apprendre aux développeurs débutants.
- Une entreprise s'étonne de ne pas trouver le mouton à 5 pattes, expérimentés, supportant tous les dysfonctionnements de la chaine de prise de décision et devant, en plus de son métier, résoudre tous ces problèmes et produire un miracle appelé logiciel! Le tout bien évidemment payer au smic ou à peine plus.

Que dire de plus, le vrai problème n'a pas l'air d'être qu'au niveau des développeurs.

Avec l'expérience, on s'aperçoit que les principes SOLID, les design patterns, l'architecture logicielle... et tout ces choses souvent qualifiées à tort d'inutile par beaucoup de développeur (trop fainéant pour essayer de comprendre?) ont un objectif commun sous-jacent: la qualité du développement et donc du logiciel.

En général, en parlant de "Qualité logicielle" la réaction des développeurs est purement allergique. Ce qui montre bien le paradoxe et le ridicule de la situation. Ceux là même qui devraient promulgué la qualité de leur travail comme objectif premier en son réduit à en avoir peur. De plus, toutes ces pseudo règles quasi religieuses se déduises très rapidement lorsque l'on s'intéresse à la qualité logicielle, et bizarrement, quand il s'agit de sa propre déduction, les règles sont appliquées automatiquement.

La seule chose à dire aux débutants est la suivante: "Le développement est un métier passionnant, difficile et compliqué; de plus, tout est fait pour empirer la situation au lieu de l'améliorer. Tu ne pourras compter que sur ta perspicacité, ta ténacité et tes capacités de raisonnement pour t'en sortir, car les 3/4 des mecs comme moi qui diffusent leur soi-dis-ante science se plante et ils ne le sauront que plus tard, si on leur laisse le temps d'arriver là."
Mais bon c'est pas très correct politiquement parlant donc "Raisonner" résume la seule règle qui aidera les débutants.

En ce qui concerne les commentaires et la documentation, j'applique le principe de responsabilité unique, ce qui donne:
- Le code, c'est le code et rien d'autre que du code. Il doit se suffire à lui-même et être lisible. En cas contraire il doit être corrigé.
- La documentation, c'est la documentation et rien d'autre. Elle n'a absolument rien à faire dans le code. Faire ou pas une documentation sur un projet est une décision liée au projet (portée interne ou externe, architecture...). Dans tous les cas, elle ne doit pas être mélangé au code.
- Des commentaires, çà sert à annoter le code. Une annotation n'est pas une documentation et vice versa. Une annotation dans du code est donc faites pour un développeur car seule les développeurs lisent le code.
Exemples d'annotation:
- Bon: Nom de l’algorithme utilisé avec un lien sur le détail de l'algo
- Mauvais: "Retourne le nom d'une personne." placé sur une propriété ou une fonction qui s'appelle "Name" ou "GetName". Complètement inutile.

Pour la langue utilisée, le code est dans la langue du langage: anglais pour VB, C#... français pour Windev.
La documentation et les annotations sont dans la langue des lecteurs prévus.

Sur ce, je retourne développer.

+1 concernant les tests, au delà de l'agilité qu'ils apportent, ils ont un vrai impact positif sur la qualité des développements.

[spidermario]

Règle numéro 3 : Ne surtout pas leur donner à manger après minuit !!

Je n’ai jamais compris cette règle. À quel moment n’est-on pas après minuit ?

[gillai]

Plutot qu'énumérer quelques règles sans les étayer, il est préférable de conseiller un ouvrage comme Coder Proprement que tout développeur un tant soit peu sérieux doit avoir lu

Je l'ai lu en anglais (j'ai lu 1 livre en français venant de supinfo et je le regrette tellement il était pourri et plein d'erreurs donc plus jamais) et c'est vraiment un super bouquin. Je le recommande très clairement.

[koyosama]

Etant dans l'étude supérieur. J'ai essayer de respecter trois ou 4 règles. Mais la plupart du temps, un développeur débutant ne respecte aucune de ces règles.

Je pense qu'il a oublié une autre règle d'or qui s'applique partout.

Règle numéro 8 : Un développeur est toujours et toujours constamment en train d'apprendre au long de sa vie.