¿Cómo implico la verificación nula?

Question

Estoy trabajando en un gran proyecto en el que, incluso con 10s de miles de pruebas automatizadas y cobertura de código 100%, estamos obteniendo una cantidad ridícula de errores. Aproximadamente el 95% de los errores que obtenemos son NullReferenceExceptions.

¿Hay alguna manera de forzar la comprobación nula en tiempo de compilación?

Al margen de eso, ¿hay alguna forma de aplicar automáticamente la verificación nula en pruebas unitarias sin tener que escribir las pruebas para casos nulos?

Answer 1

Debería mirar en Code Contracts. El verificador estático solo está disponible para las ediciones VS de nivel superior, pero eso es básicamente lo que buscas.

Hay muchos recursos en línea, y <plug> también puede leer una versión preliminar del capítulo sobre Contratos de código de la 2da edición de C# en profundidad - download chapter 15 for free. </plug> (El capítulo está ligeramente desactualizado con respecto a la compilación más reciente y mejor de Contratos de código, pero nada importante)

Answer 2

ninguno de esos es posible con C# 3. tendrías que usar algo como SpeC# ... creo que C# 4 puede tener algo de eso integrado, pero no estoy seguro de eso.

especificaciones #: http://research.microsoft.com/en-us/projects/specsharp

Answer 3

100% de cobertura de código no significa nada.

Es una falsa sensación de seguridad.

Lo único que está midiendo es que está ejecutando todas las líneas de código.

No

:

• Que esas líneas de código son todas las líneas de código que debería haber estado allí
• Que esas líneas de código funcionan correctamente (que está poniendo a prueba todos los casos extremos?)

Por ejemplo, si su procedimiento para hacer frente a un incendio contiene 1 paso "ejecutar fuera del edificio", incluso si eso ocurre en el 100% de los casos, quizás un mejor procedimiento sería "alertar al fuego" departamento, intente detener el fuego, luego agote si todo lo demás falla ".

No hay nada integrado en C# que lo ayude con esto sin que usted específicamente ingrese y agregue código, ya sea contratos de código (.NET 4.0) o declaraciones IF específicas (< 4.0).

Answer 4

No puede tener una comprobación nula en tiempo de compilación ya que en el momento de la compilación los objetos son solo Tipos y solo en en tiempo de ejecución, los tipos se convierten en instancias que tienen un valor concreto ... aquí nulo.

Answer 5

Esto no es una solución técnica, sino social. Simplemente haga que sea inaceptable en su entorno acceder a un tipo de referencia sin verificar si el tipo de referencia ha sido modificado de alguna manera por un código externo (otra llamada a método, etc.). Las Pruebas Unitarias no reemplazan la buena revisión anticuada del código.

Answer 6

tal vez debería echar un vistazo a las políticas de análisis de código personalizado para checkin TFS

http://weblogs.asp.net/uruit/archive/2009/03/17/writing-custom-rules-for-tfs-2008-code-analysis-check-in-policy.aspx

Answer 7

El marco .NET estaba buscando para hacer cumplir el tiempo de compilación verificación de referencias nulas mediante el uso de una! modificador

public void MyMethod(!string cannotBeNull) 

Pero, por desgracia, no tenemos tiempo de compilación de comprobación. Su mejor apuesta es minimizar las ocurrencias cantidad de llamadas externas para pasar valores nulos y luego cumplir cheques nulos en los métodos de revestimiento públicos:

public class ExternalFacing 
{ 
    public void MyMethod(string arg) 
    { 
    if (String.IsNullOrEmpty(arg)) 
     throw new ArgumentNullException(arg); 

    implementationDependency.DoSomething(arg); 
    } 
} 

internal class InternalClass 
{ 
    public void DoSomething(string arg) 
    { 
     // shouldn't have to enforce null here. 
    } 
} 

A continuación, se aplican las pruebas unitarias adecuadas para la clase externa esperar ArgumentNullExceptions.

Answer 8

¿Hay alguna manera de aplicar la verificación nula en tiempo de compilación?

Nope. El compilador no puede determinar si la variable de referencia en tiempo de ejecución apunta a nulo.

Y excluir declaraciones de producción nula (conjuntos y devoluciones) tampoco es suficiente. Considere:

public class Customer 
{ 
    public List<Order> Orders {get;set;} 
} 
    //now to use it 
Customer c = new Customer; 
Order o = c.Orders.First(); //oops, null ref exception; 

Answer 9

puedo estar equivocado, pero creo que FxCop tiene una regla que sugiere agregar controles de referencia nulo a su código. Podría intentar ejecutar sus ensamblajes a través de la herramienta y ver lo que tiene que decir.

Answer 10

Consulte Gendarme, puede ejecutar post-build junto con sus pruebas (posiblemente antes, si lo desea) y tiene algunas reglas relacionadas con los controles null. También puede escribir trivialmente el suyo.

Answer 11

1) Creo que el Resharper puede sugerirle que verifique algunos lugares críticos en su código. Por ejemplo, sugiere agregar el [código de verificación de referencia nulo] y lo agrega si permite.

Pruébalo. Aumentará tu experiencia si lo necesitas, por supuesto.

2) Use "fallar rápida" patrón (o hacer valer, afirmaciones) en su código en la etapa temprana de desarrollo de aplicaciones

Answer 12

La programación defensiva sólo puede llegar tan lejos ... quizás sea mejor para coger el excepción y lidiar con ella como cualquier otra.