Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Des outils simples et gratuits pour faire du XAML

Xaml est le langage de description utilisé par WPF et Silverlight. On peut créer du code Xaml en utilisant Expression Blend, Expression Design ou même Adobe Illustrator (à l'aide d'un petit plugin gratuit XamlExport). Bien entendu le code Xaml peut aussi être manipulé sous VS 2008 mais de façon sommaire.

Pour tester du code Xaml il s'avère souvent nécessaire, qu'on soit en phase d'apprentissage ou qu'on soit un expert, de pouvoir saisir ou modifier quelques lignes pour visualiser le résultat.

Pour cela il existe des "notepad" (bloc-notes).

XamlPad.exe

C'est le plus simple. Rudimentaire même. Il est fourni avec le SDK Windows. Pour info sur ma machine il se trouve dans "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin". Il dispose d'une page sur MSDN expliquant comment s'en servir. Il ne fait pas grand chose et il est préférable de se tourner vers des versions améliorées. 

XamlPadX

Cet outil est déjà plus évolué. On peut le télécharger sur le blog de Lester. La version actuelle est la 4.0 qui sait gérer les add-ins et possède quelques exemples "hard codés" qui permettent de rapidement tester l'outil. Le setup peut être téléchargé depuis le billet du blog de Lester.
Un petit détail : Avast détecte un Trojan générique lors du téléchargement et refuse d'enregistrer le fichier... Pour l'installer il faut couper Avast, télécharger l'exe, le lancer (c'est un setup) et un fois l'install terminée rétablir Avast. L'exécutable lui-même ne pose aucun problème, je suppose que c'est Avast qui doit prendre pour un Trojan une séquence du module d'installation.

 

Kaxaml

Cet autre outil offre des services similaires mais avec une philosophie légèrement différente. Difficile de dire s'il est meilleur que le précédent c'est à chacun de voir celui qui est le mieux adapté à ses besoins et à sa façon de travailler. Kaxaml dispose de sa propre page web d'où l'on peut télécharger soit la version 1.0 soit la bêta qui supporte Silverlight 2 b2.

 

Conclusion

Ces petits outils n'ont pas la sophistication d'un Blend ou d'un Expression Design, ils ne remplacent pas non plus la partie code-behind de VS 2008. En revanche ils permettent de tester rapidement des idées ou des snippets récupérés ici ou là. Ils ne remplacent donc rien mais viennent compléter agréablement la boîte à outil du développeur WPF qu'il soit expert ou en phase d'apprentissage.

Bon Dev

Et Stay Tuned !

Astuce du jour : déboguer du code sans écrire de code de test

Il arrive souvent (ou il devrait souvent arriver...) qu'on veuille tester rapidement du code. Par exemple vérifier qu'une méthode retourne bien le bon résultat selon deux ou trois variantes des paramètres d'entrée. Mais écrire du code de test à chaque fois, même si "on devrait" le faire tout le temps, n'est pas totalement conforme à la réalité. On a plus souvent la pression que la bride sur le collier et cela impose de travailler bien, mais vite !

Alors une petite astuce rapide pour aujourd'hui. La fenêtre Immediate de VS 2008 offre un moyen simple d'invoquer du code et de tester rapidement une méthode. Peut-être connaissez-vous cette fonction de VS dans ce cas j'espère juste vous avoir rafraichi la mémoire pour vous en servir plus souvent !

Je ne connais pas le nom en français de cette fenêtre car j'utilise un VS en US. Mais vous trouverez facilement.

Une des façons rapides de l'appeler est d'utiliser le raccourci vers la fenêtre Command et de taper "immed" ce qui ouvre la fenêtre Immediate. La fenêtre Command s'appelle par Ctrl-Alt-A (vérifiez si en français le raccourci est le même).

Bien entendu pour invoquer du code il faut être en debug. Soit vous avez un point d'arrêt quelque part et vous attendez d'y être arrivé, soit vous pouvez lancer l'application par F10 (step over) au lieu de F5, cela s'arrêtera tout de suite sur le Main. Là, tapez Ctrl-Alt-A puis "immed" si la fenêtre Immediate n'est pas déjà affichée. Et il ne reste plus qu'à taper votre code de test... Vous disposez de Intellisence et de toute l'aide, c'est pas merveilleux ? !

En image pour voir de quoi il s'agit (la qualité de la capture est mauvaise en raison de la réduction à 80% et de la compression jpeg, j'essaye de ne pas trop grossir les flux RSS des abonnés au blog...) :

La fenêtre Immediate, c'est facile, rapide, puissant. Autant s'en servir !

Bon Dev

...Et Stay Tuned !

Un outil gratuit pour tester les requêtes LINQ

Qu'il s'agisse de LINQ to Object ou LINQ to SQL il serait bien agréable de pouvoir disposer d'une sorte de bloc-note pour tester ou mettre au point des requêtes, voire pour s'entraîner tout simplement. Pouvoir gérer les connexions aux bases de données, éventuellement envoyer et tester du SQL "de base" sur celles-ci serait la cerise sur la gâteau. Et bien cet outil existe, et en plus il est gratuit !

 

LINQPad, puisque c'est de lui qu'il s'agit, n'est pas vraiment une nouveauté absolue mais il y a fort à parier que nombre d'entre vous n'en ont jamais entendu parlé.

Cet outil a été développé conjointement à l'excellent ouvrage "C# 3.0 in a nutshell" de Joseph Albahari, un australien, qui par la diffusion gratuite de LINQPad tente une promo plutôt positive de son livre et de ses services de consulting (si on habite au pays des kangourous, of course).

J'aime personnellement cette idée de "pub positive" qui consiste à offrir de son temps et de son travail pour faire sa pub plutôt que de gaver les gens de bandeaux agaçants. C'est de la pub dans un esprit totalement anti-google (de la pub pour de la pub, partout, sans rien apporter à ceux qui la subissent), et il faut encourager ceux qui adoptent cette façon respectueuse de faire leur promotion. Achetez le livre de Joseph ! Fin de la paranthèse :-)

LINQPad est ainsi un super utilitaire. Il interprète du code C# ou VB et les requêtes LINQ to Object ou LINQ to SQL. Il autorise la connexion à des bases de données, offre un éditeur purement SQL en supplément, bien pratique, et il permet même d'ajouter ses propres DLL et ses propres espaces de noms pour qu'ils soient reconnus dans le code C# qu'on tape !

On peut dès lors utiliser LINQPad pour requêter des objets métiers complexes, un framework maison, un modèle LINQ to SQL, etc.. Il suffit d'ajouter les références.

Pour terminer, LINQPad est fourni avec de nombreux exemples qui sont autant de moyens de tester ses connaissances et d'apprendre les subtilités de LINQ. Utilisé conjointement à ma version des "101 exemples LINQ" de Microsoft, LINQPad devient un fantastique outil d'auto-formation.

Pour télécharger le produit et avoir accès aussi aux forums, aux vidéos de démo, et plein d'autres choses, aller sur la page de LINQPad !

Bon Dev...

Et Stay Tuned !

 

Simplifier les gestionnaires d'événement grâce aux expressions Lambda

Les expressions Lambda ont été introduites dans C# 3.0. Utilisées correctement, tout comme LINQ to Object, elles permettent une grande simplification du code entraînant dans un cercle vertueux une meilleure lisibilité de ce dernier favorisant maintenabilité et fiabilité de ce même code. Il n'y a donc aucune raison de rester "frileux" vis à vis de cette nouveauté syntaxique comme encore trop de développeurs que je rencontre dans mes formations ou ailleurs.

Pour démontrer cette souplesse, voici un petit exemple qui valide un document XML en fonction d'un schéma.

La méthode Validate() de la classe XDocument attend en paramètre un delegate de type ValidationEventHandler. Dans un code très court il n'est pas forcément judicieux de déclarer une méthode juste pour passer son nom en paramètre à Validate(). Les "sous procédures" ou procédures imbriquées de Pascal n'existent pas en C# et l'obligation de déclarer à chaque fois des méthodes private pour décomposer la moindre action est une lourdeur syntaxique de ce langage dont on aimerait se passer parfois (une méthode même private est visible par toutes les autres méthodes de la classe ce qui n'est pas toujours souhaitable. Seules les méthodes imbriquées de Pascal sont des "méthodes privées de méthodes").

En fin de billet vous trouverez d'ailleurs le lien vers un autre billet dans lequel j'explique comment utiliser les expressions Lambda en les nommant pour retrouver la souplesse des procédures imbriquées. Même si "l'astuce" présentée ici peut y ressembler dans l'esprit, dans la pratique les choses sont assez différentes puisque nous n'utiliserons pas une expression nommée.

Revenons à l'exemple, il s'agit de valider un document XML à partir d'un schéma. Et de le faire de la façon la plus simple possible, c'est à dire en évitant l'écriture d'un delegate, donc en utilisant directement une expression Lambda en paramètre de Validate().

Supposons que nous ayons déjà le schéma (variable schema) et le document XML (variable doc), l'appel à Validate pourra donc s'écrire :

doc.Validate(schema,(obj, e) => errors += e.Message + Environment.NewLine);

"errors" est déclarée comme une chaîne de caractères. A chaque éventuelle erreur détectée par la validation l'expression concatène le message d'erreur à cette dernière. En fin de validation il suffit d'afficher errors pour avoir la liste des erreurs. Mais cela n'est qu'un exemple d'utilisation de l'expression Lambda. Ce qui compte c'est bien entendu de comprendre l'utilisation de cette dernière en place et lieu d'un delegate de tout type, ici ValidationEventHandler d'où les paramètres (obj,e) puisque ce delegate est déclaré de cette façon (un objet et un argument spécifique à cet handler).

C'est simple, nul besoin de déclarer un gestionnaire d'événement donc une méthode avec un nom et une visibilité. On évite que cette méthode soit réutilisée dans le code de la classe considérée (si elle existe on est tenté de la réutiliser mais sa stratégie d'écriture n'est pas forcément adaptée à une telle utilisation d'où possible bug), etc. Que des avantages donc.

Pour plus d'information vous pouvez lire mon article sur les nouveautés syntaxiques de C# 3.0 ainsi que mon billet montrant comment retrouver en C# le bénéfice des procédures imbriquées de Pascal grâce aux expressions Lambda.

Si vous voulez jouez avec l'exemple, vous pouvez télécharger le projet VS 2008 qui montre tout cela : lambda.zip (21,71 kb)

La guerre des clones n'aura pas lieu ! ... Si vous possédez Clone Detective !

Clone Detective pour Visual Studio est un outil de debug un peu particulier puisqu'il ne cherche pas les bugs mais les redondances de code.

La redondance de code est un ennemi sournois... Le code dupliqué est bien souvent la porte ouverte aux inconsistances et aux regressions lors de mises à jour correctives ou évolutives. En effet, si un bug apparaît un jour dans une séquence mais qu'il n'a pas encore été repéré dans une autre fonction qui utilise pourtant un code similaire, la mise à jour ne concernera que la séquence incriminée. Un jour où l'autre la partie codée de façon similaire plantera aussi pour les mêmes raisons. Elle ne sera d'ailleurs peut être pas corrigée de la même façon ni par la même personne... Inconsistance. Coûts de maintenance inutiles. Les défauts de la redondance de code ne manque donc pas.

D'ailleurs un outil capable de retrouver ces fameux clones est un excellent assistant pour un auditeur... La présence des clones trahit non pas celle de Palpatine ou du comte Doku mais bien d'un code for mal refactoré, donc pauvre et qui laissera par force voir d'autres faiblesses !

Précisons que Clone Detective cherche les "clones", pas seulement le code purement redondant de type copier/coller. Il analyse le code en supprimant les commentaires, les espaces, les noms de variables etc, afin d'obtenir un code de référence le plus générique possible avant d'y chercher les clones. Les clones formes des classes de code équivalent, l'un pourrait remplacer l'autre sans problème, à la présentation et aux noms de variables près.

Il s'agit donc bien d'une recherche intelligente et non simplement d'une recherche de "doublons". Mais la lecture de la documentation de CD vous en dira bien plus que ces quelques lignes.

Donc pour se prémunir des dommages causés par les clones, et si on ne connait pas le numéro de portable de Yoda, le mieux est encore de télécharger Clone Detective. Bonne nouvelle il n'habite pas une galaxie lointaire, il est sur CodePlex et donc gratuit avec le code source pour les curieux ! Mieux, C.D. s'insère dans VS 2008 (voir / autres fenêtres, pour afficher celles de C.D. une fois installé). Vraiment un bel add-in dont il serait bête de se priver !

Pour accéder à la page de chargement, cliquez simplement sur le logo de Clone Detective inséré plus haut dans le corps de ce billet.

Que la force soit avec vous !

(et Stay Tuned !)

Les différentes versions du framework .NET

Depuis sa naissance le framework a bien évolué ! La compatibilité ascendante a toujours été respectée et preuve en est aujourd'hui que le "side-by-side execution" de .NET fonctionne bien puisque toutes les versions peuvent coexister sur la même machine et que de nombreux logiciels les utilisant peuvent tourner ensemble sans aucun mélange, loin du "Dll Hell" de Win32.

Le pari est donc tenu et en général on ne se soucie de la version du framework que pour savoir si on désire supporter telle ou telle nouvelle fonctionnalité mais jamais pour éviter des "incompatibilités" (quel vilain mot ! :-) ).

Toutefois il est parfois important de respecter une implémentation particulière et donc de savoir où trouver le setup correspondant. Au-delà de ces contingences techniques il est intéressant de connaître les diverses versions qui (co)existent et qu'on peut trouver chez les utilisateurs. Un petit récapitulatif n'est donc pas forcément de trop...

Les différentes versions

Les différentes versions du Framework .NET à ce jour
VersionTypen° versionDate 
.NET Framework 1.0
1.0  RTM 1.0.3705.0  02/01/2002
1.0 SP1  Service Pack 1.0.3705.209 19/03/2002 
1.0 SP2  Service Pack  1.0.3705.288  07/08/2002 
1.0 SP3  Service Pack  1.0.3705.6018  31/08/2004
.NET Framework 1.1
1.1 RTM 1.1.4322.573 01/04/2003
1.1 SP1 Service Pack 1.1.4322.2032 30/08/2004 
1.1 incluse avec Win2003 SP1  Win2k3  1.1.4322.2300  30/05/2005 
.NET Framework 2.0
2.0  RTM  2.0.50727.42 07/11/2005 
2.0 Vista  RTM  2.0.50727.312  30/01/2007 
2.0 SP1  Service Pack  2.0.50727.1433   19/11/2007 
MS07-040  Security Patch 2.0.50727.832    

2.0 SP2 
La SP2 n'est pas distribuée seule
Elle est incluse dans .NET 3.5 SP1

Service Pack 2.0.50727.2407   
.NET Framework 3.0 
3.0  RTM 3.0.4506.30 06/11/2006 
3.0 Vista  RTM 3.0.4506.26  30/01/2007
3.0 SP1  Service Pack  3.1.21022  19/11/2007
.NET Framework 3.5 
3.5  RTM 3.5.21022.08 09/11/2007 
3.5 SP1 Service Pack 3.5.30729.1 11/08/2008

Le tableau ci-dessus n'intègre pas toutes les versions beta qui, par essence, ne sont pas installées en production. En revanche, en cliquant sur les liens vous accéderez directement à la page de téléchargement de la version concernée.

Savoir quelles versions sont installées

Cela est tout bête, mais disposer d'un joli tableau des versions est une chose, mais comment savoir quelles versions sont installées sur une machine ?

C'est une bonne question et j'attendais que vous me la posiez ! :-)

La version simple : ouvrez une commande (menu démarrer, exécuter puis tapez "cmd"), puis tapez la ligne suivante :

cd %systemroot%\Microsoft.NET\Framework

Tapez ensuite la commande "dir" et regardez la liste des répertoires... Chaque version est installée dans le sien propre dont le nom est tout simplement le numéro de la version précédé de la lettre "v", "v2.0.50727" par exemple.

La version plus complète : utilisez l'explorateur de fichiers, tapez dans la barre d'adresse  %systemroot%\Microsoft.NET\Framework, entrez dans l'un des répertoires en question et localisez le fichier Mscorlib.dll. Clic droit puis Propriétés, et dans l'onglet Version vous obtiendrez le numéro de version complet de l'installation du framework considérée.

Il faut préciser que vous obtiendrez peut-être des numéros de version qui ne sont pas dans le tableau de ce billet, comme je l'ai précisé je n'ai pas pris en compte les beta ni les hotfixes éventuels. Par exemple, sur ma machine pour le répetoire "v2.0.50727", le fichier Mscorlib.dll me donne 2.0.50727.3053 qui est vraisemblablement la version du SP2 de .NET 2.0 installée par .NET 3.5 SP1.

Pour conclure

Bientôt 7 ans, l'âge de raison si on en croit la sagesse populaire... l'âge où l'on perd ses dents. Je ne sais pas si la métaphore peut s'appliquer jusqu'à ce point, j'ai un doute... Il faut au contraire admettre que le framework commence a avoir une machoire bien gardie ! Et quand on sait tout ce qui est à venir, comme les extensions parallèles (PFX) et bien d'autres choses, on se dit qu'on a bien eu raison de s'y prendre dès le départ, car l'ère .NET ne fait que commencer...

Bon Dev et .. Stay Tuned !

Mondes Parallèles [Webcasts sur le parallélisme + article ]

Comme je vous en parlais dans mon billet "La bombe Parallèle ! PLINQ, et PCP Parallel Computing Platform", Microsoft prépare une série d'extensions à .NET pour le calcul parallèle, dont PLINQ la version parallèle de LINQ. Il y a quelques mois, Keith Yedlin and Steve Teixeira du PCP (Parallel Computing Platform) sont venus en France pour présenter les extensions parallèles. A cette occasion des Webcasts ont été enregistrés et ils sont aujourd'hui disponibles en ligne.

Ces Webcasts portent des titres français mais leur contenu est en anglais. Il existe toutefois un article en français écrit par Eric Vernié que je vous conseille : Introduction aux extensions Parallèles à .NET (PFX).

La liste des webcasts :

Programmation impérative avec F#, parallèlisme avec PFX, Microsoft développe en ce moment de nombreuses technologies qui deviendront de plus en plus incontournables dans l'avenir, autant se tenir informé !

Bon webcasts et Stay Tuned !

Le réflecteur change de miroir...

Un peu message de la BBC durant la dernière guerre le titre de ce billet non ? Je parle de l'excellent outil "Reflector" qu'il faudra désormais télécharger depuis un autre site...

En effet, Reflector de Lutz Roeder a changé de main. Les cairotes sont cuites comme dirait une amie égyptienne ? Est-ce la fin de cet outil que tout développeur .NET possède dans sa trousse ? Seul l'avenir le dira. Pour l'instant, RedGate, la société ayant fait l'acquisition du logiciel le propose toujours en téléchargement gratuit et ne semble pas vouloir changer cette stratégie. Qui vivra verra... En tout cas notez la nouvelle adresse de Reflector : http://www.red-gate.com/products/reflector/index.htm

Bon dev et Stay Tuned !

UPDATE : Non en fait comme tous les autres ce sont des xxxxxx (mettez ce que vous voulez qui ne soit pas très flatteur), ils achètent un produit gratuit, puis ils le laissent gratuit un certain temps pour bien enregistrer votre mail et pouvoir vous envoyer de la pub et quand le plein est fait ça devient payant. Ce genre d'approche qui prend le client pour un crétin me donne la gerbe. A fuir donc. D'autres outils font le même boulot aujourd'hui. Tant pis j'ai bien aimé le travail de Roeder, mais je n'aime pas la récup commerciale de RedGate pour placer en payant ce qui était gratuit (et pas développé par eux donc 0 R&D à rentabiliser), c'est déloyal et ça ne me donne pas envie d'acheter ! Je vous conseille de voir ailleurs. Quitte à payer, il y a bien maintenant.

Déboguer plusieurs projets simultanément sous VS 2008

Lorsqu'on travaille sur une solution comportant plusieurs projets il s'avère souvent utile de pouvoir lancer plusieurs projets en même temps, par exemple s'ils communiquent ensemble ou bien si les résultats de l'un peuvent influencer ceux de l'autre.
Il est certes toujours possible de lancer "à la main" depuis l'explorateur les projets "de fond" puis de lancer en mode debug le projet à déboguer. Mais cela n'est ni pratique ni totalement satisfaisant, en cas de bug dans l'un des projets "secondaires", aucun moyen de savoir ce qu'il se passe.

Il existe pourtant une solution simple...

Voici comment procéder :

  1. Clic droit dans l'explorateur de solution, sur la solution.
  2. Choisir Propriétés
  3. Aller à la page "startup project page" (désolé j'ai un VS en US. Mais c'est la 1ere page du dialogue normalement)

Vous allez voir trois boutons radio :

  • Current Selection (sélection courante)
  • Single startup projet (mode habituel, 1 seul projet lancé au debug)
  • Multiple startup projects (mode multi projets)

Pour chaque projet de la solution, une fois le mode multi projets activé, vous pouvez choisir ce que VS doit faire lorsque le debug est lancé (F5). Un projet peut ne pas être exécuté (par défaut), démarré ou démarré sans debug. La figure ci-dessous montre ces diverses options.

 

Une fois le dialogue validé, en tapant F5 tous les projets sélectionnés sont exécutés dans le mode que vous avez choisi... Les projets démarrés en mode debug peuvent tous être inspecté, avoir des points d'arrêts, etc.

C'est pas fantastique ça ?

Alors pour d'autres nouvelles, Stay Tuned !

Le Mythe du StringBuilder

Sur l'excellent blog du non moins excellent Mitsu, dans l'une de mes interventions sur l'un de ses (excellents aussi) petits quizz LINQ, j'aurai parlé du "Mythe du StringBuilder". Cela semble avoir choqué certains lecteurs qui m'en ont fait part directement. Le sujet est très intéressant et loin de toute polémique j'en profiterais donc ici pour préciser le fond de cet avis sur le StringBuilder et aussi corriger ce qui semble être une erreur de lecture (trop rapide?) de la part de ces lecteurs. J'ai même reçu un petit topo sur les avantages de StringBuilder (un bench intéressant par ailleurs).

D'abord, plantons le décor

Le billet de Mitsu dans lequel je suis intervenu se trouve ici. Dans cet échange nous parlions en fait de la gestion des Exceptions que l'un des intervenants disait ne pas apprécier en raison de leur impact négatif en terme de performance. Et c'est là que j'ai répondu :

"...Dans la réalité je n'ai jamais vu une application (java, delphi ou C#) "ramer" à cause d'une gestion d'exception, c'est un mythe à mon sens du même ordre que celui qui veut que sous .NET il faut systématiquement utiliser un StringBuilder pour faire une concaténation de chaînes."

Comme on le voit ici, seule une lecture un peu trop rapide a pu faire croire à certains lecteurs que je taxe les bénéfices du StringBuilder de "mythe". Je pensais que la phrase était assez claire et qu'il était évident que si mythe il y a, c'est dans le bénéfice systématique du StringBuilder... Nuance. Grosse nuance.

Mythe ou pas ?

La gestion des exceptions est un outil fantastique "légèrement" plus sophistiqué que le "ON ERROR GOTO" de mon premier Basic Microsoft interprété sous CP/M il y a bien longtemps, mais le principe est le même. Et si en 25 ans d'évolution, la sélection darwinienne a conservé le principe malgré le bond technologique c'est que c'est utile...

Est-ce coûteux ?

Je répondrais que la question n'a pas de sens... Car quel est le référenciel ?

Les développeurs ont toujours tendance à se focaliser sur le code, voire à s'enfermer dans les comparaisons en millisecondes et en octets oubliant que leur code s'exprime dans un ensemble plus vaste qui est une application complète et que celle-ci, pour être professionnelle a des impératifs très éloignés de ce genre de débat très techniques. Notamment, une application professionnelle se doit avant tout de répondre à 3 critères : Répondre au cachier des charges, avoir un code lisible, être maintenable. De fait, si les performances ne doivent pas être négligées pour autant, le "coût" d'une syntaxe, de l'emploi d'un code ou d'un autre, doit être "pesé" à l'aulne d'un ensemble de critères où celui de la pure performance ne joue qu'un rôle accessoire dans la grande majorité des applications. Non pas que les performances ne comptent pas, mais plutôt que face à certaines "optimisations" plus ou moins obscures, on préfèrera toujours un code moins optimisé s'il est plus maintenable et plus lisible.

Dès lors, le "coût" de l'utilisation des exceptions doit être évalué au regard de l'ensemble de ces critères où les millisecondes ne sont pas l'argument essentiel.

De la bonne mesure

Tout est affaire de bonne mesure dans la vie et cela reste vrai en informatique.

Si une portion de code effectue une boucle de plusieurs milliers de passages, et si ce traitement doit absolument être optimisé à la milliseconde près, alors, en effet, il sera préférable d'éviter une gestion d'exception au profit d'un ou deux tests supplémentaires (tester une valeur à zéro avant de s'en servir pour diviser au lieu de mettre la division dans un bloc Try/Catch par exemple).

Mais comme on le voit ici, il y plusieurs "si" à tout cela. Et comment juger dans l'absolu si on se trouve dans le "bon cas" ou le "mauvais cas" ? Loin de la zone frontière, aux extrèmes, il est toujours facile de décider : une boucle de dix millions de passages avec une division ira plus vite avec un test sur le diviseur qu'avec un Try/Catch (si l'exception est souvent lancée, encore un gros "si" !). De même, un Try/Catch pontuel sur un chargement de document sur lequel l'utilisateur va ensuite travailler de longues minutes n'aura absolument aucun impact sur les performances globales du logiciel.

Mais lorsqu'on approche de la "frontière", c'est là que commence la polémique, chacun pouvant argumenter en se plaçant du point de vue performance ou du point de vue qualité globale du logiciel. Et souvent chacun aura raison sans arriver à le faire admettre à l'autre, bien entendu (un informaticien ne change pas d'avis comme ça :-) ) !

Où est alors la "bonne mesure" ? ... La meilleure mesure dans l'existence c'est vous et votre intelligence. Votre libre arbitre. Il n'y a donc aucun "dogme" qui puisse tenir ni aucune "pensée unique" à laquelle vous devez vous plier. A vous de juger, selon chaque cas particulier si une gestion d'exception est "coûteuse" ou non. N'écoutez pas ceux qui voudraient que vous en mettiez partout, mais n'écoutez pas non plus ceux qui les diabolisent !

Et le StringBuilder dans tout ça ?

Si dans mon intervention sur le blog de Mitsu j'associais gestion des exceptions et StringBuilder c'est parce qu'on peut en dire exactement les mêmes choses !

Dans les cas extrêmes de grosses boucles il est fort simple de voir que le StringBuilder est bien plus performant qu'une concaténation de chaînes avec "+". Cela ne se discute même pas.

Mais, comme pour la gestion des exceptions, c'est lorsqu'on arrive aux "frontières" que la polémique pointe son nez. Pour concaténer quelques chaînes le "+" est toujours une solution acceptable car le StringBuilder a un coût, celui de son instanciation et du code qu'il faut écrire pour le gérer. Il s'agit là des cas les plus fréquents. On concatène bien plus souvent quelques chaines de caractères dans un soft qu'on écrit des boucles pour en concaténer 1 million le tout dans un traitement time critical... (encore des tas de "si" !).

Même du point de vue de la mémoire les choses ne sont pas si simple. Le StringBuilder utilise un buffer qu'il double quand sa capacité est dépassée. Dans certains cas courants (petites boucles dans lesquelles il y a quelques concaténation), le stress mémoire infligé par le StringBuilder peut être très supérieur à celui de l'utilisation de "+" ou de String.Concat.

C'est dans ces cas les plus fréquents que l'utilisation du StringBuilder comme panacée apparaît n'être qu'un mythe.

Conclusion 

Vous et moi écrivons du code, ce code se destine à un client / utilisateur. La première exigence de ce dernier est que le logiciel réponde au cahier des charges et qu'il fonctionne sans bug gênant. Cela impose de votre côté que vous utilisiez une "stylistique" rendant le code lisible et facilement maintenable car un code sans bug n'existe pas et qu'il faudra tôt ou tard intervenir ici ou là. Dans un tel contexte réaliste, ce ne sont pas les millisecondes qui comptent ni les octets, mais bien la qualité globale de l'application. Et c'est alors que les dogmes techniques tombent. Car ils n'ont d'existence que dans un idéal purement technique qui fait abstraction de la réalité. Un Try/Catch ou un StringBuilder ne peuvent pas être étudiés en tant que tels en oubliant les conditions plus vastes de l'application où ils apparaissent. Leur impact n'a de sens que compris comme l'une des milliers d'autres lignes de code d'une application qui doit répondre à un autre critère, celui de la qualité et de la maintenabilité.

Un seul juge existe pour trancher car chaque cas est particulier : vous.

Pour ceux qui veulent jouer un peu avec les StringBuilder, voici un mini projet que vous n'aurez qu'à modifier pour changer les conditions de tests : ConsoleApplication2.zip (6,10 kb)