Discussion :

[Hinault Romaric]

Quelles règles les programmeurs débutants devraient-ils toujours respecter ?
Un développeur expérimenté livre ses 7 règles d'or

A ses débuts, le programmeur inexpérimenté a tendance à fixer son attention sur la fonctionnalité à produire, quelque soit la quantité de ligne de code, les procédures et les fonctions utilisées pour produire le résultat final. Et ceci sans comprendre (parfois) ce qu'il fait vraiment ou les spécificités du langage.

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. Dans un billet de blog, il s'est inspiré des « sept règles pour les écrivains débutants » pour en proposer une version aux jeunes développeurs et leur éviter de faire trop d'erreurs.

Les voici.

Règle numéro 1, le programmeur débutant ne doit pas écrire de longues procédures. Une procédure ne devrait pas avoir plus de dix ou douze lignes de code.

Deux, chaque procédure doit avoir un objectif clair. Un bon programme doit avoir des procédures claires, sans cumul.

Trois, les programmeurs débutants ne doivent pas utiliser les fonctions fantaisistes du langage. Pour Paul Vick, il est mal pour un débutant d'utiliser autre chose que des déclarations de variables, les appels de procédures, des opérateurs (arithmétiques, comparaisons, etc.) et les fonctions de contrôle de flux. Selon lui, l'utilisation des fonctions simples oblige à réfléchir à ce que l'on écrit.

Règle numéro quatre, ne jamais utiliser les fonctionnalités du langage dont vous n'êtes pas sûr(e) du résultat ou du rôle. Une règle d'or indépassable pour Paul Vick, qui estime que si elle n'est pas respectée par un débutant, il devrait purement et simplement changer de métier.

Règle numéro cinq, les débutants doivent à tout prix éviter le copier/coller. Sauf, évidemment, s'ils veulent copier le code d'un programme qu'ils ont écrit.

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

Et enfin la règle numéro sept : applique les six règles ci-dessus chaque jour pendant au moins six mois.

La pratique de la programmation en suivant ces 7 règles d'or peut s'avérer très gênant reconnaît Paul Vick. Mais pour lui, c'est un excellent moyen d'apprendre un langage de programmation.

Et pourrait même permettre, conclut-il avec humour, de se débarrasser des mauvaises habitudes acquises à l'Université.

Et vous ?

Quelles sont vos « 7 Règles d'Or » de la programmation ?

Et que pensez-vous de ces règles de Paul Vick?

Source : Blog Paul Vick

[Bebel]

La règle 1 est très limitative. 15 lignes c'est vraiment peu.

Par contre, je trouve qu'il manque une règle très importante : les commentaires.

L'idéal serait même de commencer à poser l'algo en commentaire avant de commencer à coder.

[pyros]

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 .

Je suis aussi pour les commentaires mais SURTOUT pour documenter ses fonctions. Au delà de rendre le code maintenable et utilisable (ce qui est peu utile pour des débutants qui reprennent rarement leurs codes ), cela permet de clarifier le comportement de la fonction et de se focaliser sur ce qu'elle est censée faire, et non sur ce qu'on veut qu'elle fasse.

Combien de fois a-t-on vue débarquer des booléens à 3 états ou des comportement complètement aberrent car le développeur s'est focalisé sur la résolution d'un bug ou oubliant le comportement normale de la fonction...

[leyee]

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

[clavier12AZQSWX]

la régle n°1 pour le débutant : C O M M E N T E R !

régle n°2 : tester et faire tester son travail

régle n°3 : ne pas travailler et facebooker en même temps !

[Ivelios]

de se débarrasser des mauvaises habitudes acquises à l'Université.

Je ne suis pas du tout d'accord. Personnellement, les profs sont super à cheval sur la propreté de notre code. ça ne regarde que moi mais c'est en partie grâce à l'université que je peux coder "proprement" (ou presque).

[dourouc05]

Par contre, je trouve qu'il manque une règle très importante : les commentaires.

L'idéal serait même de commencer à poser l'algo en commentaire avant de commencer à coder.

Je ne suis pas entièrement d'accord avec ce point : un bon code ne peut pas être commenté, il doit se suffire à lui-même, il doit être suffisamment explicite pour ne pas avoir besoin de commentaires. Par contre, un bon bloc de commentaires avant un algorithme un peu évolué, ça, c'est nécessaire, en effet, ne fût-ce que pour poser ses idées, savoir où l'on va : si celui qui a écrit le code n'arrive pas à expliquer son algo, bonne chance pour les suivants...

Ensuite, la doc : entre une doc inexistante et du code bien commenté ou une bonne doc et du code à peine commenté, je préférerais la bonne doc tant que je dois rester utilisateur de ce code. (Pour mettre les mains dans le cambouis, c'est aussi utile, on sait ce qu'il a voulu dire - enfin, normalement... -, ce qui est toujours utile en cas de refactorisation ou autre).

[sevyc64]

R1 : je suis réservé. Cela dépend du langage, du projet et de la finalité de la procédure

R2,3,4 : OK

R5 : Si le copier/coller est remplacé par du copier/coller/comprendre-ce-que-ça-fait je n'y vois aucun problème.

R6 : Oui, d'autant plus que le concret est souvent simplificateur

R7 : Pas du tout d'accord. Ces règles ne s'appliquent pas seulement à un débutant, la majorité d’entre-elles s'appliquent à tout bon développeur, qu'il soit débutant ou sénior

[Génoce]

ne pas travailler et facebooker en même temps !

Pas spécifique au développement .

[leyee]

Je ne suis pas du tout d'accord. Personnellement, les profs sont super à cheval sur la propreté de notre code. ça ne regarde que moi mais c'est en partie grâce à l'université que je peux coder "proprement" (ou presque).

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

[Bebel]

Je ne suis pas entièrement d'accord avec ce point : un bon code ne peut pas être commenté, il doit se suffire à lui-même, il doit être suffisamment explicite pour ne pas avoir besoin de commentaires. Par contre, un bon bloc de commentaires avant un algorithme un peu évolué, ça, c'est nécessaire, en effet, ne fût-ce que pour poser ses idées, savoir où l'on va : si celui qui a écrit le code n'arrive pas à expliquer son algo, bonne chance pour les suivants...

J'aurais du préciser, que je pensais à des commentaires corrects. C'est à dire qui ne font pas que traduire le code en français ( ou anglais ), mais qui explique la logique des actions.

Faire juste un commentaire pour avoir

Code :

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

1
2
 "je sélectionne tout de ma table avion
SELECT * FROM avion

cela ne sert à rien. Et c'est, à mon avis, très utile pour la reprise derrière par quelqu'un d'autre.

Ensuite, la doc : entre une doc inexistante et du code bien commenté ou une bonne doc et du code à peine commenté, je préférerais la bonne doc tant que je dois rester utilisateur de ce code. (Pour mettre les mains dans le cambouis, c'est aussi utile, on sait ce qu'il a voulu dire - enfin, normalement... -, ce qui est toujours utile en cas de refactorisation ou autre).

Je suis d'accord avec ce point.

[Invité]

ça peut paraitre un troll mais a mon avis els commentaire, dans 90 % des cas gache le code.

Les langage sont pourvu d'une fonctionnalité qui permet d'éviter les commentaires : les noms de fonctions et de variable a taille illimité (ou presque) et les accolades !

les commentaires j'en mets : pour les API (avec la notation pour que ça apparaisse dans l'ide), et pour les bout de code vraiment bizarre qui applique des business rules de l'espace.

mais le coup de

"
//DEBUT ma procedure qui fait ça
....
//FIn ma procedure qui fait ça
"

Le conseil de " Use as few files as possible." est le pire de tous, rien de plus horrible qu'un fichier de code de 10 000 lignes avec 50 classes, la dedans je pars avec resharper et je t'en fait 50 réparti en namespace, comme ça rien qu'en voyant les noms des fichiers tu comprend comment le mec a conçu son appli.

[Traroth2]

La règle 1 est très limitative. 15 lignes c'est vraiment peu.

Par contre, je trouve qu'il manque une règle très importante : les commentaires.

L'idéal serait même de commencer à poser l'algo en commentaire avant de commencer à coder.

Franchement, attention à ne pas sur-commenter le code. Les commentaires peuvent créer plus de problèmes qu'ils n'en résolvent : on maintient le code, mais on ne maintient pas forcément aussi bien les commentaires. Et des commentaires obsolètes, c'est pire que pas de commentaires du tout. Ce que je dis généralement à mes stagiaires concernant les commentaires, c'est : commentez dès que le code n'est plus immédiatement compréhensible, c'est à dire dès que vous faites quelque chose d'astucieux (terme péjoratif, à mes yeux, concernant du code), et mieux encore, essayez d'éviter de faire des choses astucieuses en matière de programmation. L'intelligence, en matière d'ingénierie logicielle, ne doit pas se situer au niveau de la programmation, parce que ça se termine toujours en catastrophe, mais au niveau de l'analyse et de la conception de votre application. Si vous structurez bien votre code, vous ne devriez pas avoir besoin de faire de trucs astucieux pour vous en tirer au final. Autrement dit : keep it simple, stupid!

[el_slapper]

Le problème, c'est que ce genre de règle souffre toujours d'exceptions. Même si je suis grosso modo d'accord - et si je tente toujours de les respecter(sauf qu'en COBOL, 10 lignes, c'est une misère, la limite est plus vers 30-40), il y a toujours des exceptions.

@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).

Formulé autrement : un commentaire doit permettre d'éviter de lire le code qui ne correspond pas à ce que l'on cherche. Genre "Calculs divers préliminaires à l'appel référentiel BLABLA, et initialisation de la mémoire", bon, moi je cherche la sortie, je m'en fous, je passe à la suite. Alors que le nom de la fonction peut m'induire en erreur, me pousser à la lire quand même, et à perdre du temps. Parceque la fonction InitBLABLA, je peux avoir un doute. Et InitMemoireEtCalculsPreliminairesDiversPourAppelBLABLA, non plus. Définitivement.

Maintenant, du pseudo-code en commentaire, je partage l'avis de tous : poubelle.

[cs_ntd]

Je ne suis pas du tout d'accord.

Déja pour moi, un débutant programmeur n'a rien a faire dans une entreprise, c'est un étudiant en informatique, ou un autodidacte. Donc il n'y a pas vraiment de contraintes de qualité, etc... un programmeur débutant travaille pour lui.

Ensuite :

Règle numéro 1, le programmeur débutant ne doit pas écrire de longues procédures. Une procédure ne devrait pas avoir plus de dix ou douze lignes de code.

Si il y a ben une règle avec laquelle je suis d'accord, c'est bien celle la. Avoir des fonctions de 3 kilometre de long, ca n'a jamais servi a personne, c'est source d'erreur, et c'est compliqué a relire. Après je trouve que 10 ou 12 ligne, c'est bien trop peu. j'aurais plus tapé dans les 30 lignes maximum.

Deux, chaque procédure doit avoir un objectif clair. Un bon programme doit avoir des procédures claires, sans cumul.

A, je suis d'accord avec ca aussi en fait

Trois, les programmeurs débutants ne doivent pas utiliser les fonctions fantaisistes du langage. Pour Paul Vick, il est mal pour un débutant d'utiliser autre chose que des déclarations de variables, les appels de procédures, des opérateurs (arithmétiques, comparaisons, etc.) et les fonctions de contrôle de flux. Selon lui, l'utilisation des fonctions simples oblige à réfléchir à ce que l'on écrit.

La ce coup, ci, je ne suis pas du tout d'accord. Les débutant devrait essayer au contraire de se servir de toutes les fonctionnalités du langage / framework qu'ils utilise. Ca permet de mieux comprendre l'environnement dans lequel on travaille, d'etre plus familier avec les concepts du langage. Et la reflexion "que suis-je entrin de faire" peut se faire ailleurs.

Règle numéro quatre, ne jamais utiliser les fonctionnalités du langage dont vous n'êtes pas sûr(e) du résultat ou du rôle. Une règle d'or indépassable pour Paul Vick, qui estime que si elle n'est pas respectée par un débutant, il devrait purement et simplement changer de métier.

Faire ca en entreprise ? Interdit. Je suis d'accord. Faire ca en tant que débutant ? Mais au contraire. C'est source d'erreurs dues a l'incompréhension, ce qui va justement, si on cherche a les résoudre, améliorer la compréhension. Si on se contente que de faire ce qu'on sais faire, on risque pas de progresser .

Règle numéro cinq, les débutants doivent à tout prix éviter le copier/coller. Sauf, évidemment, s'ils veulent copier le code d'un programme qu'ils ont écrit.

Bon, celle la je l'admet aussi, c'est plutot mieux d'éviter le copier coller.

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

Certainement pas ! plus c'est abstrait, plus ca titille les méninges, et plus ca force a réfléchir, a apprendre, a chercher. La concret, ca va bien un moment, mais apres ca, les plus gros challenges sont dans l'abstrait !

règle numéro sept : applique les six règles ci-dessus chaque jour pendant au moins six mois.

Ne pas appliquer ces règles, meme pendant 6 mois. Sauf pour les règles 1,2,5, qu'on devrait suivre toute sa vie

Mais ce n'est pas nécessaire de les mettres en tant que règles. Ces contraintes de lisibilité, etc... peuvent très bien venir toute seules. Avec une utilisation abusive de concepts les plus abstrait possibles. La le débutant va bien se rendre compte qu'il n'arrive pas a faire ce qu'il veut, et il va petit a petit découvrir l'interet d'un code clair, que le copier/coller c'est mauvais pour la réutilisation, etc...

"Réduire" la programmation comme le fait Paul Vick, a une simple utilisation de concepts basiques, je trouve ca néfaste pour un bon développement de l'intellect "programmeur". Je ne pense pas qu'on puisse progresser qvec cette "méthode" vue que l'on se contente des concepts facile ou que l'on connait...


Si je devais faire des règles pour des débutant programmeurs, ce serait ca :

1 - Expérimenter le plus possible, tout ce qu'on peut trouver, chacune de ses idées.
2 - Tant qu'il y a la moindre choses que l'on ne comprends pas, chercher encore. Et chercher par soi-meme, et ne pas pomper l'aide sur un copain/collegue/site internet.
0 - Etre curieux, se poser des questions, et se remettre en question, chercher a savoir ce qui se fait, et rechercher la perfection...

Avec ca, ca suffit normalement...

[Invité]

@el_slapper , en général quand on a affaire du code qui a 36 ans, c'est que c'est une application super sensible (banque, aéronautique, tout ce qui touche soit au vie humaine soit aux grosse masses d'argent etc...) et donc on sait qu'un bout de code ne va pas changer tout les 36 du mois et que la moindre modification est vu par 50 personnes et qu'on est dans une techno pourrie et illisible (en l’occurrence le cobol) donc dans ce cas la oui le commentaire est nécessaire.

et comme je 'lai dit il faut mettre des commentaire sur les business rules étrange dnc ta fonction je l'appelrai bien

DeterminationTypeCourrierEntreTipChequeVirementAutre et un petit commentaire sur la limitation.

De plus il y a de grande chance que ta fonction soit 1/privée et 2appelée a un seul endroit, du coup le nom agi vraiment comme un commentaire, car personne ne va la chercher elle directement comme si c'était une fonction d'une API.

InitMemoireEtCalculsPreliminairesDiversPourAppelBLABLA

Des que y'a ET dans un nom de fonction, c'est qu'il faut en faire 2, car ton "ET" signifie que ta fonction a 2 responsabilité => mal !

[gwinyam]

R1 : Ridicule, limiter la longueur au possible ok parce que sur le principe, une fonction ne doit faire qu'une seule et unique chose ou déléguer. Mais y imposer une limite numéraire n'a pas de sens à mes yeux.
R2 : Ok (correspond à mon comm de R1)
R3 : Au contraire, à la seule et unique condition qu'ils apprennent en même temps à lire la doc et à faire des expériences avec ces fonctions.
R4 : Quand on n'est pas sûr, on ne réinvente pas la roue, on apprend en lisant la doc. En plus ça permet d'apprendre les fondamentaux du langage
R5 : Comme sevyc64, je suis pour le copier/coller/comprendre, mais évidemment contre le copier/coller/passer à la suite
R6 : Ok
R7 : La plupart de ces règles sont applicables à vie

J'ai bloggué il y a peu à ce sujet sur ce qui est pour moi les 6 règles de base à respecter pour bien développer avec Ajax : http://www.mathieurobin.com/2011/05/...per-avec-ajax/

[Barsy]

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

[Loceka]

Moi j'ai pas compris la règle 6.

Par contre j'en rajouterais une autre : toujours coder et commenter en anglais.

Je sais pas si vous avez déjà eu à reprendre un code étranger (allemand, russe, ...) mais c'est l'horreur. Je préfère encore un code obfusqué...

[Invité]

une base de donnée en hollandais ... trop bien les noms de champs de 50 km de long ^^

En plus quand vous avez besoin d'aide et que vous demandez sur des communauté anglophone (genre stackoverflow) vous avez pas a traduire tout le code. Et le jour ou un partenaire etranger se pointe et veux vos web service vous dites pas "j'en ai pour 2 mois de traduction"