Affichage des résultats du sondage: Quelles sont les habitudes de programmation qui caractérisent un bon développeur ?

Votants
196. Vous ne pouvez pas participer à ce sondage.
  • Coder intensivement

    22 11,22%
  • Écrire du code simple et être à l’affût de simplifications

    163 83,16%
  • Ne pas optimiser le code au début

    63 32,14%
  • Se concentrer sur la tâche la plus importante

    53 27,04%
  • Tout documenter et commenter

    64 32,65%
  • Faire des pauses régulièrement

    57 29,08%
  • Maîtriser parfaitement ses outils

    58 29,59%
  • Utiliser les lignes de commandes plutôt que les interfaces graphiques

    22 11,22%
  • Écrire du code lisible et compréhensible

    152 77,55%
  • Lire les codes source des projets

    44 22,45%
  • Utiliser un EDI performant

    37 18,88%
  • Corriger les bogues avant d’ajouter de nouvelles fonctionnalités

    81 41,33%
  • Écrire des tests unitaires

    87 44,39%
  • Taper sur Google et être actif sur les forums techniques

    40 20,41%
  • Suivre régulièrement les technologies utilisées et leurs alternatives

    69 35,20%
  • Parcourir toute la documentation

    26 13,27%
  • Autres (à préciser dans les commentaires)

    11 5,61%
  • Pas d'avis

    1 0,51%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 4 PremièrePremière 1234 DernièreDernière
  1. #41
    Membre habitué
    Inscrit en
    octobre 2005
    Messages
    91
    Détails du profil
    Informations forums :
    Inscription : octobre 2005
    Messages : 91
    Points : 129
    Points
    129

    Par défaut

    Citation Envoyé par ddoumeche Voir le message
    Donc à chaque fois que tu relivres une application, tu testes toutes, absolument toutes les fonctionnalités, à la main ?
    Tu écrits des tests unitaires pour toutes tes fonctionnalités ? Ça revient quelque part à écrire "deux fois" l'application.

    Je teste tout ce qui est lien direct avec mon dev et je fais tester par un tiers + client final si il y'a.

    Avec l'inté continue en plus si le projet est important.

  2. #42
    Candidat au Club
    Inscrit en
    novembre 2002
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : novembre 2002
    Messages : 4
    Points : 4
    Points
    4

    Par défaut

    Je suis d'accord avec la première moitié de la liste. Cependant, j'aurais aimé voir :

    .) Considérer la robustesse d'une application comme une priorité.

    .) De flexibilité de code. (MVC, N-Tier, ne pas etre oubligé de tout réécrire de A-Z, et tout d'un coup, si l'on change d'interface, de DB, de plateform.)

    .) De capacité a produire des solutions avec une grande durée de vie.

    .) De globalisation. (combien de fois j'ai vue des solutions pour grande entreprise, avec du hard-codage, des centaines de fichiers de parametres pelle-mèles, des shares qui pointent n'importe ou, rendant la solution très difficile a administrer)

    .) De gestion des erreurs. (trop souvent minimisé, et implenté en fin de projet, plutot qu'en début)

    Au plaisir,
    Voila.

  3. #43
    Membre expérimenté
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    mars 2005
    Messages
    1 027
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2005
    Messages : 1 027
    Points : 1 599
    Points
    1 599

    Par défaut

    Citation Envoyé par fodger
    et tu le sort comment ton indicateur qualité (ou alors tu le sort pas du tout, quand même pas !) ?
    Les outils d'intégration continue sont là pour ça (Jenkins, sonar...).
    Et bien justement, sonar, pour ne citer que lui mesure une partie de l'indicateur qualité avec le code coverage.

    Citation Envoyé par fodger
    Citation Envoyé par popo
    Mon nouveau test sert à garantir que le bug est bien corrigé et les tests déjà existants m'assurent que je n'ai rien cassé ailleurs.
    Il ne garantit en rien que tu ais écrit un code de qualité, intelligent et que tu ais réellement couvert toutes les situations.
    Le test par un tiers avec de l'intégration continue restent très efficaces.
    En effet, il ne garantissent en rien la qualité du code. Mais j'ai également évoqué SRP et le nommage entres autres, qui même s'il ne font pas tout permettent néanmoins d'améliorer les choses.
    Quand a couvrir toute les situations, c'est justement le rôle du test unitaire... quand un cas n'est pas couvert, on écrit un nouveau test, on corrige et se base sur les tests existant pour la non régression. Après si pour une même fonctionnalité, il y a trop souvent un nouveau cas de bug découvert, c'est un bon indicateur pour savoir que soit l'analyse ne correspond pas au besoin (bref qu'on a pas compris ce qu voulais le client), soit qu'elle a été baclée. Dans les deux cas il faudra revoir le client. Et en passant, le test effectué par un tiers non plus ne garantit ni la qualité du code ni la couverture de tous les cas. Si un cas a été oublié dans l'analyse, ce cas sera oublié aussi bien dans les tests unitaires, que dans les tests manuels ou par les robots de tests.

    Pyramidev, il y a de nombreuse manières d'éviter un commentaire.
    Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.
    Pour le cas des chaines de format je suis d'accord qu'un commentaire peut être utile. Quoique, certain diraient qu'on peux également renvoyer une exception et expliquer le format à l'intérieur.
    Pour le findIndex, là je ne suis pas d'accord. En règle général, il existe déjà de telles méthodes dans le framework ou dans les librairies et les développeurs savent que ce genre de méthodes est sensée renvoyer l'indice de l'élément à partir de 0, ou -1 si non trouvé.
    Pour le findElement, là encore, je ne suis pas d'accord. Ton Objet est dépendant d'un autre qui a potentiellement sa vie propre et tu n'ai pas en mesure de garantir sa longévité. Pour moi cette classe ne respecte ni principe d'encapsulation, ni le SRP. Il te faut une classe dédiée pour la gestion des configurations, une classe qui contiendra sa propre liste et dont la méthode findElement renverra une copie de l'item.

  4. #44
    Membre habitué
    Inscrit en
    octobre 2005
    Messages
    91
    Détails du profil
    Informations forums :
    Inscription : octobre 2005
    Messages : 91
    Points : 129
    Points
    129

    Par défaut

    Citation Envoyé par popo Voir le message
    Et bien justement, sonar, pour ne citer que lui mesure une partie de l'indicateur qualité avec le code coverage.


    En effet, il ne garantissent en rien la qualité du code. Mais j'ai également évoqué SRP et le nommage entres autres, qui même s'il ne font pas tout permettent néanmoins d'améliorer les choses.
    Quand a couvrir toute les situations, c'est justement le rôle du test unitaire... quand un cas n'est pas couvert, on écrit un nouveau test, on corrige et se base sur les tests existant pour la non régression. Après si pour une même fonctionnalité, il y a trop souvent un nouveau cas de bug découvert, c'est un bon indicateur pour savoir que soit l'analyse ne correspond pas au besoin (bref qu'on a pas compris ce qu voulais le client), soit qu'elle a été baclée. Dans les deux cas il faudra revoir le client. Et en passant, le test effectué par un tiers non plus ne garantit ni la qualité du code ni la couverture de tous les cas. Si un cas a été oublié dans l'analyse, ce cas sera oublié aussi bien dans les tests unitaires, que dans les tests manuels ou par les robots de tests.

    Pyramidev, il y a de nombreuse manières d'éviter un commentaire.
    Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.
    Pour le cas des chaines de format je suis d'accord qu'un commentaire peut être utile. Quoique, certain diraient qu'on peux également renvoyer une exception et expliquer le format à l'intérieur.
    Pour le findIndex, là je ne suis pas d'accord. En règle général, il existe déjà de telles méthodes dans le framework ou dans les librairies et les développeurs savent que ce genre de méthodes est sensée renvoyer l'indice de l'élément à partir de 0, ou -1 si non trouvé.
    Pour le findElement, là encore, je ne suis pas d'accord. Ton Objet est dépendant d'un autre qui a potentiellement sa vie propre et tu n'ai pas en mesure de garantir sa longévité. Pour moi cette classe ne respecte ni principe d'encapsulation, ni le SRP. Il te faut une classe dédiée pour la gestion des configurations, une classe qui contiendra sa propre liste et dont la méthode findElement renverra une copie de l'item.
    C'est tout l'intérêt de faire appel à un tiers - n'ayant pas de lien direct avec ton dev - pour tester. Le défaut récurrent chez le dev étant lors de ses tests de ne pas se mettre dans la peau d'un utilisateur "lambda".

    Les tests unitaires peuvent être intéressants pour garantir l'intégrité de données, mais le test unitaire technique à tout va non, non et encore non.
    C'est très long, fastidieux, c'est lourd.

    Plutôt que de sauter et de se rassurer avec le tout test unitaire technique, on a plus intérêt à se concentrer sur la maitrise réelle du langage tout en appliquant les bonnes pratiques. L'impact est bien plus important sur la qualité intrinsèque et plus globale.

  5. #45
    Membre expérimenté Avatar de ddoumeche
    Homme Profil pro
    Développeur J2EE
    Inscrit en
    octobre 2007
    Messages
    656
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Eure (Haute Normandie)

    Informations professionnelles :
    Activité : Développeur J2EE

    Informations forums :
    Inscription : octobre 2007
    Messages : 656
    Points : 1 436
    Points
    1 436

    Par défaut

    Citation Envoyé par fodger Voir le message
    Tu écrits des tests unitaires pour toutes tes fonctionnalités ? Ça revient quelque part à écrire "deux fois" l'application.

    Je teste tout ce qui est lien direct avec mon dev et je fais tester par un tiers + client final si il y'a.

    Avec l'inté continue en plus si le projet est important.
    Pour le maximum de fonctionnalités, en effet même si les tests unitaires sont relativement simples comparés à du code métier.

    Mais les test unitaires :
    • ne sont pas plus long à écrire que de déboguer son code a la main
    • m'obligent a conserver une architecture simple et testable
    • me font détecter rapidement les régressions
    • surtout s'ils sont fait automatiquement
    • permettent d'éviter qu'un nouveau venu ne casse tout en voulant bien faire


    Mais cela n'empêche pas les tests fonctionnels à la fin de la livraison.

    Bref cela oblige a un changement d'habitudes.

    Citation Envoyé par popo Voir le message
    Et bien justement, sonar, pour ne citer que lui mesure une partie de l'indicateur qualité avec le code coverage.
    Je n'ai pas vu encore l’intérêt de tel outils mis à part pour les équipes comprenant des programmeurs débutants, pour qui une relecture de code devrait s'imposer.
    Sont-ils vraiment adaptés à tous les projets ?

  6. #46
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 469
    Points : 2 084
    Points
    2 084

    Par défaut

    Citation Envoyé par popo Voir le message
    Il te faut une classe dédiée pour la gestion des configurations
    Pourrais-tu développer ce point ?

    Je vais prendre le scénario suivant :
    Une certaine configuration est lue en début de programme depuis un fichier (s'il n'existe pas, le fichier est créé).
    En cours d'exécution du programme, la configuration peut changer suite à des actions de l'utilisateur.
    Lors d'une sauvegarde, la configuration est sauvegardée dans le fichier.

    Pour implémenter cela en C++, j'ai pensé à la solution suivante :
    Vers le début du programme, je construis un objet de type Config qui représente le contenu du fichier.
    Ensuite, en cours d'exécution du programme, dans les objets que je construis dont le comportement dépend de la config, je sauvegarde dans chaque objet un handler qui permet d'accéder à l'objet config en lecture, par exemple un const Config& ou un std::reference_wrapper<const Config>. D'où mon exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    /*!
     * \param config Cet objet doit exister tant que Foo existe.
     */
    Foo(const Config& config);
    Quand la config sera modifiée, la prochaine fois que Foo lira la config, il lira la config à jour.
    En fin de programme, je laisse se détruire tous les objets encore vivants qui lisaient la config.
    Ensuite, je laisse cet objet de type Config se détruire.
    (En C++, dans pas mal de cas, les objets sont détruits dans l'ordre inverse de leur création.)

    Remarques :
    • Pour respecter le principe de la ségrégation d'interface (ISP), Config pourrait hériter de différentes petites interfaces.
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      /*!
       * \param config Cet objet doit exister tant que Bar existe.
       */
      Bar(const InterfaceImplementeeParConfig& config);
      Je n'ai pas trop insisté dessus pour que l'exemple reste simple. De toute façon, ça ne change pas la gestion de la mémoire.
    • Dans chaque objet, j'aurais pu mettre un std::shared_ptr<const Config> qui gère la mémoire de l'objet via un comptage de références. Le dernier qui n'utilise plus la config se charge alors de la détruire. En plus, cela évite de documenter à propos de la gestion de la mémoire. Mais cette solution me semble inappropriée dans cet exemple car je sais déjà quand l'objet de type Config devra être détruit. Ici, le comptage de références serait un surcoût inutile.

  7. #47
    Membre expérimenté
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    mars 2005
    Messages
    1 027
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2005
    Messages : 1 027
    Points : 1 599
    Points
    1 599

    Par défaut

    Citation Envoyé par fodger
    C'est tout l'intérêt de faire appel à un tiers - n'ayant pas de lien direct avec ton dev - pour tester. Le défaut récurrent chez le dev étant lors de ses tests de ne pas se mettre dans la peau d'un utilisateur "lambda".
    Je suis d'accord pour dire qu'un développeur n'arrive pas souvent à se mettre dans la peau d'un utilisateur lambda.
    Il n'empêche que quelque soit le tiers qui teste, celui-ci va se baser sur l'analyse pour savoir si un cas qu'il rencontre est correct ou non.
    Si ce tiers tombe sur un cas non prévu, il va le dire au dire au développeur (et si je suis ce développeur, je fais d'abord écrire une méthode de test avant de corriger).
    Relis bien, je n'ai écrit nulle part qu'un test fonctionnel est inutile, c'est toi qui a interprété.
    Evidemment que les tests fonctionnels sont important puisque, justement, ils permettent de lever les loups que le développeur n'a pas vu.

    Citation Envoyé par fodger
    Les tests unitaires peuvent être intéressants pour garantir l'intégrité de données, mais le test unitaire technique à tout va non, non et encore non.
    C'est très long, fastidieux, c'est lourd.
    Si faire un test unitaire est fastidieux et/ou lourd, cela signifie en général que le code de production l'est également.
    Comme le dis si bien ddoumeche :
    Citation Envoyé par ddoumeche
    Mais les test unitaires :
    •ne sont pas plus long à écrire que de déboguer son code a la main
    •m'obligent a conserver une architecture simple et testable
    •me font détecter rapidement les régressions
    •surtout s'ils sont fait automatiquement
    •permettent d'éviter qu'un nouveau venu ne casse tout en voulant bien faire
    Citation Envoyé par fodger
    Plutôt que de sauter et de se rassurer avec le tout test unitaire technique, on a plus intérêt à se concentrer sur la maitrise réelle du langage tout en appliquant les bonnes pratiques. L'impact est bien plus important sur la qualité intrinsèque et plus globale.
    ça fait deux fois que tu me sors l'argument du "tout tester unitairement ne suffit pas".
    Et donc, ça fait deux fois que je constate que tu ne prends pas le temps tout lire. Je ne prendrai donc pas la peine de tout réécrire.

    Citation Envoyé par Pyramidev
    Citation Envoyé par popo
    Il te faut une classe dédiée pour la gestion des configurations
    Pourrais-tu développer ce point ?
    Je n'ai jamais fait de C++ donc je ne sais pas si cela représente une difficulté ou non.
    En tout cas, je pensais à simple singleton encapsulant l'objet Config.

  8. #48
    Membre à l'essai
    Homme Profil pro
    Consultant informatique
    Inscrit en
    janvier 2013
    Messages
    19
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : janvier 2013
    Messages : 19
    Points : 24
    Points
    24

    Par défaut Commenter, commenter, commenter ...

    Un code est de bonne qualité si et seulement s'il est Bien commenté !
    Avant même d'écrire le code, je le commente; cela a trois avantages:
    1) éviter des oublis, préparer le futur codage
    2) permettre la mise à jour plus facile du code y compris par un autre développeur
    3) entrer rapidement et de façon globale dans un code, ce qui facilite les optimisations si nécessaire

  9. #49
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 469
    Points : 2 084
    Points
    2 084

    Par défaut

    Citation Envoyé par popo Voir le message
    En tout cas, je pensais à simple singleton encapsulant l'objet Config.
    En effet, c'est une autre solution.
    Je ne suis pas un grand fan des singletons, mais c'est vrai que ça marche.

    Citation Envoyé par popo Voir le message
    Pour ton exempler avec "FaireUnTrucA, FaireUnTrucB". Il suffit de déclarer ces méthodes en dessous de uneFonction, il aura tout directement sous les yeux.
    Je modifie légèrement l'exemple. Je vais prendre le cas particulier de Java :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    public void uneFonction()
    {
        Foo foo1 = null;
        Foo foo2 = faireUnTrucA(foo1);
        Bar bar1 = null;
        Bar bar2 = faireUnTrucB(bar1);
        faireUnTrucC(foo1, foo2, bar1, bar2);
    }
    private final Foo faireUnTrucA(Foo foo1)
    {
       foo1 = du code
       du code
       du code
       return du code
    }
    private final Bar faireUnTrucB(Bar bar1)
    {
       bar1 = du code
       du code
       return du code
    }
    private final void faireUnTrucC(Foo foo1, Foo foo2, Bar bar1, Bar bar2)
    {
       du code
       du code
       du code
       du code
       du code
    }
    Je pense que le même bout de code sera plus lisible et plus commode à maintenir sous cette forme :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    public void uneFonction()
    {
        // faire un truc A
       Foo foo1 = du code
       du code
       du code
       Foo foo2 = du code
    
        // faire un truc B
       Bar bar1 = du code
       du code
       Bar bar2 = du code
    
        // faire un truc C
       du code
       du code
       du code
       du code
       du code
    }
    Les autres inconvénients qui me viennent à l'esprit sur le code avec les fonctions faireUnTrucX ne sont pas vrais pour tous les langages.

    Par exemple, en C++, le temps de recompilation risque d'être en moyenne plus long dans la solution avec les fonctions faireUnTrucX membres de la classe.
    En C++, souvent, on déclare les fonctions dans un fichier ".h" et on les implémente dans un fichier ".cpp". Alors, il y a de fortes chances que les fonctions membres faireUnTrucX soient déclarées dans le ".h".
    Quand on ne modifie qu'un fichier ".cpp", pour recompiler le projet, on a juste besoin de recompiler ce ".cpp". Par contre, quand on modifie un ".h", il faut recompiler tous les ".cpp" qui incluent, directement ou indirectement ce ".h", ce qui est plus long.
    Dans la solution avec les fonctions membres faireUnTrucX, si on modifie le nom ou la liste des paramètres d'une des fonctions membres faireUnTrucX, il faut modifier sa déclaration dans le ".h", donc modifier le ".h".
    Dans l'autre solution, par contre, on ne fait que changer le code de uneFonction dans le ".cpp".

  10. #50
    Membre expérimenté
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    mars 2005
    Messages
    1 027
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2005
    Messages : 1 027
    Points : 1 599
    Points
    1 599

    Par défaut

    Pyramidev.
    Encore une fois, je ne connais pas le C++ alors je me trompe peut être.
    Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
    L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp
    Comme une interface (c'est du Delphi cette fois) :
    Code Delphi : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    IMyInterface = interface
    ['{D653EBB8-78FD-4F69-A771-B659449A4872}']
      procedure UneMethode;
    end;
     
    TConfigurationSerializer(TInterfacedObject, IMyInterface)
    private
      procedure FaireUnTrucA;
      procedure FaireUnTrucB; 
    public
      procedure UneMethode;
    end;

    Citation Envoyé par olibiobus Voir le message
    Un code est de bonne qualité si et seulement s'il est Bien commenté !
    Avant même d'écrire le code, je le commente; cela a trois avantages:
    1) éviter des oublis, préparer le futur codage
    2) permettre la mise à jour plus facile du code y compris par un autre développeur
    3) entrer rapidement et de façon globale dans un code, ce qui facilite les optimisations si nécessaire
    C'est tout le contraire selon moi, un code de bonne qualité est un code où tout est limpide sans avoir besoin de commentaires
    1) Pour préparer le futur codage on a jamais fait mieux que le papier et le crayon (et les commentaire n'empêchent pas les oublis). Le mieux est de le mettre au propre pour les futurs collègues qui reprendront le code (y compris nous même).
    2) La plupart des développeurs effectuant de la maintenance ou une correction vont modifier le code, voire le déplacer, et en grande majorité (en tout cas c'est ce que j'ai pu constater) le commentaire restera tel quel. On aboutit à un commentaire complètement hors de propos à l'endroit où il est resté et ça ne facilite pas vraiment les choses.
    3) Se reporter à mon commentaire 1. Car si ce document existe et qu'il est facile d'accès, le prochain développeur n'aura aucun mal à s'y retrouver.

  11. #51
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 744
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 744
    Points : 5 441
    Points
    5 441

    Par défaut

    Citation Envoyé par popo Voir le message
    Encore une fois, je ne connais pas le C++ alors je me trompe peut être.
    Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
    L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp
    Oui et non. Toute fonction doit avoir été déclarée avant d'être appelée.

    Tu peux à la rigueur organiser l'ordre des fonctions dans ton cpp pour éviter d'avoir une déclaration redondante (en imposant un ordre de lecture du bas niveau vers le haut niveau), ou tu peux placer la déclaration en haut du cpp plutôt que dans le header. Mais tu es quand même en général obligé de te farcir des déclarations distinctes à cause de ce modèle de compilation anachronique, datant d'une époque où l'AST ne pouvait pas tenir en mémoire.

    Coder en C++ c'est comme se faire un gang-bang dans une maison de retraite : ça sent la naphtaline et tu risques de contracter une saleté.

  12. #52
    Expert confirmé
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    2 206
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 206
    Points : 4 892
    Points
    4 892

    Par défaut

    Pour préciser ce que dit DonQuiche , on peut effectivement mettre des "forward declarations" en premier/ haut dans son fichier source .cpp.
    Et ensuite, coder leurs définitions où on veut dans ce fichier.

    Et une autre méthode qui fonctionne avec les fonctions/ procédures mais pas avec une classe/ méthodes.
    On peut faire 2 entêtes .h: une XXX.h et une XXX_private.h

    Dans l'entête XXX.h on place tout ce qui est public.
    Dans l'entête XXX_private.h, on fait un #include "XXX.h" et on y ajoute tout ce qui est privé

    Et dans le source XXX.c on fait un #include "XXX_private.h"

  13. #53
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 469
    Points : 2 084
    Points
    2 084

    Par défaut

    Dans un programme, les commentaires qui me semblent les plus importants sont ceux qui décrivent, pour chaque classe, en quelques lignes, quel est le rôle de cette classe dans le programme. Quand un nouveau développeur débarque sur le projet, ça lui permet d'être moins perdu les premiers temps.

    Citation Envoyé par popo Voir le message
    Est-ce qu'on est obligé de déclarer chacune des fonctions dans le fichier .h ?
    L'idée est de déclarer uniquement les méthodes publiques dans le fichier .h et de découper dans le fichier .cpp
    Dans ce cas, une solution est d'utiliser la méthode dite du pointeur opaque / de l'idiome pimpl.
    En gros, on a une classe FooImpl qu'on déclare et qu'on définit entièrement dans Foo.cpp.
    Dans Foo.h, on définit une autre classe, Foo, qui ne contient qu'un pointeur vers FooImpl et des méthodes publiques. Dans Foo.cpp, on définit ces méthodes de Foo.
    Alors, chaque fois qu'on touche à un détail d'implémentation, on n'est pas obligé de toucher à Foo.h. Pour le temps de recompilation, c'est super.
    Mais le code est un peu plus lourd à écrire et il y a un petit coût supplémentaire à l'exécution car on a ajouté une indirection entre les méthodes de Foo et les données. Donc la méthode dite du pointeur opaque n'est pas systématiquement utilisée en C++.

  14. #54
    Membre averti
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    295
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 295
    Points : 321
    Points
    321

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    foetus,
    On n'a pas interprété utiliser les lignes de commandes plutôt que les interfaces graphiques (GUI) de la même manière.
    Je l'avais compris comme, par exemple, utiliser SVN en ligne de commande au lieu d'utiliser un logiciel comme Tortoise SVN.
    Par contre, pour un outil que l'on code soi-même, j'entends qu'on n'a pas toujours le temps de coder une interface graphique, ce qui, de toute façon, n'est pas incompatible avec le fait de pouvoir utiliser l'outil directement en ligne de commande.


    Ce n'est pas une question de lisibilité.
    Dans mon exemple avec if(entier1 + entier2 < entier3), quand on arrive à cette ligne, on peut connaître directement la valeur de ces trois entiers, par exemple en passant la souris dessus (avec un bon débogueur).
    Par contre, dans mon autre exemple avec if(uneFonctionQuiRetourneUnEntier(param1) + uneFonctionQuiRetourneUnEntier(param2) < uneFonctionQuiRetourneUnEntier(param3)), pour connaître les valeurs des entiers retournés, il faut entrer dans la fonction, ce qui est moins pratique.
    Je voulais rebondir là dessus, je sais pas pour les autres debugers/langages mais en C++ avec VisualStudio (il me semble valable pour C# et VB.Net) tu as l'information des valeurs renvoyées par chacune des méthodes. Donc personnellement je suis moins catégorique: j'aime pas introduire des variables locales qui ne "servent à rien" mais si l'expression commence à être complexe c'est que de toute manière le code sera difficile à lire; dans ce cas j'introduis des variables intermédiaires plus dans l'optique d'améliorer la compréhension du code.

  15. #55
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 469
    Points : 2 084
    Points
    2 084

    Par défaut

    Citation Envoyé par CedricMocquillon Voir le message
    Je voulais rebondir là dessus, je sais pas pour les autres debugers/langages mais en C++ avec VisualStudio (il me semble valable pour C# et VB.Net) tu as l'information des valeurs renvoyées par chacune des méthodes.
    Je viens de tester avec Visual C++ 2010 Express avec la ligne de code suivante :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    if(carre(3) + carre(4) == carre(5))
    J'ai fais trois fois "Pas à pas détaillé"-"Pas à pas sortant".
    Après chaque "Pas à pas sortant", je pouvais voir dans l'IDE la valeur retournée par la fonction carre de laquelle je suis sorti. Mais cette valeur n'était plus visible à partir du "Pas à pas détaillé" suivant.
    Par contre, quand je stocke des résultats dans des variables locales "inutiles", je peux les visualiser tant qu'elles n'ont pas été dépilées.

  16. #56
    Membre averti
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    295
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 295
    Points : 321
    Points
    321

    Par défaut

    Effectivement, je ne sais pas depuis combien de temps c'est disponible dans les versions de visual (2010 c'est vieux quand même!)
    Sur la version 2015 (disponible en version express ou community), le code suivant:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    int foo() {
    	return 10;
    }
    
    int bar() {
    	return 20;
    }
    
    int main() {
    	auto result = foo() + bar();
    }
    avec break point sur la ligne "auto result" puis F10 me donne bien toutes les infos:
    Nom : Capture.PNG
Affichages : 192
Taille : 16,4 Ko

  17. #57
    Membre confirmé Avatar de zulad
    Homme Profil pro
    creatif
    Inscrit en
    juin 2007
    Messages
    696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : creatif

    Informations forums :
    Inscription : juin 2007
    Messages : 696
    Points : 487
    Points
    487

    Par défaut

    Je crois que le café n'est pas si bon que ça pour un développeur quand il prend une pause. Par contre, je pense que dans ce métier on se doit de faire plus de pause que dans d'autres...
    Aucun de nous n'est seul, Même l'air que nous expirons est inspirés par d'autres, Le soleil qui brille pour moi, brille pour mon voisin aussi, Ainsi tout est lié en se monde, Ainsi je suis lié à mon ami tout comme je suis lié à mon ennemis, Ainsi il n ya pas de différence ente mon ami et moi ainsi il n ya pas de différence entre mon ennemi et moi tout est lié en ce monde

  18. #58
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 450
    Points : 3 386
    Points
    3 386

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Je pense que le même bout de code sera plus lisible et plus commode à maintenir sous cette forme :
    Pour une petite fonction ca peut passer, mais après c'est juste immonde!
    Je me suis déjà retrouver à devoir modifier une fonction de plus de 3500 lignes...
    Ben franchement j'aurais mis beaucoup moins de temps si c'était éclaté en 10 méthodes elles même divisé en 10 méthodes.

  19. #59
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    469
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 469
    Points : 2 084
    Points
    2 084

    Par défaut

    Citation Envoyé par micka132 Voir le message
    Je me suis déjà retrouver à devoir modifier une fonction de plus de 3500 lignes...
    Ben franchement j'aurais mis beaucoup moins de temps si c'était éclaté en 10 méthodes elles même divisé en 10 méthodes.
    Entièrement d'accord. Moi non plus, je n'aime pas les fonctions qui font 2 km.

    A part ça, parmi les cas où je suis en faveur des commentaires, j'avais oublié de mentionner les cas suivants :
    • De manière générale, expliquer un choix fait dans le code.
      Par exemple, si on fait tel truc bizarre dans le code, c'est pour contourner tel bogue de tel IDE.
      Autre exemple : Si on a implémenté telle classe de telle manière qui est moins flexible que telle autre manière, c'est pour des raisons de performance de tel programme.
    • Pour une classe ou une fonction qui n'est pas la plus adaptée (flexibilité, performance…) dans un certain contexte, conseiller d'utiliser telle autre classe ou fonction dans ce contexte.
      Par exemple, une fois, dans une classe abstraite, j'avais une fonction foo qui faisait une certaine opération, une fonction bar qui faisait une autre opération et une fonction foobar qui faisait ces deux opérations à la fois. J'ai écrit en commentaire pour signaler à l'utilisateur de la classe qu'il était préférable d'appeler directement foobar plutôt que, successivement, foo et bar, car c'était plus performant avec certaines classes dérivées.
    • Pour une classe commune à plusieurs applications, écrire qu'il ne faut pas ajouter de variable membre à cette classe, car elle est très utilisée dans tel programme qui a été optimisé pour consommer peu de mémoire.
    • Pour une classe commune à plusieurs applications qui ne compilent pas forcément avec le même environnement, écrire qu'elle doit pouvoir compiler sur tel programme qui n'a pas accès à tel environnement, qui compile avec tel IDE qui ne supporte pas certaines fonctionnalités récentes du langages ou qui a tel bogue à contourner…


    PS : Dans le pseudocode Java que j'avais écrit quelques messages plus haut, je me suis gouré : j'avais oublié que les poignées étaient passées par valeur (et pas par référence) en paramètre de fonction.

  20. #60
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 787
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 787
    Points : 20 275
    Points
    20 275

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Entièrement d'accord. Moi non plus, je n'aime pas les fonctions qui font 2 km.
    (.../...)
    ça dépend. Ce que j'ai pas mal pratiqué en bancaire, ce sont des traitements par nature très linéaires, ou tu fais des choses au kilomètre, que tu ne fais nulle part ailleurs, et qui sont juste en séquence. Il y a zéro valeur ajoutée à découper tout ça en rondelles.

    Mais c'est un cas particulier. Le cas général, avec plein de SI(pleindelignes)SINON(pleindautreslignes), lui nécessite un découpage fréquent en petits morceaux.
    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.

Discussions similaires

  1. Quelles sont les phases d'un programme?
    Par patchi225 dans le forum Débutant
    Réponses: 3
    Dernier message: 01/07/2011, 18h33
  2. [TASM] Quelles sont les erreurs dans ce programme ?
    Par S.H dans le forum x86 16-bits
    Réponses: 7
    Dernier message: 25/12/2007, 23h05
  3. quelles sont les SSII qui font du forfait
    Par coax81 dans le forum SSII
    Réponses: 11
    Dernier message: 12/10/2007, 15h49
  4. Réponses: 6
    Dernier message: 03/07/2007, 11h34

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