secure - msdn c# programming guide

¿Es incorrecto usar llaves para propósitos de alcance variable?

Question

A veces uso llaves para aislar un bloque de código para evitar usar una variable por error más adelante. Por ejemplo, cuando coloco varios SqlCommand s en el mismo método, frecuentemente copio y pego bloques de código, terminando mezclando los nombres y ejecutando dos veces algunos comandos. Agregar llaves ayuda a evitar esta situación, ya que usar un SqlCommand incorrecto en un lugar equivocado resultará en un error. Aquí hay una ilustración:

Collection<string> existingCategories = new Collection<string>();
// Here a beginning of a block
{
SqlCommand getCategories = new SqlCommand("select Title from Movie.Category where SourceId = @sourceId", sqlConnection, sqlTransaction);
getCategories.Parameters.AddWithValue("@sourceId", sourceId);
using (SqlDataReader categoriesReader = getCategories.ExecuteReader(System.Data.CommandBehavior.SingleResult))
{
while (categoriesReader.Read())
{
existingCategories.Add(categoriesReader["Title"].ToString());
}
}
}
if (!existingCategories.Contains(newCategory))
{
SqlCommand addCategory = new SqlCommand("insert into Movie.Category (SourceId, Title) values (@sourceId, @title)", sqlConnection, sqlTransaction);
// Now try to make a mistake and write/copy-paste getCategories instead of addCategory. It will not compile.
addCategory.Parameters.AddWithValue("@sourceId", sourceId);
addCategory.Parameters.AddWithValue("@title", newCategory);
addCategory.ExecuteNonQuery();
}

Ahora, StyleCop muestra una advertencia cada vez que un bloque sigue una línea vacía. Por otro lado, no poner una línea vacía haría que el código sea mucho más difícil de entender.

// Something like:
Collection<string> existingCategories = new Collection<string>();
{
// Code here
}
// can be understood as (is it easy to notice that semicolon is missing?):
Collection<string> existingCategories = new Collection<string>()
{
// Code here
}

Asi que,

1. ¿Hay algún error en el uso de llaves para crear bloques de código solo para propósitos de alcance variable?

2. Si está bien, ¿cómo hacerlo más legible sin violar las reglas de StyleCop?

Answer 1

Creo que esos bloques son una buena idea, los estoy usando a menudo. Es útil cuando necesita separar bloques de código que son demasiado pequeños para ser extraídos en el método, o cuando el método consiste en pocos bloques de código que se parecen entre sí, pero no con la misma lógica. Permite dar a las variables los mismos nombres sin conflictos de nombres, y esto hace que el cuerpo del método sea más legible.

Por cierto, mi opinión es que StyleCop tiene reglas predeterminadas con más reglas cuya conveniencia es discutible.

Answer 2

No creo que haya nada de malo en usar llaves para delimitar el alcance, a veces puede ser bastante útil.

Caso en cuestión: me topé con una biblioteca de perfiles una vez que usé objetos de Profile para cronometrar secciones de código. Estos funcionaron midiendo el tiempo desde su creación hasta su destrucción, y por lo tanto funcionaron mejor al ser creados en la pila y luego destruidos cuando quedaron fuera del alcance, midiendo así el tiempo empleado en ese alcance particular. Si quisieras cronometrar algo que no tenía inherentemente su propio alcance, entonces lo mejor sería agregar llaves para definir ese alcance.

En cuanto a la legibilidad, puedo entender por qué a StyleCop no le gusta, pero cualquiera con experiencia en C / C ++ / Java / C # / ... sabe que un par de llaves define un alcance, y debería ser bastante evidente que eso es lo que estas tratando de hacer

Answer 3

No hay nada malo en sí mismo con el bloqueo de código, pero debe considerar por qué lo está haciendo.

Si está copiando y pegando código, es probable que se encuentre en una situación en la que debería refactorizar el código y generar funciones a las que llame repetidamente en lugar de ejecutar bloques de código similares pero diferentes repetidamente.

Answer 4

Tendría que decir que si tuviera que trabajar en este código después de usted, sería un poco molesto por su uso del alcance. No es, afaik, práctica común.

Yo consideraría un olor que estarías haciendo esto. Creo que la mejor práctica sería dividir cada ámbito en su propio método con nombres y documentación totalmente descriptivos.

Answer 5

Utilice la instrucción using lugar de bloques de llaves desnudos.

Esto evitará las advertencias y también hará que su código sea más eficiente en términos de recursos.

Desde una perspectiva más amplia, debe considerar dividir este método en métodos más pequeños. Usando un SqlCommand seguido de otro, generalmente se hace mejor llamando a un método seguido de otro. Cada método usaría su propio SqlCommand local.