c++ - significa - siglas tag definicion

¿Cómo se sangran las declaraciones del preprocesador?

Question

Cuando hay muchas declaraciones de preprocesador y muchas cascadas #ifdef, es difícil obtener una visión general, ya que normalmente no están sangradas. p.ej

#ifdef __WIN32__
#include <pansen_win32>
#else
#include <..>
#ifdef SOMEOTHER
stmts
#endif
maybe stmts
#endif

Cuando considero también sangrar las declaraciones del preprocesador, temo confundirme con el nivel de sangría general. Entonces, ¿cómo resuelves esto de una manera hermosa?

Answer 1

"Dicho todo esto, no hay ninguna regla que indique que no se puede sangrar las comprobaciones del preprocesador si hace que el código sea más legible".

No, pero en un mundo donde el estilo está controlado y el código se ajusta para que coincida, sería bueno habilitar el estilo para sangrar #if sentencias #if como las sentencias if .

Si bien #if posible que técnicamente sea un idioma diferente, es parte de la especificación C / C ++ y como no es una letra por letra de ninguna de las palabras clave actuales, no hay ninguna razón por la que no se pueda utilizar #if s en el estilo.

Answer 2

Como usted, todavía no he pensado en la mejor manera de sangrar, pero encontré en más de un lugar esta sangría alternativa en la que el # se coloca siempre en la primera columna y solo se sangra la palabra clave:

#ifdef __WIN32__
# include <pansen_win32>
#else
# include <..>
#endif

En Visual Studio, cuando escribe # como el primer carácter, siempre lleva su sangría a la izquierda, por lo que parece que MS no favorece nunca la sangría de las declaraciones del preprocesador o usa el formato anterior.

El gran problema es cuando se mezclan las declaraciones sin preprocesador y preprocesador y se aplica sangría. Es difícil hacer un código que se vea bien, sin importar qué opción:

opción (a)

for (...)
{
if (foo)
{
if (bar)
{
#ifdef __WIN32__
c = GetTickCount();
#else
c = clock();
#endif
}
}
}

opción (b)

for (...)
{
if (foo)
{
if (bar)
{
#ifdef __WIN32__
c = GetTickCount();
#else
c = clock();
#endif
}
}
}

opción (c)

for (...)
{
if (foo)
{
if (bar)
{
# ifdef __WIN32__
c = GetTickCount();
# else
c = clock();
# endif
}
}
}

En este punto, se convierte en una cuestión de gusto personal, como tantos otros estilos de sangría.

Answer 3

El hecho de que las directivas de preprocesamiento "normalmente" no tengan sangría no es una buena razón para no sangrarlas:

#ifdef __WIN32__
#include <pansen_win32>
#else
#include <..>
#ifdef SOMEOTHER
stmts
#endif
maybe stmts
#endif

Si con frecuencia tiene múltiples niveles de anidamiento de directivas de preprocesamiento, debe modificarlos para simplificarlos.

Answer 4

Primero, asegúrese de que realmente necesita todas las declaraciones ifdef . ¿Quizás hay una manera de refactorizarlos para mantener el número de anidados si los cheques son limitados? Suponiendo que los necesites:

Sería una buena idea separar la primera parte (la incluye) en un archivo de inclusión separado:

En your_header.h :

#ifdef __WIN32__
#include <pansen_win32>
#else
#include <..>
#endif

Luego, en el archivo de implementación, puedes mantener las cosas más sanas. Las líneas en blanco liberales y los comentarios son el enfoque que normalmente he tomado con respecto a los cheques #ifdef sin sangría.

#ifndef __WIN32__
#ifdef SOMEOTHER
stmts
// SOMEOTHER
#endif
maybe stmts
// __WIN32__
#endif

Dicho todo esto, no hay ninguna regla que indique que no se puede aplicar sangría a las comprobaciones del preprocesador si hace que el código sea más legible.