IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

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

  1. #1
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    Janvier 2007
    Messages
    4 570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2007
    Messages : 4 570
    Points : 252 372
    Points
    252 372
    Billets dans le blog
    121
    Par défaut 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

  2. #2
    Membre éprouvé Avatar de Bebel
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2003
    Messages
    786
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    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 : 786
    Points : 1 262
    Points
    1 262
    Par défaut
    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.

  3. #3
    Membre expérimenté
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 583
    Points : 1 555
    Points
    1 555
    Par défaut
    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...

  4. #4
    Membre averti
    Profil pro
    Développeur informatique
    Inscrit en
    Avril 2003
    Messages
    321
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Avril 2003
    Messages : 321
    Points : 360
    Points
    360
    Par défaut
    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

  5. #5
    Membre éclairé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Avril 2009
    Messages
    1 428
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 428
    Points : 879
    Points
    879
    Par défaut 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 !

  6. #6
    Membre expérimenté Avatar de Ivelios
    Homme Profil pro
    Développeur Java
    Inscrit en
    Juillet 2008
    Messages
    1 031
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 031
    Points : 1 540
    Points
    1 540
    Par défaut
    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).

  7. #7
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 676
    Points : 188 687
    Points
    188 687
    Par défaut
    Citation Envoyé par Bebel Voir le message
    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).

  8. #8
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 226
    Points : 28 221
    Points
    28 221
    Par défaut
    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

  9. #9
    Membre éclairé
    Homme Profil pro
    NoOb
    Inscrit en
    Mai 2007
    Messages
    554
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : NoOb

    Informations forums :
    Inscription : Mai 2007
    Messages : 554
    Points : 852
    Points
    852
    Par défaut
    Citation Envoyé par Michael REMY Voir le message
    ne pas travailler et facebooker en même temps !
    Pas spécifique au développement .

  10. #10
    Membre averti
    Profil pro
    Développeur informatique
    Inscrit en
    Avril 2003
    Messages
    321
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Avril 2003
    Messages : 321
    Points : 360
    Points
    360
    Par défaut
    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

  11. #11
    Membre éprouvé Avatar de Bebel
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2003
    Messages
    786
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    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 : 786
    Points : 1 262
    Points
    1 262
    Par défaut
    Citation Envoyé par dourouc05 Voir le message
    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 Voir le message
    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.

  12. #12
    Invité
    Invité(e)
    Par défaut
    ç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.

  13. #13
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 522
    Points
    2 522
    Par défaut
    Citation Envoyé par Bebel Voir le message
    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!

  14. #14
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 807
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 807
    Points : 32 103
    Points
    32 103
    Par défaut
    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.

  15. #15
    Membre éprouvé Avatar de cs_ntd
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2006
    Messages
    598
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2006
    Messages : 598
    Points : 1 215
    Points
    1 215
    Par défaut
    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...

  16. #16
    Invité
    Invité(e)
    Par défaut
    @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 !

  17. #17
    Membre chevronné
    Avatar de gwinyam
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mai 2006
    Messages
    1 162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    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 162
    Points : 2 015
    Points
    2 015
    Par défaut
    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/

  18. #18
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 279
    Points
    5 279
    Par défaut
    Règle numéro 3 : Ne surtout pas leur donner à manger après minuit !!


  19. #19
    Expert confirmé
    Avatar de Loceka
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    2 276
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2004
    Messages : 2 276
    Points : 4 843
    Points
    4 843
    Par défaut
    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é...

  20. #20
    Invité
    Invité(e)
    Par défaut
    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"

Discussions similaires

  1. Les développeurs Linux devraient-ils s’intéresser à Mono ?
    Par Olivier Famien dans le forum Actualités
    Réponses: 36
    Dernier message: 06/07/2015, 07h53
  2. Pourquoi les programmeurs systèmes sont-ils trop attachés au C ?
    Par Hinault Romaric dans le forum Débats sur le développement - Le Best Of
    Réponses: 81
    Dernier message: 18/05/2015, 09h55
  3. Quelles pratiques les développeurs devraient-ils éviter ?
    Par Stéphane le calme dans le forum Débats sur le développement - Le Best Of
    Réponses: 53
    Dernier message: 18/03/2015, 18h18
  4. Les jeunes diplômés devraient-ils travailler "pour du beurre" ?
    Par Katleen Erna dans le forum Actualités
    Réponses: 180
    Dernier message: 17/03/2011, 17h35
  5. Réponses: 0
    Dernier message: 30/06/2009, 11h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo