Visual Basic.NET : langage d'amateur ou de professionnel? (in French only)

En 1991, Visual Basic 1 a été créé pour les amateurs. Les professionnels, attirés par la capacité qu’offrait VB de développer des applications d’affaires très rapidement, ont poussé Microsoft à y ajouter des possibilités avancées. Mais en ce qui concerne la compatibilité, de la version 1 à la version 6, VB est toujours resté, à la base, un langage d’amateur.

En 2002 est arrivé Visual Basic.NET. Oubliez la ressemblance dans le nom. Ce sont en fait deux bêtes très différentes malgré leurs similitudes. VB.NET est un vrai langage objet qui supporte complètement les notions d’héritage et de polymorphisme, lesquelles n’étaient qu’effleurées avec le VB classique. C’est un langage qui peut être très exigeant et très robuste. Un langage de professionnel donc… si on emploie bien tout son potentiel.

Malheureusement, quand on le sort de sa « boîte », VB.NET est configuré pour les amateurs. Microsoft a profité du passage à .NET pour faire un certain ménage. Mais il n’a pas balayé dans tous les coins. Il a simplement permis d’empêcher les légions d’amateurs et les pseudo-professionnels du VB classique de « bloquer » complètement quand ils passent à .NET.

Vous êtes un « vrai » professionnel? Vous n’aimez pas les langages qui sont sensibles à la casse et qui demandent un ; à la fin de la plupart des lignes (mais pas toutes)? Vous considérerez probablement que le code de gauche est plus facile à lire que le code de droite :

Bref, vous préférez la syntaxe de VB à celle du C ou de Java, cela sans aucun préjugé quant à la qualité des langages, laquelle n’est plus sujet à débat (voir article sur le sujet) . Mais vous appréciez à sa juste valeur la rigueur de C#.

Voici quelques petits trucs qui vous permettront de rendre votre environnement Visual Basic aussi robuste que si vous programmiez en C#. Ce sont trois options définies dans l’onglet Compilation de la fenêtre de propriétés du projet, accessible dans le bas du menu Projet de Visual Studio ou par un double-clic sur le nom du projet dans l’explorateur de solution.

Option Explicit est activée (On) par défaut et vous devriez la laisser activée. Elle vous oblige à déclarer toutes vos variables. Si vous faites une erreur de frappe en tapant le nom d’une variable, vous en êtes aussitôt averti. Si vous désactivez cette option, une erreur de frappe amène automatiquement et sans avertissement la création d’une variable de type Object. Ça vous attire?

Option Strict est désactivée (Off) par défaut. L’éditeur de code et le compilateur acceptent alors le code suivant :

D’après vous, qu’est-ce qui se produira à l’exécution? Si vous préférez être averti clairement de votre erreur au moment où vous tapez le code, plutôt que d’apprendre par un utilisateur que « l’application plante de temps en temps », réglez simplement Option Strict à On. La sonnette d’alarme (un petit souligné/ondulé bleu que Microsoft appelle affectueusement un wiggly) tintera dès qu’elle percevra un danger lors d’une assignation entre deux objets de type différent.

Option Infer n’existe que depuis la version 2008. Cette option est On par défaut. Dans ce cas, le compilateur détermine implicitement le type d’une variable en fonction de la valeur qui lui est assignée lors de sa déclaration. Le code de gauche est accepté. Quand cette option est à Off, le compilateur oblige à spécifier explicitement le type, comme dans l’exemple de droite.

Le cas du Bitmap n’est pas problématique. Mais dans le code de gauche, comment savoir si x sera un Byte, un Short, un Integer ou un Long ? Pourquoi pas même un Single ou un Double ? Le résultat sera un Integer, mais ce n’est pas évident. Et en ce qui nous concerne, du code « pas évident » est du mauvais code. Nous vous suggérons donc fortement de régler cette option à Off.

Pour éviter d’avoir à ajuster ces propriétés à chaque nouveau projet, vous pouvez changer leur valeur par défaut dans votre environnement de développement par Outils…Options…Projets et Solutions…Défauts VB.

Il y a encore quelques petits pièges à éviter pour que VB devienne un langage de professionnel1 , mais en réglant Option Explicit à On, Option Strict à On et Option Infer à Off, vous avez déjà fait un bon bout de chemin.

Cours de programmation VB.NET :

Programmation Visual Basic .NET (MN204)
Visual Basic .NET avancé : Programmation objet (MN308)

1 Entre autres, évitez d’utiliser les On Error GoTo pour gérer les erreurs. Cette vieillerie a été conservée dans le langage uniquement pour permettre la conversion d’applications VB classique à .NET. On traite maintenant les erreurs par un Try…Catch beaucoup plus efficace… et qui ne demande pas de GoTo, la commande qui a probablement contribué le plus à donner une mauvaise réputation à Visual Basic.

Visual Basic.NET : langage d'amateur ou de professionnel ?

© Jacques Bourgeois, Tous droits réservés.

• Share
• Tweet