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

**Pilloutou** · 22/08/2006, 16h47

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.

Invité · 23/08/2006, 08h12

Personnellement je ne trouve pas grand chose à dire sur ta maniere de coder cette classe.

**Thomas Lebrun** · 23/08/2006, 09h57

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

**Pilloutou** · 23/08/2006, 11h45

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String.Empty ?

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.

**Thomas Lebrun** · 23/08/2006, 13h13

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

**neguib** · 23/08/2006, 16h26

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.

**Mose** · 23/08/2006, 19h42

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

**Pilloutou** · 23/08/2006, 21h23

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

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.

**neguib** · 24/08/2006, 08h20

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 .

**Pilloutou** · 24/08/2006, 08h37

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.

**neguib** · 24/08/2006, 08h48

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(...));

**Mose** · 25/08/2006, 17h56

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.

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 ?

**Pilloutou** · 25/08/2006, 18h53

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

**Mose** · 28/08/2006, 12h24

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.

**Pilloutou** · 28/08/2006, 21h24

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.

**Mose** · 29/08/2006, 16h55

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.

**Pilloutou** · 29/08/2006, 19h40

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.

**Mose** · 30/08/2006, 19h59

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);}
}

**cinemania** · 30/08/2006, 21h55

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.

**Pilloutou** · 30/08/2006, 22h02

Et bien, je vous remercie tous pour ces bon conseils...

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

VB.NET

Discussions similaires

Partager

Partager