curly braces - tributarios - ¿Utiliza llaves para un alcance adicional?

terminos tributarios en ingles

Question

Me refiero a algo más que usarlo cuando sea necesario para funciones, clases, if, while, switch, try-catch.

No sabía que se podía hacer así hasta que vi esta pregunta ASÍ .

En el enlace de arriba, Eli mencionó que "Lo usan para doblar su código en secciones lógicas que no caen en una función, clase, bucle, etc. que normalmente se doblarían".

¿Qué otros usos hay además de los mencionados?

¿Es una buena idea usar llaves para limitar el alcance de sus variables y expandir el alcance solo si es necesario (trabajando según la "necesidad de acceso")? ¿O es realmente tonto?

¿Qué le parece usar los ámbitos solo para poder usar los mismos nombres de variable en diferentes ámbitos, pero en el mismo ámbito más amplio? ¿O es una mejor práctica reutilizar la misma variable (si desea usar el mismo nombre de variable) y guardar en la desasignación y asignación (creo que algunos compiladores pueden optimizar esto?)? ¿O es mejor usar diferentes nombres de variables por completo?

Answer 1

Como otros han dicho, esto es bastante común en C ++ debido a la modulación / patrón todopoderoso RAII (adquisición de recursos es la inicialización).

Para los programadores de Java (y tal vez C #, no sé), este será un concepto extraño porque los objetos basados ​​en el montón y GC matan a RAII. En mi humilde opinión, ser capaz de poner objetos en la pila es la mayor ventaja de C ++ sobre Java y hace que el código C ++ bien escrito sea mucho más limpio que el código Java bien escrito.

Answer 2

El uso más común "no estándar" de scoping que uso regularmente es utilizar un mutex delimitado.

void MyClass::Somefun()
{
//do some stuff
{
// example imlementation that has a mutex passed into a lock object:
scopedMutex lockObject(m_mutex);
// protected code here
} // mutex is unlocked here
// more code here
}

Esto tiene muchos beneficios, pero lo más importante es que el bloqueo siempre se limpiará, incluso si se lanza una excepción en el código protegido.

Answer 3

El uso más común, como han dicho otros, es garantizar que los destructores se ejecuten cuando usted lo desee. También es útil para hacer que el código específico de la plataforma sea un poco más claro:

#if defined( UNIX )
if( some unix-specific condition )
#endif
{
// This code should always run on Windows but
// only if the above condition holds on unix
}

El código creado para Windows no muestra if, solo los refuerzos. Esto es mucho más claro que:

#if defined( UNIX )
if( some unix-specific condition ) {
#endif
// This code should always run on Windows but
// only if the above condition holds on unix
#if defined( UNIX )
}
#endif

Answer 4

Estoy de acuerdo con agartzke. Si cree que necesita segmentar los bloques de código lógico más grandes para la legibilidad, debería considerar la refactorización para limpiar los miembros ocupados y desordenados.

Answer 5

La empresa en la que estoy trabajando tiene una política de análisis estático para mantener las declaraciones de variables locales cerca del comienzo de una función. Muchas veces, el uso es muchas líneas después de la primera línea de una función, por lo que no puedo ver la declaración y la primera referencia al mismo tiempo en la pantalla. Lo que hago para "eludir" la política es mantener la declaración cerca de la referencia, pero proporcionar un alcance adicional mediante el uso de llaves. Sin embargo, aumenta la indentación, y algunos pueden argumentar que hace que el código sea más feo.

Answer 6

Lo hago si estoy usando un recurso que quiero liberar en un momento específico, por ejemplo:

void myfunction()
{
{
// Open serial port
SerialPort port("COM1", 9600);
port.doTransfer(data);
} // Serial port gets closed here.
for(int i = 0; i < data.size(); i++)
doProcessData(data[i]);
etc...
}

Answer 7

Programación en Java A menudo he querido limitar el alcance dentro de un método, pero nunca se me ocurrió usar una etiqueta. Como en mayúsculas mis etiquetas cuando las utilizo como objetivo de un descanso, usar un bloque de mayúsculas y minúsculas como el que me sugirió es justo lo que quería en estas ocasiones.

A menudo, los bloques de código son demasiado cortos para dividirse en un método pequeño, y a menudo el código en un método de framework (como startup () o shutdown ()) y en realidad es mejor mantener el código en un solo método.

Personalmente, odio los brackets simples que flotan / cuelgan (aunque eso es porque somos una tienda de sangrado de estilo de pancarta estricta), y odio el marcador de comentarios:

// yuk!
some code
{
scoped code
}
more code
// also yuk!
some code
/* do xyz */ {
scoped code
}
some more code
// this I like
some code
DoXyz: {
scoped code
}
some more code

Consideramos usar "if (true) {" porque la especificación de Java especifica que estos se optimizarán en la compilación (al igual que todo el contenido de un if (falso) - es una función de depuración), pero odiaba eso en los pocos lugares Lo intenté.

Así que creo que tu idea es buena, para nada tonta. Siempre pensé que era el único que quería hacer esto.

Answer 8

Puede ser una bendición codificar generadores. Supongamos que tiene un compilador de SQL incrustado (ESQL); es posible que desee convertir una instrucción SQL en un bloque de código que necesita variables locales. Al usar un bloque, puede reutilizar nombres de variables fijas una y otra vez, en lugar de tener que crear todas las variables con nombres separados. Por supuesto, eso no es demasiado difícil, pero es más difícil de lo necesario.

Answer 9

Sí, uso esta técnica debido a RAII. También uso esta técnica en la C sencilla, ya que acerca las variables entre sí. Por supuesto, debería pensar en dividir las funciones aún más.

Una cosa que hago es probablemente controversial desde un punto de vista estilístico: poner la llave de apertura en la línea de la declaración o poner un comentario en ella. Quiero disminuir la cantidad de espacio vertical desperdiciado. Esto se basa en la recomendación de la Guía de estilo de Google C ++. .

/// c++ code
/// references to boost::test
BOOST_TEST_CASE( curly_brace )
{
// init
MyClass instance_to_test( "initial", TestCase::STUFF ); {
instance_to_test.permutate(42u);
instance_to_test.rotate_left_face();
instance_to_test.top_gun();
}
{ // test check
const uint8_t kEXP_FAP_BOOST = 240u;
BOOST_CHECK_EQUAL( instance_to_test.get_fap_boost(), kEXP_FAP_BOOST);
}
}

Answer 10

Solo lo uso cuando necesito liberar algo por medio de RAII e incluso solo cuando debería ser lanzado tan pronto como sea posible (soltando un candado por ejemplo).

Answer 11

Tiene su lugar, pero no creo que hacerlo de modo que $ foo pueda ser una variable aquí y una variable diferente allí , dentro de la misma función u otro alcance (lógico, en lugar de léxico) sea una buena idea. A pesar de que el compilador puede entenderlo perfectamente, parece muy probable que dificulte la vida a los humanos que intentan leer el código.

Answer 12

Yo no usaría llaves para ese propósito por un par de razones.

1. Si su función en particular es lo suficientemente grande como para realizar varios trucos de alcance, quizás divida la función en subfunciones más pequeñas.

2. La introducción de llaves para el alcance para reutilizar nombres de variables solo generará confusión y problemas en el código.

Solo mis 2 centavos, pero he visto muchos de estos tipos de cosas en otros materiales de mejores prácticas.

Answer 13

C ++ :

A veces necesita introducir un nivel de refuerzos adicionales para reutilizar nombres de variables cuando tenga sentido hacerlo:

switch (x) {
case 0:
int i = 0;
foo(i);
break;
case 1:
int i = 1;
bar(i);
break;
}

El código de arriba no compila. Tienes que hacerlo:

switch (x) {
case 0:
{
int i = 0;
foo(i);
}
break;
case 1:
{
int i = 1;
bar(i);
}
break;
}