Opzione Strict On e .NET per programmatori VB6

Question

Sto preparando una lezione su Visual Basic 2005 indirizzata ai programmatori di Visual Basic 6 che migrano sulla piattaforma .NET.

Vorrei un consiglio sull'opportunità o meno di raccomandarli di abilitare sempre Opzione rigorosa .

Ho lavorato esclusivamente con linguaggi di programmazione in stile C, principalmente Java e C #, quindi per me il casting esplicito è qualcosa che mi aspetto sempre di dover fare, dal momento che non è mai stata un'opzione.
Tuttavia Riconosco il valore di lavorare con una lingua che ha il supporto integrato per late-binding , perché non dover essere eccessivamente espliciti sui tipi nel codice fa risparmiare tempo. Ciò è ulteriormente dimostrato dalla diffusione diffusa di linguaggi tipizzati dinamici , anche sulla piattaforma .NET con Dynamic Language Runtime.
Con questo in mente, qualcuno che si avvicina a .NET per la prima volta usando VB.NET e con uno sfondo VB6 dovrebbe essere incoraggiato ad entrare nella mentalità di dover lavorare con il controllo del tipo in fase di compilazione perché questa è la "best practice" nel CLR? O è " OK " continuare a beneficiare dei vantaggi dell'associazione tardiva?

Answer 1

Sì! Option Strict è sicuramente la migliore pratica con .Net. Sottolinea che .Net è al centro di una piattaforma fortemente tipizzata e lo sarà fino a quando il DLR non sarà più completamente supportato. Con poche eccezioni, ogni Dim e Function dovrebbe avere un tipo esplicito dichiarato conforme. Cose come LINQ o Boo e JScript sono le eccezioni che dimostrano la regola.

Ecco alcune altre cose da sottolineare. Sono sicuro che sei ben consapevole di tutto questo, ma ho dovuto lavorare e mantenere un sacco di codice VB.Net scritto da ex VB6ers, e quindi questo è qualcosa di dolente per me:

• Non utilizzare le vecchie funzioni stringa: LEN () , REPLACE () , TRIM () , ecc.
• Le verruche ungheresi non sono più consigliate. oMyObject e sMyString non sono kosher. Mostra loro il riferimento in Linee guida per la progettazione di Microsoft se non credono te.
• Assicurati di conoscere i nuovi operatori logici AndAlso / OrElse
• DOMANDE PARAMETERIZZATE e moderne ADO.Net. Non posso sottolineare abbastanza. Non dovrebbero mai aver bisogno di chiamare nuovamente CreateObject () .
• Scope funziona diversamente (ed è più importante) in .Net rispetto a VB6. VB.Net ha ancora moduli, ma ora sono più analoghi a una classe statica. È importante capire come lo sviluppo in un ambiente orientato agli oggetti reale sia diverso, al contrario del supporto OOP parziale fornito da VB6. Non ci sono più buoni motivi per consentire ai metodi di funzionare a lunghezze empie.
• Assicurati che ottengano un'introduzione a Generics and Interfaces (incluso IEnumeralbe (Of T) ), e scopri perché non dovrebbero mai più usare un ArrayList .

Potrei continuare, ma ti indicherò le Funzioni nascoste di VB.Net Domanda per chiudere questo rant.

Answer 2

Il tempo dedicato allo sviluppo con l'abilitazione Option Strict ti farà risparmiare una quantità enorme di tempo per il debug in seguito.

Answer 3

Option Strict ovviamente non può sostituire buoni test unitari, ma non viceversa. Mentre i test unitari possono rilevare gli stessi errori di Option Strict , questo implica che non ci sono errori nei test unitari, che i test unitari vengono eseguiti spesso e in anticipo, ecc….

Scrivere buoni test unitari non è sempre banale e richiede tempo. Tuttavia, il compilatore implementa già alcuni dei test, sotto forma di verifica del tipo. Per lo meno, questo fa risparmiare tempo. Più probabilmente, questo risparmia molto tempo e denaro (almeno occasionalmente) perché i tuoi test erano errati / non coprivano tutti i casi / dimenticavo di tenere conto delle modifiche al codice.

Per riassumere, non vi è alcuna garanzia che i test delle unità siano corretti. D'altra parte, c'è una forte garanzia che il controllo del tipo eseguito dal compilatore sia corretto o almeno che i suoi difetti (covarianza di array non controllata, bug con riferimenti circolari ...) siano ben noti e ben documentati.

Un altro riassunto: Sì, Opzione rigorosa su è sicuramente la migliore pratica. In effetti, ho lavorato per anni in comunità online come questa. Ogni volta che qualcuno aveva bisogno di aiuto su un codice che ovviamente non aveva Option Strict abilitato, lo segnalavamo educatamente e ci rifiutavamo di dare ulteriore aiuto fino a quando non fosse stato risolto. Risparmia così tanto tempo. Spesso, il problema era andato dopo questo. Questo è in qualche modo analogo all'utilizzo dell'HTML corretto quando si chiede aiuto in un forum di supporto HTML: HTML non valido potrebbe funzionare, ma, di nuovo, potrebbe non essere ed essere la causa dei problemi. Pertanto, molti professionisti si rifiutano di aiutare.

Answer 4

SI !!!!

A mio avviso, sia come sviluppatore che come istruttore di college SÌ.

È meglio entrare fin dall'inizio nelle buone abitudini, rende l'intero processo molto più semplice e Option Strict è uno di quegli elementi che a mio avviso è un elemento NECESSARIO.

aggiunto

Ci sono letteralmente tonnellate di ragioni che potrebbero essere elencate sul perché, ma la chiave è che è una buona pratica e quando si insegna una nuova lingua, è fondamentale insegnare quelle migliori pratiche dall'inizio.

Answer 5

Ricorda che ci sono due livelli qui.

Opzione esplicita Opzione rigorosa

La principale differenza tra i due è che Option Strict disabilita la conversione automatica di VB di diversi tipi di dati. Devi usare esplicitamente CType o un'altra funzione di conversione dei dati per assegnare una variabile a un altro tipo.

Uso VB dall'1.0 e mentre riesco a capire il punto, penso che Strict sia fin troppo zelante paritcularmente quando si tratta di oggetti che hanno implementato o ereditato interfacce e classi diverse.

Comincerei con Strict all'inizio e se inizia a intralciarti, passa a Esplicito. Ma non spegnere mai entrambi, in questo modo risiedono la follia e il tempo eccessivo di debug.

Nel corso degli anni con VB ho praticamente usato Double per tutte le variabili in virgola mobile. In questo modo si evitano molti problemi di arrotondamento e perdita di precisione. In VB6 ho usato fintanto che era un numero intero a 32 bit, ma Integer funziona altrettanto bene sia in .NET che in Int32. Consiglio inoltre di utilizzare Int32, Int16, ecc. Anziché Integer, Long, ecc. Nel caso in cui Microsoft decida di ridefinire tali parole chiave.

Answer 6

Non sono d'accordo con RS Conley (molto insolito). I miei guru VB6 preferiti - Francesco Balena, Dan Appleman - non hanno apprezzato la conversione automatica di VB6 e sono in favor di Opzione rigorosa in .NET. Molti programmatori VB6 esperti conoscono la conversione automatica come "coercizione di tipo malvagio" ( pdf ) e saremo lieti di attivare Option Strict .

Occasionalmente è meglio usare un piccolo modulo senza Option Strict , per evitare molti complicati codici di riflessione. Ma questa è l'eccezione che dimostra la regola.

Answer 7

Data l'idea di Boehm secondo cui risolvere un problema all'inizio del ciclo di sviluppo consuma meno risorse, sono un fan di ogni strumento che aiuta gli sviluppatori a "farlo bene". il prima possibile. Per questo motivo, sono un sostenitore di cose come IntelliSense che è sia una spinta all'efficienza che uno strumento che ti aiuta a implementare il codice di lavoro all'inizio del ciclo. (Funziona, ma non necessariamente corretto.)

Per questo motivo, sostengo anche l'uso di Option Strict come modo per aiutare a mantenere i passi falsi e le conseguenti correzioni in profondità nel "tempo di progettazione". "

Answer 8

Se sei abituato a controllare i tuoi tipi, probabilmente vorrai l'opzione rigorosa. disattivarlo può avere dei vantaggi, ma se il tuo cervello non è sintonizzato per individuare errori in cui il tuo compilatore di solito si lamenterebbe, direi di lasciarlo acceso. Ho lavorato molto su VB.Net e devo dire che, anche se lavoro con opzioni rigorose disattivate per la maggior parte del tempo, ho visto molte situazioni in cui averlo attivato avrebbe impedito un bel po ' bug.