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.

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

[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.

[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!

[kisitomomotene]

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.

Hmmm, je crois que Idéalement, un code devrait se suffire en lui même, sans commentaire. Le commentaire pour moi c'est pour expliquer des situations pas du tout évidentes.
On devrait pouvoir lire un programme bien écrit et le comprendre sans avoir besoin de commentaire ni de documentations supplémentaires.

Par exemple entre ce code:

Code :

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

1
2
3
4
5
6
7
// calcule le solde d'un client:
//le paramètre nom représente le code du client
void calculer(String nom){

...
}

et celui ci

Code :

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

1
2
void calculerSoldeClient(String codeClient){
}

je trouve que le second code n'a pas besoin de commentaire, et on comprend très bien ce que le code est censé faire à partir de sa signature

[Bebel]

Hmmm, je crois que Idéalement, un code devrait se suffire en lui même, sans commentaire. Le commentaire pour moi c'est pour expliquer des situations pas du tout évidentes.
On devrait pouvoir lire un programme bien écrit et le comprendre sans avoir besoin de commentaire ni de documentations supplémentaires.

A la base on parle quand même de règle pour des développeurs débutants. Et dans ce cas la, je pense qu'il est préférable qu'ils travaillent de façons ordonnées. Les commentaires peuvent aider dans ce sens la.

[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...

[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 !

[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

[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.

[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 !

[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

[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".

[popo]

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".

ça dépend fortement du contexte.
Dans mon contexte j'ai du faire un bout de programme qui va interroger une centrale de réservation en ligne bien particulière. Heureusement que j'avais prévu qu'un jour qu'aurais certainement à me connecter à une deuxième voir d'interriger plusieurs centrales pour un même client. ça m'a évité d'avoir à revoir ton mon code pour l'adapter. ça m'a éviter de devoir faire une MAJ de structure dans la base de données 1 an après et d'avoir à refaire une installation chez chaque client.

[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.

[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 !

[Bluedeep]

@Bourgui : Essayes de maintenir du code qui a 36 ans d'âge

Puis

2 lignes avant un bloc ... plus de 1M€ sur le TIP

En tout cas, il avait prévu l'euro en 1972, ça réclame une belle capacité d'anticipation