2010-12-30 22 views
8

Acabo de utilizar Resharper y me hizo sentir como si no supiera cómo codificar en absoluto en C#; me dio muchas sugerencias; Algunos de ellos son:Limpieza de código nítido C: reajuste

1) SomeObject o = new SomeObject();

ReSharper se convertirá en:

var o = new SomeObject() 

2) this.Loaded += new RoutedEventHandler(MainPage_Loaded);

a

this.Loaded += MainPage_Loaded; 

3) convertir mi variables y poner _ en frente de todas las variables de instancia.

4) Eliminando el nombre del padre de la clase. Probé esto en Silverlight.

public partial class MainPage : UserControl 

a

public partial class MainPage 

5) sustituir a instancia de variable

this.variable = somevalue 

a

variable = somevalue 

Son todos estos realmente necesario? ¿Realmente va a afectar la eficiencia de mi programa? Quiero decir qué tan bueno va a hacer reemplazando mis nombres de clase con la palabra clave var. Después de todo, var también se reemplaza con el nombre de clase en tiempo de compilación. ¿Está haciendo porque tiene programado para hacer o hacer estas cosas realmente afectar de alguna u otra manera?

+0

Realmente dudo sobre el punto 4. Su herencia de ruptura. –

+3

@Madhur: Solo haría eso si la otra parte de la clase parcial fuera declarada heredada de UserControl. –

+0

@Madhur: +1 en el comentario de Joe. No olvides que esta clase es "Parcial". –

Respuesta

8

Este comportamiento es configurable en todos los ajustes de ReSharper. Hay una combinación de reglas de limpieza de código (por ejemplo, si se reemplazan los usos con var-I do not!), Reglas de estilo de código (por ejemplo, nomenclatura variable) y reglas de formato (por ejemplo, cómo colocar llaves).

escribí un artículo que da una visión general de estos ajustes y cómo pueden ser utilizados para dar forma a las normas de codificación y luego aplicar de manera automática a través de código de limpieza:

http://gojisoft.com/blog/2010/05/10/coding-standards-using-resharper/

Al final del día, una Muchos de ellos se preocupan por el estilo de codificación y la eliminación de código redundante, no tienen ningún efecto sobre el código compilado. Puede configurar muchos de ellos para adaptarse a usted o al estilo de codificación de su equipo.

2

Todos estos cambios no deberían tener ningún efecto en el código compilado CIL; son solo la opinión de ReSharper sobre la legibilidad del código C#.

Puede ajustar todas esas configuraciones para satisfacer sus necesidades o las de su departamento. En su mayor parte, es una cuestión de preferencia personal.

3

No son necesarios.

Siguen un estándar de codificación establecido por el reajuste. Lo bueno es que puede configurar el estándar de codificación a su manera.

Lo mejor de resharper es que terminas aprendiendo diferentes maneras de hacer algo que siempre hiciste de cierta manera.

5

¿Son realmente necesarios?

No son necesarios.

¿Realmente va a afectar la eficacia de mi programa?

No afectará el código compilado de una manera que cambie el rendimiento o la semántica en absoluto.

Quiero decir qué tan bueno va a hacer reemplazando mis nombres de clase con la palabra clave var. Después de todo, var también se reemplaza con el nombre de clase en tiempo de compilación.

Código más legible.

¿Está funcionando porque ha sido programado para hacer o para que estas cosas realmente afecten de una u otra manera?

Sí. Estos son configurables si no te gustan.

1) Está bien.

SomeObject o = new SomeObject(); 

La primera SomeObject es redundante e inútil y con var que hay menos legible y podría decirse que sea más legible. Adicional para definiciones complejas como

var dictionary = new Dictionary<string, Dictionary<string, List<string>>(); 

es mucho más legible que la alternativa. Sin embargo, esto puede ser exagerado. Por ejemplo

string s = "s"; 

se prefiere sobre

var s = "s"; 

como es

var i = 5; 

sobre

int i = 5; 

Nota que

var i = 2147483648; 

es realmente malo porque no está inmediatamente claro cuál es el tipo de i. Para definiciones no complejas, prefiero usar la tipificación explícita sobre la implícita. Además, a veces uno quiere decir

IFoo foo = new Foo(); 

Para escribir explícitamente foo un IFoo mientras que var que escribirla como Foo.

2) Menos código es, en general, mejor código.

3) Odio esta sugerencia. Odio el guion bajo. Utilizo la convención de nomenclatura habitual para mis variables miembro y las introduzco con this para mayor claridad. Yo apagaría esta.

public SomeObject(string name) { 
    this.name = name; 
} 

es más legible que

public SomeObject(string name) { 
    _name = name; 
} 

en mi opinión.

4) Espera, ¿por qué está haciendo esto? Estoy un poco confundido por este. ¿Porque es parcial y otra parte de la definición de clase tiene la herencia? No me puedo imaginar que esté haciendo esto en un caso en el que cambia la semántica. Yo apagaría esta.

5) No me gusta este (ver 3.)

+0

Respecto al n. ° 4: Como se señala en los comentarios en el OP, ReSharper solo sugiere esto cuando la clase base es declarada por otra parte de la clase parcial. En este caso, puedo garantizar que estamos viendo el código subyacente de un UserControl de WPF, cuya interfaz XAML declara la clase base. –

+0

@djacobson: Ah, gracias. Personalmente, creo que es más claro con la declaración redundante de la clase base. – jason

+0

Re # 4, siempre elimino la clase base redundante. Lo hace más fácil si más adelante quiero cambiar mi ventana a un UserControl, o mi UserControl a una página - Solo tengo que cambiar el XAML y todo funciona. Si mantuvo el "UserControl" redundante, necesitaría cambiarlo en ambos lugares (XAML y codebehind). SECO. –

Cuestiones relacionadas