[C#] Le bug anti-boulot

Mod Message lu Posté le 31 Déc 2008 à 15:51 Bulle
Avatar de Mod
Webmaster

Messages : 4954
GCPoints : 2100823
Une petite surprise qui m'aura quand même pris pas mal de temps à débugguer. Et que je vais me faire un plaisir de partager avec vous.

Prenons un projet Winforms quelconque.

Ajoutons un UserControl.

Ajoutons-lui une propriété "Test" par exemple :

Code : C#
        private int test;
        public int Test
        {
            get
            {
                return Test;
            }
            set
            {
                test = value;
            }
        }


Compilation...

Ajoutons maintenant à une form quelconque un exemplaire de cet UserControl.

Pouf, adieu Visual Studio. Plantage en bonne et due forme avec disparition complète et instantanée de l'IDE (qui se permet d'ailleurs de rester en mémoire, non content de crasher).

Je n'ai pas encore essayé sous les versions 2008, mais sous mon Visual C# 2005 Express (avec le SP1), c'est terrifiant d'efficacité.

Pour ceux qui n'auraient pas remarqué, le problème, c'est bien sûr que le getter se retourne lui-même (Test au lieu de test). Dans un UserControl, VisualStudio analysant et affichant ce contrôle, cela provoque donc logiquement un crash (quoique sans message d'erreur, pas très propre, tout ça)

Le genre de petite erreur qui peut se produire avec l'auto-complétion, et qui passe inaperçue car syntaxiquement correcte. Il s'avère que j'ai commis cette erreur dans un gros UserControl, bourré de propriétés et de méthodes en tout genre. Avec la nécessité de recompiler le code pour mettre à jour l'affichage du UserControl dans la form, le bug n'a pas été immédiatement détecté, et j'ai pu largement modifier cet UserControl avec qu'il n'apparaisse.

Je vous laisse deviner combien de fois j'ai pu redémarrer Visual en deux jours...

Voilà, vous serez prévenus au cas où :want: .
Gulix Message lu Posté le 02 Jan 2009 à 13:41 Bulle
Avatar de Gulix
Membre Confirmé

Messages : 184
GCPoints : 8860
Une méthode radicale, que j'utilise dans tous mes projets, est de préfixer les membres internes (private) par un underscore. On les trouve beaucoup plus facilement, et même dans le code des fonctions, on sait si on utilise une variable interne à la fonction ou membre de la classe.
"Bien souvent, l'école représente votre meilleure chance. Non pas d'apprendre quoi que ce soit, bien sûr, mais de survivre à une attaque de morts-vivants".
Max Brooks - Guide de survie en territoire zombie

Mon Blog, mélange de prog' et de culture
Blind Shark - Pull N' Bounce
SEB Message lu Posté le 02 Jan 2009 à 14:00 Bulle
Avatar de SEB
Membre Evolué

Messages : 554
GCPoints : 103313
Je fais exactement pareil que toi Gulix :D
NextGine : 3D games engine
Nombre de lignes actuel : 77683
Mod Message lu Posté le 03 Jan 2009 à 15:00 Bulle
Avatar de Mod
Webmaster

Messages : 4954
GCPoints : 2100823
Je le faisais aussi auparavant, mais ça complexifie visuellement le code au point que j'ai laissé tombé l'affaire. Un code doit aussi donner envie d'être lu, et les underscores, ça donne des frissons quant il y en a de trop.

Mais c'est vrai que c'est ce que fait une majorité de programmeurs, d'après les multiples codes C# ou VB.Net que j'ai pu voir, le bug pourrait effectivement facilement être évité ainsi.
Répondre
GameCorp - Site d'apprentissage et d'entraide à la création de jeux vidéo.
XHTML Valid 1.1 - Page générée en 0.0495 secondes