Quelles règles les programmeurs débutants devraient-ils toujours respecter ?

Hinault Romaric · 19/05/2011, 15h29

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 · 19/05/2011, 15h42

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 · 19/05/2011, 16h01

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 · 19/05/2011, 16h10

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

Michael REMY · 19/05/2011, 16h18

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 · 19/05/2011, 16h23

Citation:

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 · 19/05/2011, 16h25

Citation:

Envoyé par Bebel

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 · 19/05/2011, 16h29

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 · 19/05/2011, 16h34

Citation:

Envoyé par Michael REMY

ne pas travailler et facebooker en même temps !

Pas spécifique au développement

.

leyee · 19/05/2011, 16h37

Citation:

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 · 19/05/2011, 16h37

Citation:

Envoyé par dourouc05

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.

Citation:

Envoyé par dourouc05

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.

Bourgui · 19/05/2011, 16h39

ç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 · 19/05/2011, 16h52

Citation:

Envoyé par 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.

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 · 19/05/2011, 16h53

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 · 19/05/2011, 16h53

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 :

Citation:

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.

Citation:

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

Citation:

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.

Citation:

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

.

Citation:

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.

Citation:

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 !

Citation:

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

Bourgui · 19/05/2011, 17h03

@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 · 19/05/2011, 17h09

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 · 19/05/2011, 17h18

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

Loceka · 19/05/2011, 17h23

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

Bourgui · 19/05/2011, 17h25

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"

19/05/2011, 15h29	#1
Hinault Romaric Responsable Actualités Hinault Romaric Consultant Inscription : janvier 2007 Messages : 2 824 Détails du profil Informations personnelles : Nom : Hinault Romaric Localisation : Cameroun Informations professionnelles : Activité : Consultant Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : janvier 2007 Messages : 2 824 Points : 37 288 Points : 37 288	Quelles règles les programmeurs débutants devraient-ils toujours respecter ? 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 __________________ Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire Mon blog Mes articles En posant correctement votre problème, on trouve la moitié de la solution
	131

19/05/2011, 15h42	#2
Bebel Membre Expert David B. Développeur informatique Inscription : avril 2003 Messages : 742 Détails du profil Informations personnelles : Nom : David B. Âge : 30 Localisation : France, Haute Garonne (Midi Pyrénées) Informations professionnelles : Activité : Développeur informatique Secteur : Aéronautique - Marine - Espace - Armement Informations forums : Inscription : avril 2003 Messages : 742 Points : 1 128 Points : 1 128	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. __________________ Tout énigme a une solution ! Tout est question de discipline !
	162

19/05/2011, 16h01	#3
pyros Membre Expert Inscription : mars 2011 Messages : 531 Détails du profil Informations personnelles : Sexe : Localisation : France Informations forums : Inscription : mars 2011 Messages : 531 Points : 1 042 Points : 1 042	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...
	61

19/05/2011, 16h18	#5
Michael REMY Membre éclairé Inscription : avril 2009 Messages : 671 Détails du profil Informations personnelles : Âge : 36 Localisation : France, Somme (Picardie) Informations forums : Inscription : avril 2009 Messages : 671 Points : 395 Points : 395	Michael REMY, très bon programmeur 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 !
	142

19/05/2011, 16h29	#8
sevyc64 Modérateur Yves Développeur informatique Inscription : janvier 2007 Messages : 5 278 Détails du profil Informations personnelles : Nom : Yves Âge : 40 Localisation : France, Pyrénées Atlantiques (Aquitaine) Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : janvier 2007 Messages : 5 278 Points : 11 952 Points : 11 952	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 __________________ --- Sevyc64 --- Parce que le partage est notre force, la connaissance sera notre victoire
	00

19/05/2011, 16h10	#4
leyee Membre éclairé Développeur informatique Inscription : avril 2003 Messages : 315 Détails du profil Informations personnelles : Âge : 29 Localisation : France, Hérault (Languedoc Roussillon) Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : avril 2003 Messages : 315 Points : 307 Points : 307	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
	64

19/05/2011, 16h39	#12
Bourgui Membre chevronné Rémi BOURGAREL Développeur .NET Inscription : juin 2006 Messages : 425 Détails du profil Informations personnelles : Nom : Rémi BOURGAREL Âge : 26 Localisation : France, Haute Garonne (Midi Pyrénées) Informations professionnelles : Activité : Développeur .NET Secteur : Tourisme - Loisirs Informations forums : Inscription : juin 2006 Messages : 425 Points : 604 Points : 604	ç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.
	161

19/05/2011, 16h53	#14
el_slapper Expert Confirmé Sénior Inscription : décembre 2007 Messages : 2 541 Détails du profil Informations personnelles : Localisation : France Informations forums : Inscription : décembre 2007 Messages : 2 541 Points : 6 144 Points : 6 144	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. __________________ Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten : 1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception 2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences 3)le temps de comprendre toutes les exigences, le projet est terminé 4)le temps de terminer le projet, les exigences ont changé Et le serment de non-allégiance : Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
	52

19/05/2011, 17h03	#16
Bourgui Membre chevronné Rémi BOURGAREL Développeur .NET Inscription : juin 2006 Messages : 425 Détails du profil Informations personnelles : Nom : Rémi BOURGAREL Âge : 26 Localisation : France, Haute Garonne (Midi Pyrénées) Informations professionnelles : Activité : Développeur .NET Secteur : Tourisme - Loisirs Informations forums : Inscription : juin 2006 Messages : 425 Points : 604 Points : 604	@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 !
	10

19/05/2011, 17h09	#17
gwinyam Membre Expert Mathieu ROBIN Développeur Web Inscription : mai 2006 Messages : 1 157 Détails du profil Informations personnelles : Nom : Mathieu ROBIN Âge : 26 Localisation : France, Paris (Île de France) Informations professionnelles : Activité : Développeur Web Secteur : High Tech - Opérateur de télécommunications Informations forums : Inscription : mai 2006 Messages : 1 157 Points : 2 159 Points : 2 159	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/ __________________ Mon blog techno, essentiellement JavaScript, et son billet hebdomadaire sur l'actualité jQuery. Le bouton ne masse pas les pieds, mais ça aide la communauté.
	30

19/05/2011, 17h18	#18
Barsy Expert Confirmé Sylvain Ingénieur développement logiciels Inscription : octobre 2007 Messages : 1 247 Détails du profil Informations personnelles : Nom : Sylvain Âge : 29 Localisation : France, Loire Atlantique (Pays de la Loire) Informations professionnelles : Activité : Ingénieur développement logiciels Informations forums : Inscription : octobre 2007 Messages : 1 247 Points : 3 543 Points : 3 543	Règle numéro 3 : Ne surtout pas leur donner à manger après minuit !! __________________ "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"
	112

19/05/2011, 17h23	#19
Loceka Expert Confirmé Tlouye Ci Inscription : mars 2004 Messages : 1 800 Détails du profil Informations personnelles : Nom : Tlouye Ci Informations forums : Inscription : mars 2004 Messages : 1 800 Points : 2 918 Points : 2 918	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é...
	51

19/05/2011, 17h25	#20
Bourgui Membre chevronné Rémi BOURGAREL Développeur .NET Inscription : juin 2006 Messages : 425 Détails du profil Informations personnelles : Nom : Rémi BOURGAREL Âge : 26 Localisation : France, Haute Garonne (Midi Pyrénées) Informations professionnelles : Activité : Développeur .NET Secteur : Tourisme - Loisirs Informations forums : Inscription : juin 2006 Messages : 425 Points : 604 Points : 604	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"
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email