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. #161
    Membre éclairé Avatar de befalimpertinent
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    561
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : Avril 2007
    Messages : 561
    Points : 833
    Points
    833
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    /**
    * Pour lire le texte rtf converti dans un traitement de texte, il est conseillé *de le mettre à la taille 20, et d'utiliser la police Arial
    */
    String convertirAsciiEnRtf(String texteAconvertir){
    }
    ça ça marche sur un code qui contient relativement peu de fonctions et/ou classes. Par contre dès qu'on est dans le cadre pro, avec plusieurs centaine de classes et plusieurs centaine de milliers de ligne de code j'image même pas le bazar si on compte sur ce genre de commentaires pour maintenir le code. Et donc ce n'est pas un bon conseil à donner aux débutants.
    C'est à la fonction ou à la classe de gérer ce genre de "détails" si dans tel ou tel cas ce n'est pas possible c'est que le découpage n'est pas bon.
    Et enfin si nécessaire vient l'option TU.
    Dans l'exemple donnée c'est difficile de prédire la solution adéquate parce qu'il manque le contexte, mais la première à éviter est certainement par le biais d'un commentaire
    Linux > *

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par deuz59 Voir le message
    On est bien d'accord, ce TU est suffisant, et comme la fonction ne fait rien d'autre, le commentaire associé est mal placé !
    mal plaçé? Encore une fois, il ne se substitue pas au code.

    Citation Envoyé par deuz59 Voir le message
    Le but est d'écrire du bon code, et l'effort doit être fourni pour le code à écrire pas pour aller "au-delà"
    Ben non. On est pas des pisseurs de code, on est des ingénieurs. Que ce soit par la structure du code ou par des commentaires appropriés, on se doit de prévoir la suite.

    Citation Envoyé par deuz59 Voir le message
    Tout à fait, et pour la même raison qu'il n'y a pas besoin de TU, le commentaire est inutile. Le jour où cette fonctionnalité devra être développée alors là tu pourras écrire son TU...qui servira justement à valider que la fonctionnalité continue à faire ce qu'on lui demande lorsque tu décideras de changer l'outillage pour le transfert ....et le commentaire ne servira toujours à rien !!!
    Ben non. Le code peut être amené à être lu par des gens qui ne connaissent pas bien la problématique. Sur du code qui vieillit, c'est souvent le cas. Sur mon code à 35 ans d'âge, personne ne savait ce que ça faisait ni pourquoi - on savait juste que le résultat final était bon. Et, je peux te dire que les rares commentaires qui te disent POURQUOI sont vraiment, vraiment utiles.

    Citation Envoyé par deuz59 Voir le message
    On parle de règle à appliquer pour un débutant (ou pas) à notre époque, avec les moyens à notre dispo aujourdh'ui et avec le recul (là encore on retrouve l'expérience qui dicte les bonnes pratiques)...sûr que dans les programmes "d'antan" la règle de tout commenter était beaucoup plus légitime
    Je ne dis pas "tout commenter". Loin s'en faut. Je dis "eclairer le lecteur non informé de la raison des choix qui sont faits, et peuvent paraitre surprenants". Par exemple, le mainteneur peu averti pourrait se dire que tout ce bordel est inutile et tenter un transfert sans conversion préalable - ce qui lui ferait perdre les caractères spéciaux(j'ai essayé). En sachant d'entrée pourquoi je me suit fait chier à cracher cette fonction, il ne va pas chercher plus loin : il SAIT, sans rien lire du code, que cette fonction devient indispensable dès qu'on risque d'avoir des caractères spéciaux.

    Le débutant aura peut-être un débutant qui arrive derrière. Si il ne tente pas de "simplifier" le code parcequ'il n'aura pas compris sa finalité, alors le commetaire aura rempli son objectif.

    Citation Envoyé par deuz59 Voir le message
    Si c'est cette fonction que tu dois modifier, tu l'auras trouver en même temps que son commentaire, donc plus besoin de commentaire (c'est comme enterrer une carte au trésor avec son trésor : aucun intérêt !!)
    Non, encore : si on la modifie(en l'occurence, il faudrait une modification des normes ASCII ou EBCDIC, autant dire que ça n'arrivera jamais, mais imaginons quand même), pour autant, le contexte de sa création n'a pas évolué. Le commentaire reste toujours d'actualité, passer par la fonction puis, à la main, par un transfert binaire, est le seul moyen connu de ne pas perdre les caractères spéciaux.

    Et ça n'est pas une carte. C'est un descriptif d'utilisation. un contexte d'utilisation. La carte au trésor, c'est le nom de la fonction. Mais sur du vieux code, généralement, on ne sait même pas ce que l'on cherche, au départ. On tombe sur des trucs qui paraissent invraisemblables, inutiles ou mal pensés. Et qui, quand on a enfin compris, font soudain sens.

    Quand dans deux ans(je viendrais de partir, règle des 3 ans) on dira à un successeur "tiens, le slap il a laissé ce code pour préparer les transferts, tu peux nous l'adapter à tel nouveau format?", il pourra lire le commentaire et comprendre pourquoi il faut passer par les étapes déclarées dans le commentaire(3 minutes), ou bien voir qu'il y a une étrange pré-traduction qui semble inutile, lourdingue, que ce serait plus élégants de faire un fichier lisible sous windows à transférer en mode "traduction", et se rendre compte plus tard qu'il a perdu les caractères spéciaux(3 jours).



    ==>Ma fonction traduit de l'ASCII en EBCDIC. Mais si on ne sait pas pourquoi c'est utile, elle ne sert à rien. La doc, ça se perd. Seul le commentaire reste. Donc le commentaire doit expliquer à quoi ça sert(et non pas ce que ça fait, le nom de la fonction doit suffire).
    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.

  3. #163
    Membre habitué
    Inscrit en
    Octobre 2004
    Messages
    83
    Détails du profil
    Informations forums :
    Inscription : Octobre 2004
    Messages : 83
    Points : 132
    Points
    132
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    mal plaçé? Encore une fois, il ne se substitue pas au code.
    Pire, il se substitue au code inexistant et qui n'existera peut etre jamais ! En voulant faire bien, cela nuit à la maintenabilité globale du code...

    Citation Envoyé par el_slapper Voir le message
    Ben non. On est pas des pisseurs de code, on est des ingénieurs. Que ce soit par la structure du code ou par des commentaires appropriés, on se doit de prévoir la suite.
    Entièrement d'accord, c'est pour cela qu'on doit pas "pisser" des commentaires inutilement. C'est justement un code bien pensé qui pourra se passer de commentaires inutiles qui plombent la maintenabilité du code

    Citation Envoyé par el_slapper Voir le message
    Ben non. Le code peut être amené à être lu par des gens qui ne connaissent pas bien la problématique. Sur du code qui vieillit, c'est souvent le cas. Sur mon code à 35 ans d'âge, personne ne savait ce que ça faisait ni pourquoi - on savait juste que le résultat final était bon. Et, je peux te dire que les rares commentaires qui te disent POURQUOI sont vraiment, vraiment utiles.
    Encore une fois, on parle de règles à appliquer par un débutant...si ces règles avaient été appliquées il y a 35 ans, les commentaires auraient eu l'effet inverse....maintenant c'est sûr qu'avec le peu d'expérience dans le domaine et les moyens de l'époque ça eut été plus compliqué et qu'en effet le meilleur contournement possible restait les commentaires => ils sont donc utiles
    Le sujet ici est tout autre, c'est justement parceque cette règle de tout commenter a été bonne a une époque et est (trop) restée comme une règle absolue qu'il est difficile de faire entendre/comprendre aujourd'hui qu'"un bon commentaire est celui qui n'a pas besoin d'être écrit"

    Citation Envoyé par el_slapper Voir le message
    Je ne dis pas "tout commenter". Loin s'en faut. Je dis "eclairer le lecteur non informé de la raison des choix qui sont faits, et peuvent paraitre surprenants". Par exemple, le mainteneur peu averti pourrait se dire que tout ce bordel est inutile et tenter un transfert sans conversion préalable - ce qui lui ferait perdre les caractères spéciaux(j'ai essayé). En sachant d'entrée pourquoi je me suit fait chier à cracher cette fonction, il ne va pas chercher plus loin : il SAIT, sans rien lire du code, que cette fonction devient indispensable dès qu'on risque d'avoir des caractères spéciaux.
    C'est donc un problème d'ego...tu as écrit cette fonction et tu veux qu'on s'efforce de comprendre tout ce qu'elle permettrait de faire et surtout qu'on l'utilise...ce n'est pas l'objectif du codage qui doit "simplement" implémenter un besoin fonctionnel précis


    Citation Envoyé par el_slapper Voir le message
    Le débutant aura peut-être un débutant qui arrive derrière. Si il ne tente pas de "simplifier" le code parcequ'il n'aura pas compris sa finalité, alors le commetaire aura rempli son objectif.
    C'est tout le débat de ce sujet et en particulier concernant l'utilité des commentaires.
    Le code peut/doit être compréhensible sans commentaire dans la mesure du possible...si tu penses qu'un commentaire est nécessaire car risque d'incompréhension, c'est que le code peut être amélioré...


    Citation Envoyé par el_slapper Voir le message
    Non, encore : si on la modifie(en l'occurence, il faudrait une modification des normes ASCII ou EBCDIC, autant dire que ça n'arrivera jamais, mais imaginons quand même), pour autant, le contexte de sa création n'a pas évolué. Le commentaire reste toujours d'actualité, passer par la fonction puis, à la main, par un transfert binaire, est le seul moyen connu de ne pas perdre les caractères spéciaux.
    Sauf que le contexte de création, on s'en cogne (sauf cas extrême comme un choix arbitraire pas immédiat), on ne doit pas raconter sa vie dans le code

    Citation Envoyé par el_slapper Voir le message
    Et ça n'est pas une carte. C'est un descriptif d'utilisation. un contexte d'utilisation. La carte au trésor, c'est le nom de la fonction. Mais sur du vieux code, généralement, on ne sait même pas ce que l'on cherche, au départ. On tombe sur des trucs qui paraissent invraisemblables, inutiles ou mal pensés. Et qui, quand on a enfin compris, font soudain sens.
    Tu décris exactement ce pourquoi ce type de commentaire nuit !

    "C'est un descriptif d'utilisation"
    ==> Cela n'a pas lieu d'être dans le code (encore une fois sauf si tu développes une API destinées à être utilisée par des applications tierces auquel cas la javadoc par exemple a toute son utilité)

    "Mais sur du vieux code, généralement, on ne sait même pas ce que l'on cherche, au départ. On tombe sur des trucs qui paraissent invraisemblables, inutiles ou mal pensés. Et qui, quand on a enfin compris, font soudain sens."
    ==> voilà pourquoi sur du nouveau code on doit s'efforcer d'éviter cela et que l'utilisation systématique des commentaires tend justement à aboutir à un code moins maintenable...c'est le fait d'écrire des commentaires qui les rend nécessaires donc autant les éviter au maximum

    Citation Envoyé par el_slapper Voir le message
    Quand dans deux ans(je viendrais de partir, règle des 3 ans) on dira à un successeur "tiens, le slap il a laissé ce code pour préparer les transferts, tu peux nous l'adapter à tel nouveau format?", il pourra lire le commentaire et comprendre pourquoi il faut passer par les étapes déclarées dans le commentaire(3 minutes), ou bien voir qu'il y a une étrange pré-traduction qui semble inutile, lourdingue, que ce serait plus élégants de faire un fichier lisible sous windows à transférer en mode "traduction", et se rendre compte plus tard qu'il a perdu les caractères spéciaux(3 jours).
    Et pour un autre besoin il devra identifier où intervenir dans le code mais il s'épuisera inutilement à lire tout un tas de commentaires dont il se fou, comprendre les moindres détails des problématiques qui ne concernent en rien son intervention (pire : il sera induit en erreur par un commentaire obsolète)..au final, après avoir perdu bcp de temps et une grosse fatigue intellectuelle, il se résignera à faire une modification sans conviction avec un risque d'erreur sur l'endroit mais aussi sur l'implémentation de son intervention
    (écrire du code en étant lassé et fatigué est rarement bon) créant une nouvelle anomalie, peut être pas immédiate mais dont la correction future nécessitera de nouveau qu'il ou qqun d'autre se repaluche tout le code (et tous les commentaires sans intérêt) !!!

    Citation Envoyé par el_slapper Voir le message
    ==>Ma fonction traduit de l'ASCII en EBCDIC. Mais si on ne sait pas pourquoi c'est utile, elle ne sert à rien. La doc, ça se perd. Seul le commentaire reste. Donc le commentaire doit expliquer à quoi ça sert(et non pas ce que ça fait, le nom de la fonction doit suffire).
    Dans ce cas au lieu de commenter inutilement, voit comment faire en sorte de ne pas perdre la doc !!!

    Quant à la question "A quoi ça sert" on le sait déjà : à répondre au besoin du client ! Si quelqu'un se penche sur du code en ayant la conviction qu'une fonction ne sert à rien, soit le code est bien fichu et il devrait rapidement se rendre compte du contraire, soit le code est illisible et là en effet il risque de tirer des conclusions hâtives maladroites.....donc le commentaire est encore un moyen d'éviter de bien coder tout en soulageant sa conscience !!!
    Pour finir, tu évoques ici les risques du refactoring...le risque n'évite pas le danger et le maintien du code passe par le refactoring. Le meilleur moyen de se prémunir des risques induits demeure le test, le test et encore le test..en commençant par les tests unitaires (si on supprime ta fonction et qu'un test unitaire échoue à cause de cela, elle sera finalement conservée voir améliorée ou remplacée par une alternative plus adaptée...même sans commentaire)

  4. #164
    Membre averti
    Inscrit en
    Août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 307
    Points : 378
    Points
    378
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Non, car c'est un exemple très mal choisi, qui devrait être dans une doc utilisateur et n'a rien à faire dans du code, que ça soit commentaire ou TU
    Les docs utilisateurs des API sont précisément des commentaires dans le code source! (voire par exemple la doc du JDK)

  5. #165
    Membre habitué
    Inscrit en
    Octobre 2004
    Messages
    83
    Détails du profil
    Informations forums :
    Inscription : Octobre 2004
    Messages : 83
    Points : 132
    Points
    132
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    Les docs utilisateurs des API sont précisément des commentaires dans le code source! (voire par exemple la doc du JDK)
    Le cas des API a en effet toujours été considéré comme un cas particulier.
    L'exemple ici ne concerne pas une API et combien même, le commentaire ne serait pas une documentation d'API donc rien à voir là...

    A noter qu'en effet le JDK utilise la javadoc qui est du commentaire dans le code mais ce n'est pas pour cela que cette solution serait la panacée...au jour d'aujourd'hui cela semble demeurer un bon compromis documentation/lisibilité mais si on pouvait découpler davantage les pavés de commentaires du code source tout en conservant une documentation aussi proche du code cela serait nettement meilleur (peut être que dans 35 ans de nouveaux moyens alors à notre disposition permettrons de faire mieux )

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Bon, on ne sera jamais d'accord sur ce sous-débat.....

    Pour faire bref(enfin essayer), je dirais que nous ne vivons pas dans un monde parfait, et que la doc SERA perdue. Nous ne vivons pas dans un monde parfait et il y aura du code non-parfait. Nous ne vivons pas dans un monde parfait, et notre surccesseur ne sera pas meilleur que nous. Et il sera heureux de trouver un peu de vrai Français qui lui dise deux-trois trucs utiles.

    Mais bon, c'est un vieux débat, qui plus est à la marge, car je suis d'accord avec ton prémisse
    si tu penses qu'un commentaire est nécessaire car risque d'incompréhension, c'est que le code peut être amélioré...
    Juste, je crois que même si le code n'a pas besoin de commentaires pour être compris, un commentaire sera quand même utile. Toi, tu ne le considères pas comme utile. Et on est d'accord sur notre désaccord.
    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.

  7. #167
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Citation Envoyé par deuz59 Voir le message
    C'est tout le débat de ce sujet et en particulier concernant l'utilité des commentaires.
    Le code peut/doit être compréhensible sans commentaire dans la mesure du possible...si tu penses qu'un commentaire est nécessaire car risque d'incompréhension, c'est que le code peut être amélioré...
    C'est ça la phrase clé : dans la mesure du possible. Il arrive tout de même souvent qu'on soit amené à faire des choses qui semblent un peu contre-intuitives ou superflues mais qui ont une certaine importance, style une optimisation ou un test supplémentaire qui évite une défaillance dans une librairie tierce.

    Pour le reste, je maintiens que les commentaires ne sont pas une documentation en soi. Il existe de supers outils gratuits pour faire de la doc, des diagrammes, et tout ça, et des solutions style wiki très faciles à mettre en oeuvre pour les publier (voir mes posts précédents).

  8. #168
    Membre habitué
    Inscrit en
    Octobre 2004
    Messages
    83
    Détails du profil
    Informations forums :
    Inscription : Octobre 2004
    Messages : 83
    Points : 132
    Points
    132
    Par défaut
    Citation Envoyé par _skip Voir le message
    C'est ça la phrase clé : dans la mesure du possible. Il arrive tout de même souvent qu'on soit amené à faire des choses qui semblent un peu contre-intuitives ou superflues mais qui ont une certaine importance, style une optimisation ou un test supplémentaire qui évite une défaillance dans une librairie tierce.

    Pour le reste, je maintiens que les commentaires ne sont pas une documentation en soi. Il existe de supers outils gratuits pour faire de la doc, des diagrammes, et tout ça, et des solutions style wiki très faciles à mettre en oeuvre pour les publier (voir mes posts précédents).
    Le commentaire demeure un outil qu'il faut utiliser à bon escient, en fait si on insiste ici sur son inutilité c'est que dans 90% des cas où on dit "il faut commenter" c'est pour une mauvaise raison et c'est un contre emploi qui provoque l'effet inverse de ce qu'on veut faire, à savoir un code propre et maintenable..malheureusement tant qu'on ne sera pas suffisamment catégorique sur les méfaits des commentaires, les règles du style 'tout commenter' demeureront dans les subconscients et on continuera à commenter en pensant qu'il était impossible de faire autrement alors que c'est quasiment toujours possible. La bonne conduite à tenir est donc de coder en faisant tout pour ne pas commenter et laisser un commentaire la mort dans l'âme en ayant bien étudié la raison de ce commentaire et fait son maximum pour l'éviter.....il restera toujours des commentaires mal placés ou complètement inutiles, c'est pour ça que le refactoring est une autre bonne règle à adopter (prérecquis : Tests Unitaires pour limiter les risques de régression) => si tu vois qu'un collègue à laisser un commentaire en pensant qu'il ne pouvait pas faire autrement alors que c'est clairement parcequ'il n'a pas été au bout pour faire du bon code, revoit son code et supprime le commentaire inutile.....

  9. #169
    Membre habitué
    Inscrit en
    Octobre 2004
    Messages
    83
    Détails du profil
    Informations forums :
    Inscription : Octobre 2004
    Messages : 83
    Points : 132
    Points
    132
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Bon, on ne sera jamais d'accord sur ce sous-débat.....

    Pour faire bref(enfin essayer), je dirais que nous ne vivons pas dans un monde parfait, et que la doc SERA perdue. Nous ne vivons pas dans un monde parfait et il y aura du code non-parfait. Nous ne vivons pas dans un monde parfait, et notre surccesseur ne sera pas meilleur que nous. Et il sera heureux de trouver un peu de vrai Français qui lui dise deux-trois trucs utiles.

    Mais bon, c'est un vieux débat, qui plus est à la marge, car je suis d'accord avec ton prémisse Juste, je crois que même si le code n'a pas besoin de commentaires pour être compris, un commentaire sera quand même utile. Toi, tu ne le considères pas comme utile. Et on est d'accord sur notre désaccord.
    On est bien d'accord mais c'est surtout pour cela qu'il faut faire en sorte de "rendre le monde meilleur" et ne pas continuer de suivre de mauvaises règles par dépit => faisons en sorte d'améliorer les choses et non de les prendre comme une fatalité

  10. #170
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Points : 13 314
    Points
    13 314
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    @Bourgui : Essayes de maintenir du code qui a 36 ans d'âge
    Puis

    2 lignes avant un bloc ... plus de 1M€ sur le TIP
    En tout cas, il avait prévu l'euro en 1972, ça réclame une belle capacité d'anticipation

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  11. #171
    Membre expérimenté
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2011
    Messages
    366
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : Mai 2011
    Messages : 366
    Points : 1 361
    Points
    1 361
    Par défaut
    Tester, tester, tester, règle numéro 0.
    les raisonnables ont duré, les passionné-e-s ont vécu

  12. #172
    Modérateur
    Avatar de Kreepz
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2011
    Messages
    681
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Juin 2011
    Messages : 681
    Points : 1 458
    Points
    1 458
    Billets dans le blog
    1
    Par défaut
    La première règle pour un débutant c'est d'avoir des bugs pour ensuite apprendre à les résoudre ou apprendre à chercher des réponses pour les résoudre.
    Pensez à regarder nos cours et tutoriels PHP ainsi que notre FAQ PHP avant de poser votre question!
    Un message vous a aidé, n'oubliez pas le

  13. #173
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    Citation Envoyé par rmaker Voir le message
    Tester, tester, tester, règle numéro 0.
    tu ne peux pas mettre cette règle en premier, il faut d'abord coder avant de tester
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  14. #174
    Membre habitué
    Inscrit en
    Octobre 2004
    Messages
    83
    Détails du profil
    Informations forums :
    Inscription : Octobre 2004
    Messages : 83
    Points : 132
    Points
    132
    Par défaut
    Citation Envoyé par shenron666 Voir le message
    tu ne peux pas mettre cette règle en premier, il faut d'abord coder avant de tester
    ok donc coder le test puis tester tester tester

  15. #175
    Membre actif Avatar de DrHelmut
    Homme Profil pro
    Software craftsman - JS, Java...
    Inscrit en
    Octobre 2005
    Messages
    112
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Software craftsman - JS, Java...
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2005
    Messages : 112
    Points : 215
    Points
    215
    Par défaut
    Citation Envoyé par shenron666 Voir le message
    tu ne peux pas mettre cette règle en premier, il faut d'abord coder avant de tester
    oui et non, avec le TDD

  16. #176
    Membre Expert

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Points : 5 724
    Points
    5 724
    Par défaut
    Citation Envoyé par DrHelmut Voir le message
    oui et non, avec le TDD
    Et l'ATDD
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  17. #177
    Membre averti
    Inscrit en
    Août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 307
    Points : 378
    Points
    378
    Par défaut
    Citation Envoyé par DrHelmut Voir le message
    oui et non, avec le TDD
    Je ne crois pas que le TDD demande de tester avant de coder, je crois plutôt que le TDD demande d'écrire le code de test avant d'ecrire le code à tester.
    Mais on ne peut tester (comprendre executer le code de test) avant d'avoir écrire le code principale

  18. #178
    Membre Expert

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Points : 5 724
    Points
    5 724
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    Mais on ne peut tester (comprendre executer le code de test) avant d'avoir écrire le code principale
    Tester ce n'est pas simplement 'exécuter du code' c'est aussi, avec l'ATDD d'autant plus, spécifier notamment les détails fonctionnels et techniques.

    Donc oui on écrit un test au sens ATDD ou TDD (qui là pour le coup est aussi du code) avant d'écrire une ligne de code de production

    La qualification/ou test d'acceptation effectivement ne peut être réalisé avant d'avoir écrit tout le code d'une fonction
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

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, 08h53
  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, 10h55
  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, 19h18
  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, 18h35
  5. Réponses: 0
    Dernier message: 30/06/2009, 12h22

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