¿Por qué var a ser una mala cosa?

https://stackoverflow.com/questions/545616

23-08-2019
|

Pregunta

He estado charlando con mis compañeros el otro día y escuchó que su estándar de codificación prohíbe explícitamente el uso de los var la palabra clave en C#.Ellos no tenían idea de por qué fue así y siempre lo he encontrado declaración implícita de ser increíblemente útil cuando la codificación.Nunca he tenido ningún problema para encontrar cuál es el tipo de la variable (que sólo pase el ratón sobre la variable en VS y recibirá el tipo de esa manera).

¿Alguien sabe por qué sería una buena idea utilizar la palabra clave var en C#?

Solución

Los escritores de la .NET Framework Guías de Diseño (libro impresionante) que salió en noviembre de 2008 recomiendan considerar el uso de var cuando el tipo es obvio e inequívoco.

Por otro lado, si se utiliza var daría lugar a una ambigüedad al leer el código, como Anton Gogolev señaló, entonces es mejor no utilizarlo.

en el libro (Anexo A), que en realidad dan este ejemplo:

var names = new List<string>(); // good usage of var

string source = GetSource();
var tokens = source.Split(' '); // ok; most developers know String.Split

var id = GetId(); // Probably not good; it's not clear what the type of id is

Es posible que, para asegurarse de que la lectura no está sometido a los caprichos de los desarrolladores de condición humilde, su organización ha decidido que usted no era digno de var y prohibió.
Es una pena, sin embargo, es como tener una buena herramienta a su disposición, pero manteniéndolo en una vitrina cerrada.

En la mayoría de los casos, el uso de var para los tipos simples en realidad ayuda a la legibilidad y no hay que olvidar que también hay ninguna penalización en el rendimiento para el uso de var.

Otros consejos

var q = GetQValue();

es de hecho algo malo. Sin embargo,

var persistenceManager = ServiceLocator.Resolve<IPersistenceManager>();

está perfectamente bien para mí.

La línea de fondo es: usar nombres de identificadores descriptivos y obtendrá lo largo de bien

Como nota al margen: Me pregunto ¿cómo se ocupan de los tipos anónimos cuando no está permitido el uso de palabras clave var. O que no utilizan por completo?

En la mayoría de los casos cuando se utiliza racionalmente (es decir,un tipo simple de inicializador donde el tipo y el valor son el mismo), entonces es correcto.

Hay algunas veces en que no está claro que se ha roto cosas por cambiarlo, principalmente, cuando el tipo inicializado y el (original) tipo de variable no son lo mismo, porque:

la variable fue originalmente la base de la clase
la variable fue originalmente una interfaz
la variable fue originalmente de otro tipo con una conversión implícita operador

En estos casos, puede tener problemas con cualquier tipo de resolución - por ejemplo:

los métodos que tienen diferentes sobrecargas para los dos tipos de competencia
los métodos de extensión que se definen de forma diferente para los dos tipos de competencia
los miembros que han sido re-declaró (oculto) en uno de los tipos de
tipo genérico de inferencia funcionará de forma diferente
resolución de operador trabajará de manera diferente

En tales casos, puede cambiar el significado del código, y la ejecución de algo diferente.Esto es una mala cosa.

Ejemplos:

La conversión implícita:

static void Main() {
    long x = 17;
    Foo(x);
    var y = 17;
    Foo(y); // boom
}
static void Foo(long value)
{ Console.WriteLine(value); }
static void Foo(int value) {
throw new NotImplementedException(); }

Método de ocultación:

static void Main() {
    Foo x = new Bar();
    x.Go();
    var y = new Bar();
    y.Go(); // boom
}
class Foo {
    public void Go() { Console.WriteLine("Hi"); }
}
class Bar : Foo {
    public new void Go() { throw new NotImplementedException(); }
}

etc

Sin duda, esto es un error. Se debe a que alguna gente no se da cuenta de que en realidad es inflexible y no como una var en VB.

No todos los estándares de codificación corporativos tienen sentido, una vez trabajé para una empresa que quería delante de todos los nombres de las clases con el nombre de la empresa. Hubo una reanudación masiva cuando la compañía cambió su nombre.

En primer lugar, como regla general, las normas de codificación deben ser discutidos y acordados por el equipo, y el razonamiento detrás de ellos se deben anotar, por lo que cualquiera puede saber por qué están allí. Ellos no deben ser la Santa Verdad de un amo.

En segundo lugar, esta regla es probablemente justifica porque código es leído más veces de lo escrito . var acelera la redacción, pero puede ralentizar la lectura de un bit. Obviamente no es una regla de comportamiento de código como "inicializar las variables siempre" porque las dos alternativas (escritura y la escritura var el tipo) tienen exactamente el mismo comportamiento. Así que no es una regla fundamental. Yo no lo quiera var, yo sólo tiene que utilizar "Prefiero ..."

escribí un artículo en el blog sobre este tema hace unos meses. Para mí, lo uso todos los que sea posible y diseño específicamente mis API de todo tipo de inferencia. Las razones básicas que utilizan la inferencia de tipos son

No reduce la seguridad de tipos
Se va a aumentar la seguridad teclee el código alertando a conversiones implícitas. El mejor ejemplo de la instrucción foreach
Mantiene principios DRY en C #. Esto es específicamente para el caso de declaración, ¿por qué molestarse diciendo el nombre dos veces?
En algunos casos se requiere de plano. Ejemplo tipos anónimos
Menos de escribir sin pérdida de funcionalidad.

http: // blogs.msdn.com/jaredpar/archive/2008/09/09/when-to-use-type-inference.aspx

var es el último "cómo diseñar los aparatos de ortodoncia" notación / húngaro / Camel debate carcasa. No hay una respuesta correcta, pero hay personas que se sientan en los extremos.

Su amigo es desafortunado que trabajan por debajo de uno de los extremistas.

Prohibir por completo significa que prohíbe el uso de los tipos anónimos (que se convierten en muy útil cuando se utiliza LINQ más).

Esta es la estupidez simple y llanamente a menos que alguien puede formalizar una buena razón para no utilizar los tipos anónimos.

Se puede hacer daño a la legibilidad si se utiliza mal. Sin embargo completamente prohibiendo que es un poco extraño que sus colegas van a tener un tiempo difícil usando los tipos anónimos sin él.

Esto es realmente un problema de legibilidad con su código.

Mi preferencia personal es utilizar únicamente "var" para los tipos anónimos (de hecho, si desea utilizar los tipos anónimos en absoluto, tendrá que utilizar var), y estos en su mayoría provienen de las consultas LINQ. En estos casos, no tiene más remedio que utilizar var si su consulta está proyectando en una nueva (implícita y anónima) tipo.

Sin embargo, C # 3.0 felizmente le permite utilizar la var cualquier lugar que desee, fuera de LINQ y los tipos anónimos, por ejemplo:

var myint = 0;
var mystring = "";

es perfectamente válido, y Myint y mystring estarán fuertemente tipificado por los valores inferidos utilizados para inicializar ellos. (Por lo tanto, Myint es un System.Int32 y mystring es un System.String). Por supuesto, es bastante obvio cuando se mira en los valores que se utilizan para inicializar las variables que tipos van a ser escritos de manera implícita a, sin embargo, creo que es incluso mejor para la legibilidad del código si lo anterior se escribe como:

int myint = 0;
string mystring = "";

ya que se puede ver de inmediato a simple vista exactamente qué tipo son aquellas variables.

Considere este escenario un tanto confuso:

var aaa = 0;
double bbb = 0;

Código perfectamente válido (aunque un poco no convencional), pero en lo anterior, sé que la acreditación es un doble, a pesar del valor de inicialización que parece ser un int, pero aaa definitivamente no será un doble, sino más bien un int.

Usted puede considerar la opinión de Microsoft para ser relevante, ya que C # es su idioma:

"Sin embargo, el uso de var no tiene al menos el potencial para hacer que su código sea más difícil de entender para otros desarrolladores. Por esa razón, la documentación C # utiliza generalmente var sólo cuando es necesario ".

MSDN - Variables locales con tipo Implícitamente (C # Guía de Programación) , último párrafo.

También debe tener en cuenta que var elimina la prueba de tipo de datos en tiempo de compilación en la asignación inicial.

var x = "mistake";     // error not found by compiler
int x = "mistake";     // error found

Como la mayoría de las variables sólo se asignan una vez, el uso constante de var elimina casi todas las pruebas de tipo de datos sobre las asignaciones de variables.

Esto hace que su código vulnerable a los cambios accidentales por ejemplo, las realizadas por las herramientas de mezcla o desarrolladores cansados.

tipos implícitos es grande, y la gente que de plano prohíbe que daña la productividad y el código de invitación frágil.

Es casi como, duck typing compilador a cuadros de tipo seguro, que es increíblemente útil al refactorizar. Por ejemplo, si tengo un método que devuelve una lista, y yo refactorearlo para volver IEnumerable, entonces cualquier personas que llaman a este método que han utilizado la palabra clave var y sólo utilizar métodos IEnumerable va a estar bien. Si he especificado de forma explícita, por ejemplo, la lista, entonces tengo que ir y cambiar eso a IEnumerable en todas partes.

Obviamente, si alguna de las personas que llaman-tipos implícitos requieren métodos lista, entonces me van a errores de compilación cuando construyo, pero si ese es el caso, probablemente no debería haber estado cambiando el tipo de retorno de todos modos.

Eric Lippert lo resume así :

Uso var cuando se tiene que; cuando está usando los tipos anónimos.
Uso var cuando el tipo de la declaración es evidente desde el inicializador, especialmente si se trata de una creación de objetos. Esto elimina la redundancia.
Considere el uso de var si el código hace hincapié en la "fines comerciales" semántica de la variable y resta importancia a los detalles "mecánicos" de su almacenamiento.
Usar tipos explícitos si hacerlo es necesario que el código para ser comprendido y mantenido correctamente.
Utilice nombres de variables descriptivas, independientemente de si utiliza el "var". Los nombres de variables deben representar la semántica de la variable, no los detalles de su almacenamiento; "DecimalRate" es malo; "TasaDeInterés" es bueno.

Mi opinión: Me resulta difícil de leer y un poco sin sentido con tipos como int, string, bool o incluso un User. Se trata de la legibilidad después de todo (excepto cuando se utiliza con LINQ), por lo que cuando VARs se salpicaron de ello puede ser más difícil de leer y derrotar el propósito de la palabra clave que los diseñadores del lenguaje destinados para.

Departamento de Declaración Departamento Redundancia (de Jeff < a href = "http://www.codinghorror.com/" rel = "nofollow noreferrer"> Coding Horror ):

"Yo uso a escribir la variable implícita cuando y donde hace mi código más concisa. Cualquier cosa que elimina redundancia de nuestro código debe ser agresivamente perseguido - hasta e incluyendo el cambio de idioma ".

Yo mismo creo que es sobre la pena tomar, pero la creación de una guía completa sobre cuándo se debe utilizar o no sería exageración .

he tenido casos (cuando forEach través de una colección Table.Rows) cuando se utiliza var resultó en el ser tipo de alguna clase de base en lugar del tipo DataRow real. Esa es la única vez que he tenido problemas con var.

'var' se trata de ser claro

El principal debate sobre si se debe utilizar la palabra clave var o no es acerca de cómo leer el código es a usted y otros desarrolladores.

Al igual que si estuviera escribiendo una historia que no hay respuesta correcta definitiva. Pero vamos a ver algunos ejemplos de esto en la llanura Inglés.

Jake dijo hola a Bill. Él no le gustaba así que se volvió y se fue a la inversa.

¿Quién fue a la inversa? Jake o Bill? En este caso, "Jake" y "Bill" son como el nombre del tipo. Y "él" y "él" son como la palabra clave var. En este caso, podría ayudar a ser más específico. El siguiente, por ejemplo, es mucho más claro.

Jake dijo hola a Bill. Jake no le gustaba Bill así que se volvió y se fue a la inversa.

En este caso siendo más específica hecha la frase más clara. Pero eso no siempre va a ser el caso. En algunos casos, ser específico hace que sea más difícil de leer.

Bill le gustan los libros, por lo que Bill fue a la biblioteca y Bill sacó un libro que Bill siempre le ha gustado.

En este caso, sería más fácil de leer la sentencia si utilizamos "él" y en algunos casos dejan su nombre todos juntos, esto es el equivalente de la utilización de la palabra clave var.

Bill le gustan los libros, así que fue a la biblioteca y sacó un libro que siempre le ha gustado.

Estas analogías cubren lo esencial, pero no cuentan toda la historia. Ver en esos ejemplos sólo había una manera de referirse a la persona. Ya sea con su nombre, por ejemplo Bill, o de manera más general, como "él" y "él". Pero sólo estamos trabajando con una sola palabra.

En el caso del código tiene dos "palabras", el tipo y el nombre de la variable.

Person p = GetPerson();

La pregunta ahora es ¿hay suficiente información allí para que usted pueda determinar fácilmente lo que es p? ¿Todavía sé lo que la gente es en este escenario:

var p = GetPerson();

¿Qué tal este:

var p = Get();

¿Qué tal este:

var person = Get();

O esta otra:

var t = GetPerson();

O esta otra:

var u = Person.Get();

Si la palabra clave var funciona en una situación dada depende mucho del contexto del código, al igual que lo que los nombres de las variables, clases y métodos son, así como la complejidad del código.

En lo personal me gusta usar la palabra clave var es más amplia a . Pero también tiendo a nombre de mi variables después del tipo así que no estoy realmente perder ninguna información.

Una vez dicho esto a veces hago excepciones, tal es la naturaleza de algo complejo, y el software es nada si no es complicado.

Estos son los resultados de una prueba me encontré en la eficiencia de var frente tipificación explícita:

  private void btnVar_Click(object sender, EventArgs e)
    {
        Stopwatch obj = new Stopwatch();
        obj.Start();
        var test = "Test";
        test.GetType();
        obj.Stop();
        lblResults.Text = obj.Elapsed.ToString();
    }

    private void btnString_Click(object sender, EventArgs e)
    {
        Stopwatch obj = new Stopwatch();
        obj.Start();
        string test = "Test";
        obj.Stop();
        lblResults.Text = obj.Elapsed.ToString();

    }

En primer resultado Label es: 00:00:00 000034

En segundo resultado Label es: 00:00:00 00008

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow