remarks - C#- StyleCop-SA1121: UseBuiltInTypeAlias-Reglas de legibilidad

remarks c#

Question

No lo encontré en el Manual de Ayuda de StyleCop, en SO y Google, así que aquí está;)

Durante el uso de StyleCop tengo una advertencia:

SA1121 - UseBuiltInTypeAlias ​​- Reglas de legibilidad

El código usa uno de los tipos básicos de C #, pero no usa el alias incorporado para el tipo.

En lugar de utilizar el nombre de tipo o el nombre completo del tipo, los alias incorporados para estos tipos siempre deben usarse: bool, byte, char, decimal, doble, corto, int, largo, objeto, sbyte, float, cadena , ushort, uint, ulong.

tan String.Empty está mal (depende de las reglas anteriores) y string.Empty es bueno.

¿Por qué usar alias integrados es mejor? Puede String. Int32 String. Int32 , Int64 (etc.) complican algo en el código en escenarios especiales?

Answer 1

Esta regla de StyleCop supone que el uso de alias introduce menos confusión al "usuario de lenguaje promedio" que se cree que existe. Lo que sabe, por ejemplo, tipo ''largo'', pero de alguna manera aterrador de tipo ''System.Int64'' y se confunde, lo ve. Personalmente, creo que es importante ser coherente en el estilo de su código, es imposible satisfacer a todos .

Answer 2

Menos confuso? Me parece muy incómodo para un tipo de datos base, que tradicionalmente es solo un valor, incluir funciones estáticas. Entiendo usar el tipo de datos base equivalente si solo está almacenando un valor, pero para acceder a los miembros de la clase, parece muy incómodo poner un. (Punto) después del nombre del tipo de base.

Answer 3

Porque el alias incorporado es una forma más natural de expresar el concepto en ese idioma.

Algunas culturas dicen fútbol, ​​otros dicen fútbol. Cuál es más apropiado depende del contexto.

Answer 4

Realmente complicaría el código si tuviera sus propios tipos String , Int32 etc. que podrían terminar siendo utilizados en lugar de System.* - ¡y no haga eso!

En definitiva, es una preferencia personal. Utilizo los alias en todas partes, pero sé que algunas personas (por ejemplo, Jeffrey Richter) aconsejan no utilizarlas nunca . Probablemente sea una buena idea ser consistente, eso es todo. Si no te gusta esa regla de StyleCop, desactívala.

Tenga en cuenta que los nombres de los métodos, etc. deben usar el nombre del marco en lugar del alias, para que sean neutrales en cuanto al idioma. Esto no es tan importante para los miembros privados / internos, pero también podría tener las mismas reglas para los métodos privados que para los públicos.

Answer 5

Solo para aclarar: no todos están de acuerdo con los autores de StyleCop. Win32 y .NET gurú Jeffrey Richter escribe en su excelente libro CLR a través de C # :

La especificación del lenguaje C # establece: "Como cuestión de estilo, se prefiere el uso de la palabra clave sobre el uso del nombre completo del tipo de sistema". No estoy de acuerdo con la especificación del idioma; Prefiero usar los nombres de tipo FCL y evitar por completo los nombres de tipos primitivos. De hecho, me gustaría que los compiladores ni siquiera ofrecieran los nombres de tipos primitivos y forzaran a los desarrolladores a usar los nombres de tipos de FCL. Aquí están mis razones:

• He visto a varios desarrolladores confundidos, sin saber si usar cadena o cadena en su código. Debido a que en C # string (una palabra clave) se asigna exactamente a System.String (un tipo FCL), no hay diferencia y puede usarse. De manera similar, escuché a algunos desarrolladores decir que int representa un entero de 32 bits cuando la aplicación se ejecuta en un sistema operativo de 32 bits y que representa un entero de 64 bits cuando la aplicación se ejecuta en un sistema operativo de 64 bits. Esta afirmación es absolutamente falsa: en C #, una int siempre se asigna a System.Int32 , y por lo tanto representa un entero de 32 bits independientemente del sistema operativo en el que se ejecuta el código. Si los programadores usan Int32 en su código, esta posible confusión también se elimina.

• En C #, los mapas largos a System.Int64 , pero en un lenguaje de programación diferente, long se puede asignar a un Int16 o Int32 . De hecho, C ++ / CLI trata a largo como un Int32 . Alguien que lea el código fuente en un idioma podría malinterpretar fácilmente la intención del código si estuviera acostumbrado a programar en un lenguaje de programación diferente. De hecho, la mayoría de los idiomas ni siquiera tratarán como una palabra clave y no compilarán el código que la usa.

• La FCL tiene muchos métodos que tienen nombres de tipos como parte de sus nombres de métodos. Por ejemplo, el tipo BinaryReader ofrece métodos como ReadBoolean , ReadInt32 , ReadSingle , etc., y el tipo System.Convert ofrece métodos como ToBoolean , ToInt32 , ToSingle , etc. Aunque es legal escribir el siguiente código, la línea con flotador se siente muy antinatural para mí, y no es obvio que la línea sea correcta:

  BinaryReader br = new BinaryReader(...);
  float val = br.ReadSingle(); // OK, but feels unnatural
  Single val = br.ReadSingle(); // OK and feels good

• Muchos programadores que usan C # exclusivamente tienden a olvidar que se pueden usar otros lenguajes de programación en contra del CLR, y debido a esto, los C -ismos se infiltran en el código de la biblioteca de la clase. Por ejemplo, la FCL de Microsoft está escrita casi exclusivamente en C # y los desarrolladores del equipo FCL ahora han introducido métodos en la biblioteca como GetLongLength de Array , que devuelve un valor Int64 que es largo en C # pero no en otros idiomas (como C ++ / CLI). Otro ejemplo es el método LongCount de System.Linq.Enumerable .

Answer 6

Una analogía podría ayudar: la cadena es para System.String como mosquete para rifle. string es una reliquia de un idioma antiguo y se proporciona para los programadores antiguos. C # no tiene tipos de datos "incorporados" y estos alias se proporcionan para una generación de programadores "C" que tienen problemas con este concepto.