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

VB.NET Discussion :

[VB.Net] Quels conseils pour une programmation stylée ?


Sujet :

VB.NET

  1. #1
    Membre actif
    Inscrit en
    Août 2006
    Messages
    381
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 381
    Points : 252
    Points
    252
    Par défaut [VB.Net] Quels conseils pour une programmation stylée ?
    Bonjour à tous,

    j'ai développé une classe Polynôme.
    J'aimerais avoir vos avis sur cette classe, ce que vous pensez du style de programmation, des tests sur les références null (car j'ai un peu de mal comment les utiliser efficacement, des exceptions, des asserts etc.
    Pourriez-vous me donner de précieux de conseils que je puisse améliorer mon code ?

    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
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
     
    using System;
    using System.Collections.Generic;
    using System.Text;
     
    namespace MyLibrary.Mathematic
    {
      class Polynome
      {
        /// <summary>
        /// Coefficients du polynôme
        /// </summary>
        private double[] m_Coefficient = null;
        public double[] Coefficient
        {
          get { return m_Coefficient; }
          set 
          {
             if (m_Coefficient != value)
              m_Coefficient = value;
          }
        }
     
        /// <summary>
        /// Constructeur
        /// </summary>
        /// <param name="ordre"></param>
        public Polynome(uint ordre)
        {            
           System.Diagnostics.Debug.Assert((ordre > 0 ), "L'ordre"
            + " doit être supérieur à 0");
           if (ordre >0)
           {
              double[] coeff = new double[ordre+1];
              m_Coefficient = coeff;
           }
           else throw new ArgumentException("L'ordre doit être supérieur à 0");
        }
     
        /// <summary>
        /// Constructeur
        /// </summary>
        /// <param name="coeff"></param>
        public Polynome(double[] coeff)
        {
           System.Diagnostics.Debug.Assert((coeff !=null), "La référence"
            + " du coefficient est nulle");
           if (coeff != null)
              m_Coefficient = coeff;
           else throw new ArgumentException("Le paramètre n'est pas valide");
         }
     
         /// <summary>
         /// Calcul d'une valeur à partir du polynôme
         /// </summary>
         /// <param name="value"></param>
         /// <returns></returns>
         public double CalculValueFromPoly(double valueOfX)
         {
            double varTemp = 0;
     
            for (int i = 0; i < m_Coefficient.Length; i++)
            {
               varTemp += m_Coefficient[i]*System.Math.Pow(valueOfX,i);
            }
            return varTemp;
         }
     
         /// <summary>
         /// Retourne la formule
         /// </summary>
         /// <returns></returns>
         public override String ToString()
         {
            return ConstructFormule(m_Coefficient); ;
         }
     
         /// <summary>
         /// Construction de la formule
         /// </summary>
         /// <returns>Formule</returns>
         private string ConstructFormule(double[] coeff)
         {
            System.Diagnostics.Debug.Assert(coeff != null, "Les"
             + " coefficients sont nuls");
            if (coeff != null)
            {
              string formule = "";
              for (int i = 0; i < coeff.Length; i++)
              {
                 if (i != 0)
                   formule = " + " + formule;
                 formule = coeff[i].ToString() + "X^" + i.ToString() + formule;
               }
               return formule;
            }
            else return null;
          }
       }
    }
    Merci.

  2. #2
    Invité
    Invité(e)
    Par défaut
    Personnellement je ne trouve pas grand chose à dire sur ta maniere de coder cette classe.

  3. #3
    Rédacteur
    Avatar de Thomas Lebrun
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    9 161
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 9 161
    Points : 19 434
    Points
    19 434
    Par défaut
    Pas mal sauf pour la dernière méthode: elle doit renvoyé une String mais dans le cas où coeff == null, tu renvoies null, ce qui n'est pas très logique.....
    Renvoit String.Empty (par exemple) à la place, ce sera mieux

  4. #4
    Membre actif
    Inscrit en
    Août 2006
    Messages
    381
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 381
    Points : 252
    Points
    252
    Par défaut
    Je ne connaissais pas.
    Merci.

    Pas mal
    Personnellement je ne trouve pas grand chose à dire sur ta maniere de coder cette classe
    Ah ouais ? C'est cool ça.

    Même les assert ? Ca ne fait pas trop ?
    Et j'ai raison de lancer des ArgumentException ?
    Est-ce que ce type d'exception doit être lancé dès qu'un argument n'est pas valable ?

    Et supposons qu'une opération doit être fait tel qu'une division.
    Vaut-il mieux faire:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    int a=0;
    int b=5;
    int c=0;
    if (a!=0)
        c=b/a;
    ou alors
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    int a=0;
    int b=5;
    int c=0;
    try {
        c=b/a;
    }
    catch (DivideByZeroException ex) {
    }
    Merci.

  5. #5
    Rédacteur
    Avatar de Thomas Lebrun
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    9 161
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 9 161
    Points : 19 434
    Points
    19 434
    Par défaut
    Citation Envoyé par Pilloutou
    Est-ce que ce type d'exception doit être lancé dès qu'un argument n'est pas valable ?
    Pour cela, il suffit de regarder la doc (MSDN), c'est le mieux

  6. #6
    Expert éminent
    Avatar de neguib
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    3 627
    Détails du profil
    Informations personnelles :
    Âge : 63
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2005
    Messages : 3 627
    Points : 7 879
    Points
    7 879
    Par défaut
    Attention Pilloutou, pour la gestion des exceptions, saches que tu peux te contenter de mettre certains bloc de ton code un try/catch qui te pemrettront simplement de récupérer l'exception levée nativement par le framework, par exemple la Classe DivideByZeroException existe et est déjà prévu par le framework sur certaines opérations mathématiques donc tu peux te contenter de gérer l'exception au plus haut niveau de ton code pour l'interface utilisateur notamment (l'exception est propagée par defaut.
    Pour ce qui est des Debug.Assert, je pense que c'est plutôt à destination des developpeurs qui auront à utiliser tes classes mais ce n'est pas forcement necessaire sauf pour toi-même pendant le stade du developpement du soft
    En gros tant que le framework a déjà une implémentation d'exceptino sur tes opérations tu peux laisser l'exception se propager jusqu'où c'est necessaire, sans quoi effectivement tu peux developper tes propres classes d'exceptions spécifiques qui hériteront d'Exception ou de ses dérivés selon l'explicitation nécessaires.
    Pour le bien de ceux qui vous lisent, ayez à coeur le respect du forum et de ses règles

  7. #7
    Membre expérimenté Avatar de Mose
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 143
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 143
    Points : 1 379
    Points
    1 379
    Par défaut
    C'est quoi un code stylé ?
    C'est dans quel sens du mot :
    1 - Qui est habitué à exécuter une fonction, un travail selon certaines règles.
    2 - Qui se caractérise par un style original

  8. #8
    Membre actif
    Inscrit en
    Août 2006
    Messages
    381
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 381
    Points : 252
    Points
    252
    Par défaut
    Citation Envoyé par neguib
    la Classe DivideByZeroException existe et est déjà prévu par le framework
    Mais selon vous lors d'une opération mathématique succeptible de lever une exception comme une division, vaut-il mieux tester le dividende:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    int a=0;
    int b=5;
    int c=0;
    if (a!=0)
        c=b/a;
    else Console.Writeln("Division par zéro interdite");
    ou placer un try/catch
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    int a=0;
    int b=5;
    int c=0;
    try {
        c=b/a;
    }
    catch (DivideByZeroException ex) {
    Console.Writeln("Division par zéro interdite");
    }
    Effectivement si je ne teste pas le dividende, l'exception ne sera pas remonté.

    Citation Envoyé par neguib
    donc tu peux te contenter de gérer l'exception au plus haut niveau de ton code pour l'interface utilisateur notamment (l'exception est propagée par defaut)
    Mais pour ça, il faut que je code ça de la façon suivante ?

    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
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
     
     
    class GUI {
       private Button bton;
       private Data data;
     
       GUI(){
          data=new Data();
          bton=new Button();
          bton.Click += new System.EventHandler(this.bton_Click);
       }
     
       private void bton_Click(object sender, EventArgs e)
            {
                try {
                     data.Calcul();
                }
                catch (DivideByZeroException ex){
                     MessageBox.Show(Division par zéro interdite);
                }
            }
    }
     
    class Data {
        int m_A=7;
        int m_B=8;
        float m_C=0;
        Operation oper = new Operation();
     
        public void Calcul() {
               m_C = oper.division(m_A,m_B);
        }
    }
     
    class Operation {
     
         public int division (int a,int b){
                return a/b;
         }
    }
    Mais est-il possible d'attraper des exceptions à un seul endroit du programme. Par exemple, est-il possible d'attraper toutes les exceptions DivideByZeroException dans une méthode qui serait par exemple une méthode de diagnostique ? Ou il n'y a qu'à l'aide d'un bloc try/catch ?

    Merci.

  9. #9
    Expert éminent
    Avatar de neguib
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    3 627
    Détails du profil
    Informations personnelles :
    Âge : 63
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2005
    Messages : 3 627
    Points : 7 879
    Points
    7 879
    Par défaut
    Mmmh ... Finalement la reflexion de Mose se revèle plus pertinente qu'il n'y pârait. Nous te conseillerons d'autant mieux, que tu nous livre le cadre conceptuel de ta classe Polynome. Si tu developpes une librairie de classes MyLibrary.Mathematic en vue d'utilisation comme dll pour toutes sortes d'appli, alors oui autant qu'elle lève toutes les exceptions necessaires après différentes conditionnelles . Je ne connais pas l'ampleur de ta dll MyLibrary.Mathematic , si elle est imposante, il ya des chances que tu te rendes compte que tu formules souvent des messages plus ou moins similaires. La création d'une blibliothèque de classes d'Exception spécifiques enrichira certainement ton espace de noms MyLibrary.Mathematic .
    Pour le bien de ceux qui vous lisent, ayez à coeur le respect du forum et de ses règles

  10. #10
    Membre actif
    Inscrit en
    Août 2006
    Messages
    381
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 381
    Points : 252
    Points
    252
    Par défaut
    Citation Envoyé par neguib
    Mmmh ... Finalement la reflexion de Mose se revèle plus pertinente qu'il n'y pârait
    Ah ? C'est si nul que ça ce que j'ai écris ?

    Bah c'est juste que je m'interroge sur l'utilisation des exceptions et particulièrement sur DivideByZeroException parce qu'en langage procédural, je me contentais de tester le diviseur.
    J'ai lu qu'une exception ne devait pas être levé dans le fonctionnement normal d'une application. C'est pourquoi je m'étais dit qu'on pouvait éviter de lever une exception en testant le diviseur.

    Sinon MyLibrary.Mathematic est bien une dll.

    C'est quoi un code stylé ?
    C'est dans quel sens du mot :
    1 - Qui est habitué à exécuter une fonction, un travail selon certaines règles.
    2 - Qui se caractérise par un style original
    J'entendais par code stylé une façon de programmer élégante.

    Merci.

  11. #11
    Expert éminent
    Avatar de neguib
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    3 627
    Détails du profil
    Informations personnelles :
    Âge : 63
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2005
    Messages : 3 627
    Points : 7 879
    Points
    7 879
    Par défaut
    Citation Envoyé par Pilloutou
    ...c'est juste que je m'interroge sur l'utilisation des exceptions et particulièrement sur DivideByZeroException parce qu'en langage procédural, je me contentais de tester le diviseur.
    J'ai lu qu'une exception ne devait pas être levé dans le fonctionnement normal d'une application. C'est pourquoi je m'étais dit qu'on pouvait éviter de lever une exception en testant le diviseur.
    Entendons nous bien, je parle de ceci par exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    else throw new ArgumentException("Le paramètre n'est pas valide");
    Donc tu as testé et pourtant tu as levé l'exception ok . je te parlais d'enrichir la façon élégante que tu emploies en précisant ici ArgumentException N'oublie pas que les objets Exceptions peuvent s'imbriquer les uns dans les autres par leur propriété InnerException
    Ainsi par exemple ton ArgumentException peut très bien contenir ici un NullReferenceException ok
    soit :
    else throw new ArgumentException("Le paramètre n'est pas valide","coeff[]",new NullReferenceException(...));
    Pour le bien de ceux qui vous lisent, ayez à coeur le respect du forum et de ses règles

  12. #12
    Membre expérimenté Avatar de Mose
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 143
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 143
    Points : 1 379
    Points
    1 379
    Par défaut
    Citation Envoyé par Pilloutou
    Ah ? C'est si nul que ça ce que j'ai écris ?
    Non, mais c'est que tu cherches un absolu là où il y a un relatif.
    Je m'explique : ton code doit dépendre du cadre d'utilisation. Un code n'est pas excellent dans l'absolu, il l'est par rapport a un problème ou une architecture donnée.
    Par analogie : habillé en rasta, tu es "stylé" dans la cours du lycée, mais dans un rallye du 16ème, tu es crado.
    Citation Envoyé par Pilloutou
    J'entendais par code stylé une façon de programmer élégante.
    Lol, ton chef de projet est une femme ? Tu veux la draguer en lui montrant que tu alignes de belles lignes bien proprement comme un premier de la classe ? (Oups.. chui méchant là )
    Tu veux entrer en SSII et faire de la lèche à ton boss pour avoir une augmentation ?
    Tu veux que tes collègues t'admire paske ton code est beau, ce qui permet de compenser le complexe que tu as vis-à-vis de ton physique ?

    Nan, franchement, je comprend pas. Cette réflexion (un code élégant) dénote soit une immaturité dû à ta jeunesse et aux conneries qu'on t'as inculqué, soit un refoulement probablement assez enfoui en toi (au point que tu vas certainement t'énerver à la lecture de ces conjectures innocentes), soit un manque cruel de discernement de ma part car je ne vois d'esthétique que dans l'intellectualisation des problèmes et solutions informatiques, et pas dans le bel alignement de caractères affichés à l'écran.

    Permet moi juste de partager mon expérience de vieux con (10 ans de programmation) : je suis maniaque avec mon code, car j'aime le comprendre instantanément en le relisant. Aujourd'hui je fais environ une ligne de commentaire pour une ligne de code. Et je fais ça pour une seule personne : moi même.
    Pourquoi ? Parce qu'en 10 ans, personne n'a jamais relu mon code. En entreprise, les gens n'en ont rien à foutre (sauf tierce maintenance applicative, et de toute façon on te critique), ce qui compte c'est que ça marche.
    Je n'ai jamais pu draguer une nana avec mon code alors qu'il démontre indéniablement une rigueur et un professionnalisme (une "élégance") digne d'un homme de l'art.
    Je n'ai jamais fait qu'agacer mes collègues (et co-étudiants) par mes maniaqueries (mais dans le fond je m'en fous, je fais ça pour moi)
    Et mes boss n'ont jamais relu mon code pour me féliciter.

    Maintenant, je vais faire preuve de mansuétude, ravaler mon discours, et te poser une simple question : qui veux-tu impressionner avec un code élégant ?

  13. #13
    Membre actif
    Inscrit en
    Août 2006
    Messages
    381
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 381
    Points : 252
    Points
    252
    Par défaut
    au point que tu vas certainement t'énerver à la lecture de ces conjectures innocentes
    Bah en fait, je trouve ça assez rigolo surtout que c un peu vrai.

    Donc non je ne veux impressionner personne en particulier mais en fait je pense que par code élégant, je voulais simplement dire code flexible, facile à maintenir, réutilisable.
    Je me posais aussi des questions sur les traces, les messages pour le debuggage, l'utilisation des exceptions. Bon oui ça fait un paquet de truc...

    Mais néanmoins merci bien pour ta réponse.
    Je vais méditer là-dessus.

    Bye

  14. #14
    Membre expérimenté Avatar de Mose
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 143
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 143
    Points : 1 379
    Points
    1 379
    Par défaut
    Citation Envoyé par Pilloutou
    je voulais simplement dire code flexible, facile à maintenir, réutilisable.
    Oki, là on parle le même langage

    Alors pour répondre sur le fond :
    * Tu devrais sans doute commenter un peu plus ton code surout sur deux points :
    - les boucles car dans 3 ans tu auras sans doute oublié ce qu'elles calculent
    - les paramètres de tes méthodes dans les commentaires XML, pour éviter d'avoir à réfléchir à quoi ils correspondent quand tu t'en sers
    * Les traces/debut/assert : c'est une question de philosophie personnelle. Va-y comme tu le sens, de toute façon, ta façon de coder évoluera avec le temps.

    Perso je n'utilise pas la classe Debug directement dans mes méthodes, mais j'utilise un objet static perso pour factoriser tous les problèmes que je rencontre, et derrière c'est dans cet objet que je choisi si je lance une exception, si je créé un log ou si j'envoie un message à l'utilisateur. Comme ça à chaque appli je peux choisir comment les erreurs sont traitées, sans avoir à modifier tout mon code.
    C'est un choix, ce n'est pas parfait, mais ça colle bien à mon dev.

  15. #15
    Membre actif
    Inscrit en
    Août 2006
    Messages
    381
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 381
    Points : 252
    Points
    252
    Par défaut
    Perso je n'utilise pas la classe Debug directement dans mes méthodes, mais j'utilise un objet static perso pour factoriser tous les problèmes que je rencontre, et derrière c'est dans cet objet que je choisi si je lance une exception
    Je cherche aussi à faire une classe de ce style.
    J'en ai d'ailleurs fait une pour les traces et le debug.

    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
     
    static class DiagnosticsHandling
        {
            /// <summary>
            /// Trace horodatés des messages
            /// </summary>
            /// <param name="message"></param>
            static public void TraceMessage (String message)
            {
                Trace.WriteLine(DateTime.Now.TimeOfDay.ToString() + " - " +
     message);
            }
     
            static public void DebugMessage(String message)
            {
                Debug.WriteLine(DateTime.Now.TimeOfDay.ToString() + " - " +
     message);
            }
        }
    J'aimerais bien en faire une pour les exceptions. Je suis en train d'étudier l'application block de Microsoft sur les exceptions.

    Mais globalement comment tu fais ? Tu fais une classe qui dérive de la classe Exception. Et toutes les exceptions que tu attrapes dans un bloc try/catch, tu relances une exception instance de ta classe exception, ce qui te permets de la traiter ensuite. C'est ça ?

    Merci.

  16. #16
    Membre expérimenté Avatar de Mose
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 143
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 143
    Points : 1 379
    Points
    1 379
    Par défaut
    Citation Envoyé par Pilloutou
    Mais globalement comment tu fais ? Tu fais une classe qui dérive de la classe Exception. Et toutes les exceptions que tu attrapes dans un bloc try/catch, tu relances une exception instance de ta classe exception, ce qui te permets de la traiter ensuite. C'est ça ?
    Bah perso je n'utilise le moins possible les blocs try/catch dans mon code.
    C'est trop lent. Je fais les vérif moi-même avec des if/else
    Et quand j'ai une erreur bloquante, là je lance une exception depuis mon Failer (mon objet qui factorise tous les problèmes)

    En revanche, quand j'utilise du code .Net susceptible de planter sans pouvoir le vérifier (genre connexion serveur SQL), là je colle un try/catch pour récupérer l'Exception .Net, et je la passe en paramètre à la méthode du Failer.

    Suivant la config choisie, cet objet va :
    * soit créer une ApplicationException (avec celle qu'on lui a donné comme InnerException, comme ça j'ai la stack trace complète), et la relancer parce que je souhaite que l'Exception se propage (ex : librairie de classe)
    * soit balancer un message utilisateur avec l'exception.ToString() (mode debug) ou juste un message user-friendly (mode release) (ex : application WinForm)
    * en plus il peut faire un log avec l'Exception complète (mode log)

    Bon.. et puis c'est pas un objet static paske sinon je pourrais utiliser qu'une seule config par système au lieu d'une config par appli. en fait je stocke en static une Hashtable de Failer, et j'identifie chaque Failer par une clef (qui est générée automatiquement : c'est le nom de l'appli lancée) (mais là on rentre vraiment dans le détail )

    Sinon je vois pas trop l'intérêt de créer sa propre exception... à moins de vouloir une gestion d'erreur très spécifique.

  17. #17
    Membre actif
    Inscrit en
    Août 2006
    Messages
    381
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 381
    Points : 252
    Points
    252
    Par défaut
    Citation Envoyé par Mose
    Bah perso je n'utilise le moins possible les blocs try/catch dans mon code.C'est trop lent. Je fais les vérif moi-même avec des if/else

    Et quand j'ai une erreur bloquante, là je lance une exception depuis mon Failer (mon objet qui factorise tous les problèmes)
    Donc si je comprends bien par exemple,

    au lieu de faire:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    int a = 0;
    int b = 5;
    int c = 0;
     
    try {
        c = b / a;
    }
    catch (DivideByZeroException ex) {
        Console.Writeln(ex.Message);
    }
    tu fait plutôt:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    int a = 0;
    int b = 5;
    int c = 0;
     
    if (a!=0)
        c = b / a;
    else TonObjetFailer.SendMessage("Division par zéro interdite");
    Par contre, pour les plantage possible,

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    try {
        connectToServer(MyDataBase);
    catch (Exception ex) {
        TonObjetFailer.SendError(ex);
    }
    En regardant l'application block de Microsoft, l'auteur a crée une classe statique ExceptionPolicy et ça donnerait:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    int a = 0;
    int b = 5;
    int c = 0;
     
    try {
        c = b / a;
    }
    catch (DivideByZeroException ex) {
        ExceptionPolicy.HandleException(ex, "Wrap Policy");
    }
    Ou "Wrap Policy" est le nom de la politique de traitement de l'exception.

  18. #18
    Membre expérimenté Avatar de Mose
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 143
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 143
    Points : 1 379
    Points
    1 379
    Par défaut
    Plus ou moins. En fait j'ai trois appels possibles :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Failer.Default.Log(string);
    Failer.Default.Log(string, Exception);
    Failer.Default.Log(string, Exception, Failer.FailingType);
    // le FailingType est utilisé pour distinguer différents types d'erreurs
    Le "Default" c'est l'accès à l'instance par défaut.
    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
    30
    31
    32
    33
    34
    35
    36
    37
    /// <summary>
    /// Failer's table
    /// </summary>
    private static Hashtable _failers = null;
    /// <summary>
    /// Get the Failer associated to the given key. Isntanciate a new one if needed
    /// </summary>
    /// <param name="key">The given key</param>
    /// <returns>A Failer instance</returns>
    public static Failer FromKey(string key)
    {
    	Failer retour = null;
     
    	// if the Failers collection is not instanciated
    	if(_failers == null)
    		// instanciate it
    		_failers = new Hashtable();
    	// if the given key is in the Failers collection
    	if(_failers.Contains(key))
    		// then get the associated Failer
    		retour = (Failer)_failers[key];
    	else // if it's not in the Failers collection
    	{
    		// instanciate a new one
    		retour = new Failer(key);
    		// add it to the Failers collection
    		_failers.Add(key, retour);
    	}
    	return retour;
    }
    /// <summary>
    /// Automatic instance used to simplify error logging
    /// </summary>
    public static Failer Default
    {
    	get{return Failer.FromKey(System.Diagnostics.Process.GetCurrentProcess().ProcessName);}
    }

  19. #19
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Points : 1 561
    Points
    1 561
    Par défaut
    Un code éléguant n'a pas de sens,

    La seule chose qui peut rendre un code éléguant par rapport à un autre, c'est la façon dont il est structuré, et permet une relecture et compréhension facile.

    Car meme des formules style
    a = (b !=c)?a/((b!=0)?b:((c!=0)?c:0)):b;
    c'est élégant, tout dépend du contexte.

    Maintenant les assertions sont à proscrire dans un projet en phase finale (release) en effet, car elles ralentissent très fortement ton programme, car la plupart du temps tu fait toi même les tests nécessaires, et génére si nécessaire des exceptions.

    N'oublie pas que là tu traite d'une DLL, pas d'une application. Il est donc nécessaire qu'elle leve de temps à autre des Exceptions préférables à des réponses null.

    Maintenant je suis d'accord il faut aussi minimiser les exceptions, et ne pas les utiliser à mauvais essient car cela reste un mécanisme relativement lent. Mais extremement pratique dans le cadre ou une personne ne respecte pas une règle d'appel sur une fonction par exemple. Car tu fabrique du code réutilisable par d'autres.

    Malheureusement tu n'echappera pas au try/catch/finally car le framework utilise à outrance les exceptions dès que quelque chose ne va pas, même lorsqu'une simple fonction d'erreur suffit.

    Sinon pour ce qui est de ton code, utilise les commentaires pour toi avant tout, pour une relecture facile et pour un débogage facile. Car on peut toujours critiquer du code. Et souvent le code compilé final, n'est que peu altéré, quand les compilateurs sont très pointus au niveau optimisations.

    De plus un code élégant ne rend pas tes algorithmes plus efficaces pour autant, alors ...

    Maintenant il est vrai qu'il existe des codes plus propres que d'autres, mais comme toujours, c'est une question de relecture. Si un code est illisible et qu'en prime, on n'y comprend rien, il est pas élégant, mais surtout pas pratique.

    Essaie donc d'avoir du code bien structuré, bien aéré, et bien commenté, ca t'évitera pas mal de bugs, ou te permettra de mieux les trouver.

  20. #20
    Membre actif
    Inscrit en
    Août 2006
    Messages
    381
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 381
    Points : 252
    Points
    252
    Par défaut
    Et bien, je vous remercie tous pour ces bon conseils...

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. quelques conseils pour une application web vb.net
    Par Gr@nd@x dans le forum VB.NET
    Réponses: 1
    Dernier message: 20/11/2008, 20h34
  2. [Conseil] Quel langage pour une petite appli. serveur ?
    Par hm@rch@1 dans le forum Windows
    Réponses: 0
    Dernier message: 29/07/2007, 10h40
  3. Quel ETL est à me conseiller pour une migration de bases ?
    Par Arvulis dans le forum Alimentation
    Réponses: 10
    Dernier message: 27/10/2006, 16h39
  4. Réponses: 4
    Dernier message: 06/03/2006, 18h54
  5. [Systeme d'Information] Quels conseils pour une refonte ?
    Par jejefeds dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 07/12/2005, 19h23

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