Option Strict On e .NET para programadores VB6

https://stackoverflow.com/questions/222370

03-07-2019
|

Pergunta

Estou preparando uma aula sobre Visual Basic 2005 visando Visual Basic 6 programadores que migram para a plataforma .NET.
Eu gostaria de ter uma palavra de aconselhamento sobre se a recomendá-los para sempre habilitar a Option Strict ou não.
Eu trabalhei exclusivamente com linguagens de programação estilo C, principalmente Java e C #, então para mim conversão explícita é algo que eu sempre esperar que tenho que fazer, uma vez que nunca foi uma opção.
Entretanto Eu reconheço o valor de trabalhar com uma linguagem que foi construído com suporte para ligação tardia , porque não ter que ser excessivamente explícita sobre os tipos no código, na verdade economiza tempo. Isto é ainda mais comprovado pela difusão popular de dinâmicos digitado línguas , mesmo na plataforma .NET com o Dynamic Language Runtime.
Com isto em mente, deve alguém que está se aproximando .NET pela primeira vez usando VB.NET e com um fundo VB6 ser encorajados a entrar na mentalidade de ter que trabalhar com o tipo de tempo de compilação verificação porque essa é a "melhor prática" no CLR? Ou é "OK" para continuar a usufruir dos benefícios da ligação tardia?

Foi útil?

Solução

Sim! Option Strict é definitivamente uma das melhores práticas com .Net. Enfatize que .Net está no seu núcleo uma plataforma fortemente tipado, e será até o DLR é mais totalmente suportado. Com poucas exceções, todos os Dim e Function deve ter um tipo explícito declarado para ir com ele. Coisas como LINQ ou Boo e JScript são as exceções que confirmam a regra.

Aqui estão algumas outras coisas a apontar. Eu tenho certeza que você está bem ciente de tudo isso, mas eu tive de trabalhar e manter um monte de código VB.Net escrito por ex-VB6ers, e então isso é algo de um ponto sensível para mim:

Não use as antigas funções de string: LEN(), REPLACE(), TRIM(), etc

verrugas húngaros não são mais recomendados. oMyObject e sMyString não são kosher. Mostre-lhes a referência no Projeto Diretrizes da Microsoft se eles não acreditam você.

Certifique-se que aprender sobre os operadores lógicos nova AndAlso / OrElse

consultas parametrizadas e ADO.Net moderna. Não posso enfatizar o suficiente. Eles nunca precisará CreateObject() chamada novamente.

Scope funciona de forma diferente (e mais importante) na Net do que era em VB6. VB.Net ainda tem módulos, mas eles são agora mais análogo a uma classe estática. É importante compreender como desenvolver em um ambiente orientado objeto real ser diferente, em oposição ao apoio OOP parcial fornecida pelo VB6. Não há nenhuma boa razão mais para permitir métodos para executar a comprimentos ímpios.

Certifique-se de que eles obter uma introdução aos genéricos e Interfaces (incluindo IEnumeralbe(Of T)), e saiba por que eles nunca deve usar um ArrayList novamente.

Eu poderia continuar, mas eu só vou indicar você para o Invisível Características de VB.Net Pergunta para fechar este discurso.

Outras dicas

O tempo gasto em desenvolvimento com Option Strict permitir que você vai economizar quantidade enorme de depuração tempo mais tarde.

Option Strict, obviamente, não pode substituir boa teste de unidade - mas nem o contrário. Enquanto o teste de unidade pode detectar os mesmos erros como Option Strict, isso implica que não há erro nos testes de unidade, que o teste de unidade é feito muitas vezes e precoce, etc ....

Escrever bons testes de unidade nem sempre é trivial e leva tempo. No entanto, o compilador já implementa alguns dos testes - na forma de verificação de tipo. No mínimo, isso economiza tempo. Mais provavelmente, isso poupa um monte de tempo e dinheiro (pelo menos ocasionalmente), porque os testes foram / errônea não cobrem todos os casos / esqueceu-se de conta para mudanças no código.

Para resumir, não há nenhuma garantia de que os testes de unidade estão corretos. Por outro lado, há uma forte garantia de que o tipo de verificação executada pelo compilador é correto ou pelo menos que suas falhas (desmarcada covariância matriz, bugs com referências circulares ...) são bem conhecidos e bem documentados.

Outra soma-up: Sim, Option Strict On é definitivamente melhores práticas Na verdade, eu tenho trabalhado durante anos em comunidades online como este.. Sempre que alguém precisava de ajuda no código que, obviamente, não têm Option Strict habilitado, nós educadamente apontar isso e se recusam a dar qualquer ajuda adicional até que este foi fixas. Ele economiza muito tempo. Muitas vezes, o problema foi embora depois disso. Isto é algo análogo a usar HTML correto ao pedir ajuda em um fórum de suporte HTML: trabalho poderia HTML inválido, mas, novamente, não pode e ser a causa dos problemas. Por isso, muitos profissionais se recusam a ajuda.

SIM !!!!

Na minha opinião, tanto como um desenvolvedor, e como um SIM professor universitário.

É melhor entrar em bons hábitos desde o início, faz todo o processo muito mais fácil, e Option Strict é um daqueles itens que na minha opinião é um elemento necessário.

adicionado

Há literalmente toneladas de razões que poderiam ser listados como a razão pela qual, mas o fundamental é que é uma boa prática, e quando ensinar um novo idioma, é a chave para ensinar essas melhores práticas desde o início.

Lembre-se há dois níveis aqui.

Option Explicit Option Strict

A principal diferença entre os dois é a conversão automática que Option Strict disable de VB de diferentes tipos de dados. Você tem que usar explicitamente a função CType ou outra conversão de dados para atribuir uma variável para outro tipo.

Eu estava usando VB desde 1.0 e enquanto eu posso ver o ponto de isso eu acho que Strict é paritcularily mais zeloso quando se lida com objetos que implementaram ou herdados diferentes interfaces e classes.

Gostaria de começar com Strict em primeiro lugar e se ele começa a ficar em seu caminho, em seguida, cair para explícita. Mas nunca tanto desligar, de que maneira mentiras loucura e depuração excessivo tempo.

Ao longo dos anos, com VB eu praticamente uso duplo para todas as variáveis ??de ponto flutuante. Desta forma, você evita muitos problemas com arredondamento e perda de precisão. Em VB6 eu usei desde que ele era um inteiro de 32 bits, mas o trabalho Integer tão bem em .NET, pois é um Int32. Eu também recomendo o uso de Int32, Int16, etc, em vez de Integer, Long, etc no caso Microsoft sempre decide redefinir essas palavras-chave.

Vou discordar RS Conley (muito raro). Meus gurus VB6 favoritos - Francesco Balena, Dan Appleman - todos não gostava de conversão automática de VB6, e são em favorecer de Option Strict em .NET. Muitos programadores VB6 experientes sabem conversão automática como "tipo de mal coerção" ( pdf ), e ficará encantado para ligar Option Strict.

É ocasionalmente melhor usar um módulo pequeno, sem Option Strict, para evitar um monte de código reflexão complicada. Mas isso é a exceção que confirma a regra.

Dada a noção de Boehm que a fixação de um problema no início do ciclo de desenvolvimento consome menos recursos, eu sou um fã de cada ferramenta que ajuda os desenvolvedores a "acertar" o mais cedo possível. Por esta razão, eu sou um defensor de coisas como IntelliSense que é ao mesmo tempo um impulso eficiência, bem como uma ferramenta que ajuda a implementar o código de trabalho no início do ciclo. (Trabalho, mas não necessariamente correta.)

Por esta razão, eu também apoiar o uso de Option Strict como uma maneira de ajudar a manter erros e as conseqüentes correções profundamente em "tempo de design."

Se você está acostumado a ter seus tipos marcada, então você provavelmente vai querer opção estrita diante. desligá-lo pode ter vantagens, mas se o seu cérebro não está sintonizado com mancha erros onde seu compilador normalmente reclamar, então eu diria que para deixá-lo ligado. Eu trabalhei em VB.Net muito, e eu tenho que dizer, que mesmo que eu trabalho com opções estritas desligado a maior parte do tempo, eu vi muitas situações em que tê-lo ligado teria impedido muito poucos bugs.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow