2009-08-19 8 views
6

simplemente he instalado Remodeladora 4.5 y se ha llegado con las siguientes sugerencias:¿Resharper es correcto?

return this.GetRuleViolations().Count() == 0; -- REMOVE this. 

new string[] { this.ID.ToString(), this.Registration } -- REMOVE string, MAKE ANONYMOUS TYPE 

int i = Method.GetNumber(); -- REPLACE int WITH var 

debo hacer esto?

Creo que en algunos casos hará que el código sea menos legible, pero ¿mejorará el rendimiento? ¿Cuáles son los beneficios de hacer estos cambios?

Gracias

+1

Solo hay una canción de Rigobert. Asegúrese de verificar las diversas ocurrencias dup de las subcuestiones de esto en este foro. –

+1

Intente instalar StyleCop y StyleCop-for-ReSharper, que le proporcionará las pautas de estilo de codificación recomendadas por Microsoft. Sin embargo, necesitarás modificar las reglas de R # para que coincidan. En cuanto al uso de var, siempre lo usamos internamente, ya que ayuda a la legibilidad en nuestra opinión, los tipos son para el compilador, no para los humanos. –

+1

Hm. Siempre he usado el tipo - supongo que siento que debes estar al tanto de lo que estás recuperando de tus expresiones lambda, y ayuda un poco si lo estás especificando. – Yablargo

Respuesta

12

1) El puntero explícita this sólo es necesario cuando la referencia haría de lo contrario ser ambiguo. Como GetRuleViolations se define en el tipo, lo más probable es que no necesite this.

Otro punto aquí es que si GetRuleViolations devolver un IEnumerable de algo, por lo general será mucho mejor usar Any() en lugar de Count() == 0 a medida que corre el riesgo de enumerar toda la secuencia.

2) La cadena se puede deducir de la inicialización.

3) Resharper prefiere var sobre tipos específicos.

+0

+1 - Bonito consejo para usar Cualquier() gracias –

0

primera: ReSharper está preguntando por la eliminación de this que es sólo una cosa de estilo para mí. Nada más, mantenerlo no dañará el rendimiento de ninguna manera. Es solo una cuestión de legibilidad.

Para el segundo y tercer: Resharper normalmente prefiere usar var en lugar de un tipo de datos específico, es por eso que las sugerencias. Creo que es una cuestión de elección personal y no ofrece ninguna ganancia extra aparte de la legibilidad.

0

Lo primero no me parece claro. Por lo general, no es necesario que prefija this., siempre que no haya ambigüedades, lo que no puedo deducir de este ejemplo. Resharper probablemente tenga razón. Los otros dos no mejorarán el rendimiento, el resultado compilado será el mismo. Es solo una cuestión de gusto y, por supuesto, sus pautas de codificación.

0

El primero debe ser configurable. Por lo que recuerdo, puedes decirle a ReSharper si quieres tener "esto". frente a solo campos, métodos, ambos o ninguno.

El uso de "var" no cambiará nada en el código CIL generado, por lo que el rendimiento seguirá siendo el mismo. No he usado ReSharper por un tiempo y no sé por qué promueve los tipos anónimos tan agresivamente, pero una de las ventajas de "var" es que es más resistente al cambio.

Significado si, en lugar de llamar a Method.GetNumber(), llamó a un contenedor, por ejemplo. Filter (Method.GetNumber()) en la misma línea que devuelve un Nullable, no tendrá que actualizar el tipo de variable.

1

Creo que el primero es para este fin, si desea hacer de "GetRuleViolations()" un método estático. Entonces no tiene que eliminar el identificador "this".

2

Para la tercera, la que más me molesta. Proporciona al lector menos información y creo que solo se trata de mostrar una característica nueva.

diría - var uso cuando se conoce el tipo de retorno y utilizar el tipo de objeto correcto cuando no te gusta esto:

var reader = new XmlReader(.... // Implicit 
XmlReader reader = SomeClass.GetReader() // Explicit when you can't be sure 
3

Además de la ventaja obvia de que su pequeño cuadrado se vuelva verde, si está escribiendo código que alguien más tarde conservará, tiene sentido no utilizar sus preferencias personales en la sintaxis de codificación. Resharper se está volviendo útil para formatear el código de una manera que sea reconocible para un público muy amplio.

Pertenezco a la escuela de pensamiento que dice que no importa quién es el camino correcto. Si todos nos atenemos a un patrón, todos nos resultará más fácil leer el código de los demás.

Por lo tanto, en mi humilde opinión, no cambie la configuración de reajuste predeterminada. Simplemente acepte que si utiliza los valores predeterminados, hace la vida simple para todos.

+1

Estoy de acuerdo con usted en el uso de las herramientas predeterminadas. Desafortunadamente, por lo que he visto, no me gustan los valores predeterminados de Resharper. –

+1

Siempre cambiaría la configuración 'var' de resharper a tipo explícito debido a la SEGURIDAD. Legible está bien, pero puede causar daños graves después de que alguien refactorice. – Offler

0

Ninguno de estos tendrá ningún efecto en el rendimiento, solo en la legibilidad.

Encuentro que las sugerencias 1 y 2 son más legibles y 3 menos legibles que el código original.

Pero no solo necesita seguir estas sugerencias si, por ejemplo, las encuentra menos legibles o si infringen el estándar de estilo de código de su empresa. Cuando coloca el cursor en la línea ondulada, presione Alt-Intro para mostrar la lista de Acciones Contex. Uno de ellos será para cambiar la severidad de la inspección; no puedes mostrarlo en absoluto o mostrarlo como una pista. Puede encontrar una lista completa de inspecciones en ReSharper | Opciones | Inspección de código | Severidad de inspección.