Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 9 12345 ... DernièreDernière
Affichage des résultats 1 à 20 sur 178
  1. #1
    Responsable Actualités

    Avatar de Hinault Romaric
    Homme Profil pro Hinault Romaric
    Consultant
    Inscrit en
    janvier 2007
    Messages
    3 861
    Détails du profil
    Informations personnelles :
    Nom : Homme Hinault Romaric
    Localisation : Cameroun

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 3 861
    Points : 56 532
    Points
    56 532

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

  2. #2
    Membre Expert Avatar de Bebel
    Homme Profil pro David B.
    Développeur informatique
    Inscrit en
    avril 2003
    Messages
    763
    Détails du profil
    Informations personnelles :
    Nom : Homme David B.
    Âge : 31
    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 : 763
    Points : 1 212
    Points
    1 212

    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.
    Tout énigme a une solution ! Tout est question de discipline !

  3. #3
    Membre Expert
    Homme Profil pro
    Inscrit en
    mars 2011
    Messages
    542
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : mars 2011
    Messages : 542
    Points : 1 162
    Points
    1 162

    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 confirmé
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2003
    Messages
    320
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2003
    Messages : 320
    Points : 299
    Points
    299

    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 éprouvé
    Profil pro
    Inscrit en
    avril 2009
    Messages
    735
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Somme (Picardie)

    Informations forums :
    Inscription : avril 2009
    Messages : 735
    Points : 433
    Points
    433

    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 Expert Avatar de Ivelios
    Homme Profil pro Paul-Alexandre NAUD
    Consultant SI
    Inscrit en
    juillet 2008
    Messages
    1 011
    Détails du profil
    Informations personnelles :
    Nom : Homme Paul-Alexandre NAUD
    Âge : 25
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Consultant SI

    Informations forums :
    Inscription : juillet 2008
    Messages : 1 011
    Points : 1 407
    Points
    1 407

    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).
    Il était une fois [...] Et ils vécurent heureux et eurent beaucoup d'enfants!

  7. #7
    Responsable Qt

    Avatar de dourouc05
    Homme Profil pro Thibaut Cuvelier
    Étudiant
    Inscrit en
    août 2008
    Messages
    19 481
    Détails du profil
    Informations personnelles :
    Nom : Homme Thibaut Cuvelier
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 19 481
    Points : 76 042
    Points
    76 042

    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).
    Vous souhaitez participer aux rubriques Qt ou PyQt/PySide (tutoriels, FAQ, traductions, sources) ? Contactez-moi par MP.

    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  8. #8
    Modérateur
    Avatar de sevyc64
    Homme Profil pro Yves
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    6 943
    Détails du profil
    Informations personnelles :
    Nom : Homme Yves
    Âge : 41
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 6 943
    Points : 17 810
    Points
    17 810

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

    Parce que le partage est notre force, la connaissance sera notre victoire

  9. #9
    Membre émérite
    Homme Profil pro
    NoOb
    Inscrit en
    mai 2007
    Messages
    555
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : NoOb

    Informations forums :
    Inscription : mai 2007
    Messages : 555
    Points : 812
    Points
    812

    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 confirmé
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2003
    Messages
    320
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2003
    Messages : 320
    Points : 299
    Points
    299

    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 Expert Avatar de Bebel
    Homme Profil pro David B.
    Développeur informatique
    Inscrit en
    avril 2003
    Messages
    763
    Détails du profil
    Informations personnelles :
    Nom : Homme David B.
    Âge : 31
    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 : 763
    Points : 1 212
    Points
    1 212

    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 :
    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.
    Tout énigme a une solution ! Tout est question de discipline !

  12. #12
    Membre expérimenté
    Homme Profil pro Rémi BOURGAREL
    Développeur .NET
    Inscrit en
    juin 2006
    Messages
    425
    Détails du profil
    Informations personnelles :
    Nom : Homme Rémi BOURGAREL
    Âge : 27
    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 : 549
    Points
    549

    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
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 777
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 777
    Points : 6 663
    Points
    6 663

    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!
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  14. #14
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 143
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 143
    Points : 10 258
    Points
    10 258

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

  15. #15
    Membre Expert 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 131
    Points
    1 131

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

    The magic of Opera, La magie de l'Opera
    The mysteries of Space Opera, Les mystères de l'Opera Spatial
    Mr. Know-it-all, M. Je-Sais-Tout
    Prelude in C sharp minor, the most beautiful piano song and the best C sharp prelude ever, Prélude en do dièse mineur, le plus beau morceau de piano et le meilleur prélude au C#
    The Mesmerizing Saphir Division for Nerds, L'Hypnotisante Division Saphire pour les Nerds (HDSN)

  16. #16
    Membre expérimenté
    Homme Profil pro Rémi BOURGAREL
    Développeur .NET
    Inscrit en
    juin 2006
    Messages
    425
    Détails du profil
    Informations personnelles :
    Nom : Homme Rémi BOURGAREL
    Âge : 27
    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 : 549
    Points
    549

    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 Expert
    Avatar de gwinyam
    Homme Profil pro Mathieu ROBIN
    Développeur Web
    Inscrit en
    mai 2006
    Messages
    1 162
    Détails du profil
    Informations personnelles :
    Nom : Homme Mathieu ROBIN
    Âge : 28
    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 037
    Points
    2 037

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

  18. #18
    Expert Confirmé Avatar de Barsy
    Homme Profil pro Sylvain
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 376
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain
    Âge : 31
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 376
    Points : 3 780
    Points
    3 780

    Par défaut

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

  19. #19
    Expert Confirmé Sénior Avatar de Loceka
    Profil pro Tlouye Ci
    Inscrit en
    mars 2004
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Nom : Tlouye Ci

    Informations forums :
    Inscription : mars 2004
    Messages : 2 048
    Points : 4 052
    Points
    4 052

    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
    Membre expérimenté
    Homme Profil pro Rémi BOURGAREL
    Développeur .NET
    Inscrit en
    juin 2006
    Messages
    425
    Détails du profil
    Informations personnelles :
    Nom : Homme Rémi BOURGAREL
    Âge : 27
    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 : 549
    Points
    549

    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"

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •