quien - ¿Por qué usar#if 0 para el bloqueo de comentarios?

como saber si te bloquearon en messenger 2017

Question

Invierta el código de ingeniería y estoy un poco horrorizado por el estilo, pero quería asegurarme de que no hay una buena razón para hacer estas cosas ...

¿Soy yo o es un estilo de codificación horrible?

if ( pwbuf ) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);

¿Y por qué envolver código no destinado para compilación en un

#if 0
....
#endif

En lugar de comentarios?

EDIT: Entonces, como se explica a continuación, esto se debe a la posibilidad de flummox / * * / que no me di cuenta.

Pero aún no entiendo, ¿por qué no usar las herramientas de su entorno de programación o las macros del editor de texto favorito para bloquear el comentario usando "//"?

¿No sería esto mucho más sencillo y fácil de saber para omitir visualmente?

¿Estoy sin experiencia en C y me olvido de por qué estas cosas pueden ser una buena idea, o no hay excusa, y estoy justificado en sentirme irritado por lo feo que es este código?

Answer 1

Además del problema con los comentarios de estilo C que no se anidan, deshabilitar bloques de código con #if 0 tiene la ventaja de poder contraerse si está utilizando un editor que admite el plegado de código. También es muy fácil de hacer en cualquier editor, mientras que deshabilitar grandes bloques de código con comentarios de estilo C ++ puede ser difícil de manejar sin el soporte del editor / macros.

Además, muchos bloques #if 0 tienen un bloque else . Esto proporciona una manera fácil de intercambiar entre dos implementaciones / algoritmos, y es posiblemente menos propenso a errores que comentar en masa una sección y desinstruir en masa otra. Sin embargo, sería mejor usar algo más legible como #if DEBUG en ese evento.

Answer 2

En lo que respecta a los comentarios de bloque que utilizan // , una razón que se me ocurre es que, si comprueba ese código en su sistema de control de origen, el registro de culpa le mostrará como el último editor de esas líneas de código. Si bien es probable que desee que los comentarios se le atribuyan, al mismo tiempo, el código en sí también se le atribuye. Claro, puede retroceder y ver las revisiones anteriores si necesita consultar el registro de culpa del autor "real" del código, pero le ahorraría tiempo si uno conservara esa información en la revisión actual.

Answer 3

Eso es bastante idiomático C justo ahí. No veo qué tiene de malo. No es un código hermoso, pero es fácil de leer y está claro qué ocurre y por qué, incluso sin contexto.

Los nombres de las variables podrían ser mejores, y probablemente sería más seguro usar snprintf o quizás strncpy .

Si crees que podría ser mejor, ¿cómo lo preferirías?

Podría hacer un ligero cambio:

char username[32];
strncpy(username, 30, (pwbuf ? pwbuf->pw_name : user_id));
username[31] = ''/0'';

Answer 4

Los comentarios son comentarios. Ellos describen el código.

El código que se excluye de la compilación es código, no comentarios. A menudo incluirá comentarios, que describen el código que no se está compilando, por el momento /

Son dos conceptos distintos, y forzar la misma sintaxis me parece un error.

Answer 5

Muy ocasionalmente utilizo el estilo más conciso cuando admite la simetría del código y las líneas no se alargan. Tomemos el siguiente ejemplo artificial:

if (strcmp(s, "foo") == 0)
{
bitmap = 0x00000001UL;
bit = 0;
}
else if (strcmp(s, "bar") == 0)
{
bitmap = 0x00000002UL;
bit = 1;
}
else if (strcmp(s, "baz") == 0)
{
bitmap = 0x00000003UL;
bit = 2;
}
else if (strcmp(s, "qux") == 0)
{
bitmap = 0x00000008UL;
bit = 3;
}
else
{
bitmap = 0;
bit = -1;
}

y la versión concisa:

if (strcmp(s, "foo") == 0) { bitmap = 0x00000001UL; bit = 0; }
else if (strcmp(s, "bar") == 0) { bitmap = 0x00000002UL; bit = 1; }
else if (strcmp(s, "baz") == 0) { bitmap = 0x00000003UL; bit = 2; }
else if (strcmp(s, "qux") == 0) { bitmap = 0x00000008UL; bit = 3; }
else { bitmap = 0; bit = -1; }

Los insectos son mucho más propensos a saltar directamente a la cara.

Descargo de responsabilidad: este ejemplo está ideado, como he dicho. Siéntase libre de discutir el uso de strcmp, los números mágicos y si un enfoque basado en tablas sería mejor. ;)

Answer 6

Obviamente, cada uno tiene sus propias opiniones sobre este tipo de cosas. Así que aquí está la mía:

Nunca escribiría un código como el anterior, y me importaría menos a cualquiera que lo hiciera. No puedo contar el número de veces que la gente piensa que está bien escapar sin restricciones de alcance, y luego ser mordido por ella.

Poner la declaración de control en la misma línea que el bloque de código es aún peor; la falta de sangrado hace que sea más difícil ver el control de flujo mientras se lee. Una vez que haya estado codificando durante algunos años, se acostumbra a poder leer e interpretar el código de manera rápida y precisa, siempre que pueda confiar en ciertas indicaciones visuales. Eludir estas señales por "casos especiales" significa que el lector tiene que detenerse y hacer una doble toma, sin ninguna razón.

#if (0) , por otro lado, está bien durante el desarrollo, pero debe eliminarse una vez que el código esté "estable" (o al menos reemplace 0 con un nombre de símbolo de preprocesador significativo).

Answer 7

Woah allí! No exageres ...

Yo lo llamaría más descuidado por más el espacio inconsistente que cualquier otra cosa. He tenido tiempo en el que encontré mejor poner las declaraciones cortas en la misma línea que su FI, aunque esas declaraciones lo están extendiendo.

El estilo en línea es mejor para la brevedad vertical ... podría dividirse fácilmente en 4, más líneas

if (pwbuf)
sprintf(username,"%s",pwbuf->pw_name);
else
sprintf(username,"%d",user_id);

Personalmente odio el siguiente estilo ya que es tan largo, lo que dificulta hojear un archivo.

if (pwbuf)
{
sprintf(username,"%s",pwbuf->pw_name);
}
else
{
sprintf(username,"%d",user_id);
}

Answer 8

puntos arriba mencionados. Pero los monitores son de pantalla panorámica y todos, en estos días, no me importa

if (pwbuf) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);

¡Siempre parece tener demasiado espacio horizontal, y no hay suficiente espacio vertical en mi pantalla!

Además, si el bloque de código ya tiene directivas de preprocesador, no use #if 0 ; Si el código ya tiene comentarios de bloque, no use /* */ . Si ya tiene ambos, puede recurrir a un editor que tenga ctrl + / , para comentar muchas líneas. Si no, estás lleno, borra el código directamente!

Answer 9

#if 0 ... #endif es bastante común en el código C más antiguo. La razón es que comentar con comentarios de estilo C /* .... */ no funciona porque los comentarios no se anidan.

Aunque es común, diría que no tiene cabida en el código moderno. La gente lo hizo en tiempos pasados ​​porque sus editores de texto no podían bloquear comentarios de grandes secciones automáticamente. Más importante aún, no tenían el control de código fuente adecuado como lo hacemos ahora. No hay excusa para dejar comentado o # ifdef''d en el código de producción.

Answer 10

#if 0 se usa con bastante frecuencia cuando el bloque eliminado contiene comentarios de bloque

No diré que es una buena práctica, pero la veo bastante a menudo.

La declaración de control de flujo en una sola línea es bastante fácil de entender, aunque personalmente la evito (y la mayoría de las pautas de codificación en las que he trabajado lo prohíben)

Por cierto, probablemente editaría el título para que sea algo útil "¿Por qué usar #if 0 en lugar de comentarios en bloque?"

Si tienes los siguientes

#if 0
silly();
if(foo)
bar();
/* baz is a flumuxiation */
baz = fib+3;
#endif

Si reemplaza ingenuamente el #if 0 / #endif con /* */ , eso provocará que el comentario finalice justo después de la fluxuxiación, lo que provocará un error de sintaxis cuando presione */ en lugar del #endif anterior.

EDITAR: Una nota final, a menudo la sintaxis de #if 0 se usa solo durante el desarrollo, especialmente si tiene que admitir múltiples versiones o dependencias o plataformas de hardware. No es raro que el código sea modificado a

#ifdef _COMPILED_WITHOUT_FEATURE_BAZ_
much_code();
#endif

Con un encabezado centralizado que define (o no) cientos de esas constantes #define. No es la cosa más bonita del mundo, pero cada vez que he trabajado en un proyecto de tamaño decente, hemos usado una combinación de interruptores de tiempo de ejecución, constantes de tiempo de compilación (esto), decisiones de compilación en tiempo de compilación (solo use diferentes). cpp (dependiendo de la versión), y la solución de plantilla ocasional. Todo depende de los detalles.

Sin embargo, mientras usted es el desarrollador que está haciendo que la cosa funcione en primer lugar ... #if 0 es bastante común si no está seguro de si el código anterior aún tiene valor.

Answer 11

if ( pwbuf ) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);

Idiomático y conciso. Si se toca más de 2 o 3 veces, lo pondré en un paréntesis y lo alinearé en la siguiente línea. No es muy fácil de mantener si agrega información de registro u otras condiciones.

#if 0
....
#endif

Bueno para activar bloques de código de depuración o no. Además, evitaría errores de compilación relacionados con tratar de bloquear comentarios de este tipo:

/* line comment */
...
/* line comment again */

Dado que los comentarios del bloque C no se anidan.