Option Strict On et .NET pour les programmeurs VB6

https://stackoverflow.com/questions/222370

03-07-2019
|

Question

Je prépare un cours sur Visual Basic 2005 destiné aux programmeurs Visual Basic 6 migrant vers la plate-forme .NET.

Je voudrais un conseil pour leur recommander de toujours activer Option Strict ou non.

J'ai travaillé exclusivement avec des langages de programmation de style C, principalement Java et C #, donc pour moi le casting explicite est une chose que je m'attends toujours à devoir faire, car cela n'a jamais été une option.
Cependant Je reconnais l'intérêt de travailler avec un langage qui prend en charge de manière la liaison tardive , car le fait de ne pas être trop explicite à propos des types dans le code permet effectivement de gagner du temps. Ceci est encore prouvé par la diffusion populaire des langages à typage dynamique , même sur la plate-forme .NET avec Dynamic Langage Runtime.

C’est pourquoi nous incitons les personnes qui approchent .NET pour la première fois à utiliser VB.NET et qui possèdent un arrière-plan VB6 à entrer dans l’esprit de devoir travailler avec la vérification de type à la compilation , car c'est la "meilleure pratique" dans le CLR? Ou est-ce "OK"? continuer à profiter des avantages d'une liaison tardive?

La solution

Oui! Option Strict est sans aucun doute une pratique exemplaire avec .Net. Soulignez le fait que .Net est à la base une plate-forme fortement typée et le restera jusqu’à ce que le DLR soit plus complètement pris en charge. À quelques exceptions près, chaque type de code Dim et Function doit avoir un type explicite déclaré. Des choses comme LINQ ou Boo et JScript sont les exceptions qui prouvent la règle.

Voici quelques autres points à signaler. Je suis sûr que vous êtes au courant de tout cela, mais je dois travailler avec beaucoup de code VB.Net écrit par d'anciens utilisateurs de VB6 et le conserver. C'est donc un point sensible pour moi:

N'utilisez pas les anciennes fonctions de chaîne: LEN () , REPLACE () , TRIM () , etc
Les verrues hongroises ne sont plus recommandées. oMyObject et sMyString ne sont pas casher. Montrez-leur la référence dans les consignes de création de s'ils ne croient pas vous.
Assurez-vous qu'ils connaissent le nouvel opérateur logique AndAlso / OrElse
QUERIES PARAMETERISEES et ADO.Net moderne. Je ne saurais trop insister là-dessus. Ils ne devraient jamais avoir à appeler CreateObject () à nouveau.
Scope fonctionne différemment (et est plus important) dans .Net que dans VB6. VB.Net a toujours des modules, mais ils sont maintenant plus analogues à une classe statique. Il est important de comprendre en quoi le développement dans un environnement réel orienté objet peut être différent, par opposition à la prise en charge partielle de la POO fournie par VB6. Il n'y a plus de bonne raison pour permettre aux méthodes de s'exécuter à des longueurs impies.
Assurez-vous qu'ils connaissent bien les génériques et les interfaces (y compris IEnumeralbe (Of T) ), et découvrez pourquoi ils ne devraient jamais utiliser de nouveau ArrayList .

Je pourrais continuer, mais je vous indiquerai simplement les fonctionnalités cachées de VB.Net Question pour clore ce discours.

Autres conseils

Le temps passé à développer avec Option Strict enable vous fera gagner énormément de temps de débogage plus tard.

Option Strict ne peut évidemment pas remplacer de bons tests unitaires - mais ni l'inverse. Alors que les tests unitaires peuvent détecter les mêmes erreurs que Option Strict , cela implique qu’il n’ya pas d’erreur dans les tests unitaires, que les tests unitaires sont effectués souvent et à l’avance, etc. / p>

Écrire de bons tests unitaires n’est pas toujours trivial et prend du temps. Cependant, le compilateur implémente déjà certains des tests - sous forme de vérification de type. À tout le moins, cela fait gagner du temps. Plus probablement, cela économise beaucoup de temps et d’argent (au moins occasionnellement), car vos tests étaient erronés / ne couvraient pas tous les cas / avaient oublié de prendre en compte les modifications apportées au code.

En résumé, rien ne garantit que vos tests unitaires sont corrects. Par ailleurs, il existe une forte garantie que la vérification de type effectuée par le compilateur est correcte ou au moins que ses problèmes (covariance de tableaux non vérifiée, bogues avec des références circulaires…) sont bien connus et bien documentés.

Autre résumé: Oui, Option Strict On est sans aucun doute la meilleure pratique. En fait, je travaille depuis des années dans des communautés en ligne comme celle-ci. Chaque fois que quelqu'un a besoin d'aide sur un code pour lequel Option Strict n'est évidemment pas activé, nous le signalons poliment et refusons toute aide supplémentaire jusqu'à ce que cela soit corrigé. Cela fait gagner beaucoup de temps. Souvent, le problème a disparu après cela. Ceci est quelque peu analogue à l'utilisation du code HTML correct lorsque vous demandez de l'aide dans un forum d'assistance HTML: un code HTML non valide peut fonctionner, mais là encore, il se peut que cela ne fonctionne pas et soit à l'origine des problèmes. Par conséquent, de nombreux professionnels refusent d'aider.

OUI !!!!

À mon avis, à la fois en tant que développeur et en tant qu'instructeur universitaire OUI.

Il est préférable d'entrer dans les bonnes habitudes dès le départ, cela simplifie grandement le processus et Option Strict est l'un de ces éléments qui, à mon avis, constituent un élément BESOIN.

ajouté

Il existe littéralement des tonnes de raisons qui pourraient être énumérées, mais l'essentiel est qu'il s'agisse d'une meilleure pratique et que, lorsque vous enseignez une nouvelle langue, il est essentiel d'enseigner ces meilleures pratiques dès le début.

N'oubliez pas qu'il existe deux niveaux ici.

Option explicite Option Strict

La principale différence entre les deux réside dans le fait qu'Option Strict désactive la conversion automatique de différents types de données par VB. Vous devez utiliser explicitement CType ou une autre fonction de conversion de données pour affecter une variable à un autre type.

J'utilise VB depuis la version 1.0 et même si je peux comprendre le sens de ceci, je pense que Strict fait preuve de trop de zèle lorsqu'il s'agit de traiter des objets qui ont implémenté ou hérité différentes interfaces et classes.

Je commencerais par Strict au début et si cela commence à vous gêner, passez à Explicit. Mais ne désactivez jamais les deux, car c’est la folie et le temps de débogage excessif.

Au fil des années avec VB, j’utilise assez souvent Double pour toutes les variables à virgule flottante. De cette façon, vous évitez de nombreux problèmes d'arrondi et de perte de précision. Dans VB6, j’ai utilisé longtemps car c’était un entier 32 bits, mais Integer fonctionnait aussi bien dans .NET que dans un Int32. Je recommande également d'utiliser Int32, Int16, etc. au lieu de Integer, Long, etc. au cas où Microsoft déciderait de redéfinir ces mots clés.

Je ne suis pas d'accord avec les RS Conley. (très inhabituel). Mes gourous préférés en VB6 - Francesco Balena et Dan Appleman - n’aimaient pas la conversion automatique de VB6 et sont in faveur de Option Strict dans .NET. Beaucoup de programmeurs VB6 expérimentés savent que la conversion automatique est une "coercition de type pervers". ( pdf ) et sera ravi d'activer Option Strict .

Il est parfois préférable d'utiliser un petit module sans Option Strict , afin d'éviter beaucoup de code de réflexion compliqué. Mais c'est l'exception qui confirme la règle.

Etant donné que Boehm pensait que résoudre un problème plus tôt dans le cycle de développement consomme le moins de ressources, je suis fan de tous les outils qui aident les développeurs à "bien faire les choses". le plus tôt possible. Pour cette raison, je suis un partisan d’IntelliSense, qui améliore à la fois l’efficacité et l’outil, et qui vous permet d’implémenter du code de travail plus tôt dans le cycle. (Fonctionnel, mais pas nécessairement correct.)

Pour cette raison, je soutiens également l'utilisation d'Option Strict comme moyen de conserver les faux pas et les corrections qui en résultent au plus profond de la "période de conception".

Si vous avez l'habitude de faire vérifier vos types, vous souhaitez probablement que l'option soit stricte. le désactiver peut avoir des avantages, mais si votre cerveau n'est pas prêt à repérer des erreurs où votre compilateur se plaint généralement, alors je vous conseillerais de le laisser activé. J'ai beaucoup travaillé dans VB.Net, et je dois dire que même si je travaillais avec des options strictes désactivées la plupart du temps, j'ai souvent été confronté à des situations où l'activation de cette option aurait évité plusieurs bugs.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow