Suprimir el análisis de código estático Advertencia CA1806 para llamadas de TryParse

Me preguntaba qué pensaba la gente sobre la advertencia de análisis de código estático CA1806 (DoNotIgnoreMethodResults) al usar FxCop.Suprimir el análisis de código estático Advertencia CA1806 para llamadas de TryParse

Tengo varios casos en los que uso Int32.TryParse para extraer la información de configuración interna que se guardó en un archivo. Termino con una gran cantidad de código que se parece a:

Int32.TryParse(someString, NumberStyles.Integer, CultureInfo.InvariantCulture, out intResult);

MSDN dice que el resultado por defecto de intResult es cero si algo falla, que es exactamente lo que quiero.

Desafortunadamente, este código desencadenará CA1806 al realizar análisis de código estático. Parece que una gran cantidad de código redundante/inútil para corregir los errores con algo como lo siguiente:

bool success = Int32.TryParse(someString, NumberStyles.Integer, CultureInfo.InvariantCulture, out intResult); 
if (!success) 
{ 
intResult= 0; 
}

¿Debo suprimir este mensaje o morder la bala y añadir todo este error redundante de cheques? ¿O tal vez alguien tiene una mejor idea para manejar un caso como este?

Gracias!

Fuente

2011-01-05 Tim

Este título no es apropiado, usa algo como: "¿Cuándo está bien tragar las advertencias de estilo?" y reformule la pregunta de manera apropiada. Tal como está, esto está en peligro de ser cerrado. "No es una pregunta" – Firoso

Suprimir lejos!

FxCop/Code Anaylysis solo es realmente una guía. Puede ayudar a mejorar partes de su código, especialmente si se distribuye a otros desarrolladores para su uso, pero al final del día, es solo una guía y puede codificar de la forma que desee.

Fuente

2011-01-05 22:54:11

Es solo una guía, y aunque no estoy de acuerdo con seguir las guías de estilo de la carta, en este caso se agrega una claridad de propósito que mantiene a los asesinos fuera de su puerta. – Firoso

Muerde la viñeta, o al menos agrega comentarios. ¿Cómo sabe Johnny el programador homicida que Int32.TryParse proporcionará un resultado de 0 sin mirar la documentación externa? Del mismo modo, ¿cómo sabe que 0 es lo que DESEAS que sea el valor predeterminado? La implementación posterior es específica en su propósito, así que tengo que estar de acuerdo con FxCop aquí.

Recuerda, Johnny sabe dónde vives.

Dicho esto, A MENUDO suprimo el estilo de policía, (en gran parte porque utilizo el CTP asincrónico que todavía no funciona bien). Las pautas de estilo son solo eso, pautas. Usa tu cabeza, pero siempre hay un error por el lado de la claridad es que la preformance no es un problema.

Tenga en cuenta que un comportamiento como este podría cambiarse en el futuro, ¿siempre quiere que 0 sea el valor predeterminado? ¿Podría esto cambiar? Incluso si se refactoriza en un método de ayuda ParseOrDefault, probablemente debería considerar cambios razonables de los valores predeterminados durante la vida útil del producto.

Fuente

2011-01-05 22:54:37 Firoso

+1 para la referencia JTHM ;) – TrueWill

Si Johnny conoce su C# lo sabrá porque el método llamado es * obligatorio * para asignar un valor a cualquier parámetro declarado usando el modificador 'out'. Esto no es nada especial sobre 'Int32.TryParse'. –

Excepto que la asignación Int32.TryParse a 0 sigue siendo específica (aunque común) para ese método, además, ¿quién dijo que Johnny es compentente? ;-) Es solo homicida. – Firoso

Por qué no refactorizar sus TryParse s en una sola función con el comportamiento que está buscando ?:

static int ParseOrDefault(string someStr) 
{ 
    int result = 0; 
    if(int.TryParse(someStr, out result)) 
    { 
     return result; 
    } 
    return 0; 
}

De esta manera se evita el molesto y advertencia zanja el código redundante. Una función separada hace que sus expectativas sean explícitas y no deja lugar a confusión.

Fuente

2011-01-05 23:04:04

Esto me hace desear tener métodos de extensión estáticos ... – Firoso

¿Por qué tiene múltiples devoluciones? esa es una práctica muy mala que lleva a pruebas torpes y refactorización. – Firoso

@Firoso: esto también funcionaría como un método de extensión de cadena (con un nombre diferente). Los retornos múltiples no me molestan, especialmente en una función corta. A Bruce Eckel tampoco parece importarles: http://onthethought.blogspot.com/2004/12/multiple-return-statements.html. Pero, por supuesto, evítalos si no te gustan. –

Suprimir el análisis de código estático Advertencia CA1806 para llamadas de TryParse

Respuesta

Cuestiones relacionadas