Opción Infer Activado o Desactivado?

Question

Duplicar posible:
Best Practices: Option Infer
What is the best way to mix VB.NET's Option Strict and the new Option Infer directives?

Estoy desarrollando una solución de edad, que se tradujo del VB6 a la VB.NET.

En realidad, las opciones por defecto en archivos son

Option Strict On 
Option Explicit On 

Quiero usar LINQ, y encontraron que es más fácil de usar también la Option Infer On.

Menos escribir, menos (por lo tanto, más fácil) de leer.

Sin embargo, una parte (conservadora, desde mi punto de vista) del equipo mantiene desactivada la Opción Inferida e insisten en que no la utilicen en absoluto, sin explicar explícitamente las causas.

En su opinión, ¿cuáles son los "peligros" de utilizar Option Infer On, junto con otras dos opciones (estricta y explícita, ambas activadas)?

Answer 1

En mi caso, yo prefiero tener todos de la

pero tener Deducir OFF es "ok", sólo tiene que escribir más ;-)

Answer 2

Más y más idiomas inferir el tipo de sus variables. Considera C#, F # y posiblemente una gran cantidad de lenguajes que no sean de .NET.

Mantiene la seguridad de tipo con option infer on. Las personas a las que les gusta especificar sus variables aún pueden hacerlo. Pero a veces es casi imposible y definitivamente hace que leer código sea más difícil, con esos nombres crípticos que terminas cuando usas LINQ.

Yo solía ser de la vieja escuela. Pero cuando deduje entrar en el mundo C#, después de un tiempo simplemente tuve que admitirlo: mejora la velocidad de codificación, la legibilidad y, por lo tanto, la calidad y facilita el mantenimiento de tu código. Esto no significa que deba dejar de especificar todas sus variables. En muchos casos, es mejor especificar los tipos, independientemente de si inferir está activado o desactivado. De nuevo: por el bien de la legibilidad.

Explique a la gente de la vieja escuela por qué querría que estuviera activada de manera predeterminada y que aún así puedan escribir sus nombres si así lo desean.

Answer 3

El código escrito con Option Infer en no es diferente en rendimiento o tipo de seguridad que el código escrito con los mismos tipos explícitamente declarados. Con esto en mente, los argumentos que podrían llegar a contra Option Infer son:

• La inconsistencia entre los casos en que se debe especificar el tipo y cuando se puede inferir.

  • No se pueden inferir los campos de clase para uno, incluso si se inicializa en línea.
  • Las variables que contienen lambdas (Dim f = Function(x) ...) no siempre infieren los tipos.
  • variables que no se inicializan deben recibir un tipo

  La fuerza de este argumento es directamente proporcional a la consistencia de estilo en su base de código existente. (Por ejemplo, a veces todavía uso de guiones para seguir las líneas cuando se trabaja con código antiguo, incluso cuando el nuevo compilador no requiere de ellos, si el resto del código alrededor de ella los usa.)

• A veces el tipo no es inmediato obvio al mirar a través del código.

  Dim temp = Foo() 'temp is type of Foo's return, which is... 
  

  Solución: Declarar tipo de la variable cuando se siente la necesidad.

  Esto no es un "peligro" tanto como un inconveniente potencial. Más aún si no está trabajando en un entorno donde Intellisense no puede decirle el tipo inferido.

• El tipo inferido puede terminar siendo más específico de lo que realmente desea en ese caso.

  Solución alternativa: Específicamente declare el tipo que desea en ese caso.

  Como el compilador detecta casos cuando esto es un problema, yo no lo llamaría un "peligro" per se. La única vez que puedo pensar en dónde podría ser un problema que el compilador no detecta sería si tiene sobrecargas diferentes de un método para los tipos base y derivados o son métodos de sombreado en un tipo derivado. Yo diría que cualquiera de esos casos son problemas con el código existente y no con Option Infer.

• El uso de tipos anónimos que aparecen en las consultas LINQ podría dar lugar a métodos más grandes que lo normal, ya que no se pueden pasar entre los métodos.

  Solución alternativa: Defina los tipos con nombre cuando esto ocurra y divida los métodos de la forma habitual.

  Esto es más un peligro en la medida en que los métodos largos son peligrosos. Se aplican las discusiones habituales de "cuánto tiempo es demasiado largo".

• Me hace parecer menos productivo porque hay menos KB en mis archivos de código de todos los nombres de tipos que no tengo que escribir. (OK, esta es una broma.)