2011-01-20 13 views
15

¿El cheque del estado realmente redundante en el siguiente ejemplo ?:condición redundante cheque antes de la sugerencia de asignación para C# en ReSharper 5

public class MyClass  { 
    public bool MyProperty { get; set; } 

    public void DoSomething(bool newValue) { 
     // R# says: redundant condition check before assignment 
     // on the following line: 
     if (MyProperty != newValue) { // <====== 
      MyProperty = newValue; 
     } 
    } 
} 

Sé que de cualquier manera MyProperty se establecerá en newValue, pero es el cheque redundante?

En Adobe Flex, el getter is called implicitly by the VM se ejecuta siempre que se llama a un setter aunque no se esté realizando una comprobación explícita. El resultado final es que la comprobación antes de una asignación da como resultado dos comprobaciones, una explícita y otra implícita, lo que da como resultado una verificación redundante. ¿Pasa algo similar en C#?

Respuesta

10

Solo he visto dos situaciones en las que he visto este tipo de verificación.

El primero es cuando hay una línea de código adicional que establece otra propiedad en el objeto en True para indicar que el objeto se ha modificado. Esto normalmente se usa cuando se intenta decidir si se persiste el estado del objeto a algo así como una base de datos.

La segunda situación es cuando los tipos en cuestión son inmutables. Es posible que desee evitar establecer el valor y, por lo tanto, crear una nueva cadena, por ejemplo, cuando los valores son los mismos. Incluso entonces, solo lo he visto en ciertas aplicaciones donde el uso de memoria es crítico.

+1

En mi caso es en torno a un formas de las ventanas 'propiedad TopMost' que sí tiene efectos secundarios. Muy buenos puntos sobre los valores inmutables. –

1

Yo diría que la verificación es redundante. Tendría más sentido si tuviera una implementación de INotifyPropertyChanged, pero luego la verificación estaría en el colocador para evitar desencadenar el evento si no se realiza ningún cambio real.

4

En este caso específico, es lógicamente redundante, ya que no se está ejecutando código en el getter, solo un contenedor directo alrededor de un campo privado. Si tienes el hábito de poner cosas en tu getter que tendrían efectos secundarios, yo diría que desactives esa advertencia R #.

Puede valer la pena tratar de poner algo en el captador de la propiedad, y ver si ReSharper todavía piensa que es redundante. Si lo hace, entonces llamaría a eso un error R #.

+1

Cambié la propiedad a 'int' e incrementé el valor en el getter y todavía veo la misma sugerencia, por lo que voy a considerarlo un error de Resharper. –

+0

Es bueno saberlo, gracias. Mantendré mis ojos abiertos para ese escenario en mis cosas. –

0

si (MyProperty != newValue) es redundante, dejando la línea va a producir el mismo resultado

Cuestiones relacionadas