Зачем использовать #if 0 для комментирования блока?

Ответ 1

#if 0 используется довольно часто, когда удаленный блок содержит комментарии блока

Я не буду говорить, что это хорошая практика, но я вижу это довольно часто.

Однолинейное управление потоком-контролем + достаточно легко понять, хотя я лично его избегаю (и большинство правил кодирования, которые я работал под его запретом)

Кстати, я бы, вероятно, отредактировал название, чтобы быть несколько полезным. "Зачем использовать #if 0 вместо комментариев блока"

Если у вас есть следующие

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

Если вы наивно замените #if 0/#endif на /* */, что приведет к тому, что комментарий завершится сразу после flumuxiation, вызывая синтаксическую ошибку, когда вы нажимаете */ вместо #endif выше..

EDIT: последнее замечание, часто синтаксис #if 0 используется только при разработке, особенно если вам приходится поддерживать несколько версий или зависимостей или аппаратных платформ. Это не редкость для того, чтобы код был изменен на

#ifdef _COMPILED_WITHOUT_FEATURE_BAZ_
    much_code();
#endif

С помощью централизованного заголовка, определяющего (или не) сотни констант #define. Это не самая красивая вещь в мире, но каждый раз, когда я работал над проектом с приличным размером, мы использовали некоторую комбинацию переключателей времени исполнения, констант времени компиляции (это), решений компиляции во время компиляции (просто используйте разные. cpp в зависимости от версии) и случайное решение шаблона. Все зависит от деталей.

В то время как вы разработчик просто получаете то, что работает в первую очередь, хотя... #if 0 довольно распространен, если вы не уверены, что старый код по-прежнему имеет значение.

Ответ 2

Комментарии - это комментарии. Они описывают код.

Код, исключаемый из компиляции, - это код, а не комментарии. Он часто будет включать комментарии, которые описывают код, который не компилируется, на данный момент /

Они представляют собой два разных понятия, и форсирование одного и того же синтаксиса кажется мне ошибкой.

Ответ 3

Помимо проблемы с комментариями C-style, не вложенными, отключение блоков кода с помощью #if 0 имеет то преимущество, что может быть свернуто, если вы используете редактор, который поддерживает сворачивание кода. Это также очень легко сделать в любом редакторе, тогда как отключение больших блоков кода с комментариями в стиле C++ может быть громоздким без поддержки/макросов редактора.

Кроме того, многие блоки #if 0 имеют блок else. Это дает простой способ обмена между двумя реализациями/алгоритмами и, возможно, менее подвержен ошибкам, чем массовое комментирование одного раздела и массовое раскомментирование другого. Однако в этом случае вам лучше использовать что-то более читаемое, например #if DEBUG.

Ответ 4

Это довольно идиоматический C прямо там. Я не понимаю, что с этим не так. Это не красивый кусок кода, но его легко читать и понятно, что происходит и почему, даже без контекста.

Имена переменных могут быть лучше, и, вероятно, было бы безопаснее использовать snprintf или, возможно, strncpy.

Если вы думаете, что это может быть лучше, что бы вы предпочли, чтобы он выглядел?

Я мог бы внести небольшое изменение:

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

Ответ 5

Что касается блочного комментирования с использованием //, то одна из причин, о которой я могу думать, заключается в том, что если вы проверите этот код в вашей системе управления версиями, журнал вины покажет вам, как последний редактор для этих строк код. Хотя вы, вероятно, хотите, чтобы комментирование было приписано вам, в то же время сам код также приписывается вам. Конечно, вы можете вернуться и посмотреть предыдущие версии, если вам нужно проверить журнал вины для "реального" автора кода, но это сэкономит время, если сохранится эта информация в текущей версии.

Ответ 6

Очевидно, у каждого есть свои мнения по этому поводу. Итак, здесь мое:

Я бы никогда не писал код, как указано выше, и думал бы меньше о том, кто это сделал. Я не могу сосчитать количество раз, когда люди думают, что это нормально, чтобы уйти без брекетов, а затем были укушены им.

Приведение оператора управления в ту же строку, что и кодовый блок, еще хуже; отсутствие отступов затрудняет просмотр контроля потока во время чтения. Когда вы кодируете несколько лет, вы привыкаете к тому, чтобы читать и интерпретировать код быстро и точно, пока вы можете полагаться на определенные визуальные сигналы. Обход этих реплик для "особых случаев" означает, что читатель должен остановиться и сделать двойной прием, без уважительной причины.

#if (0), с другой стороны, нормально во время разработки, но должен быть удален после того, как код "стабилен" (или, по крайней мере, заменит 0 некоторым значимым именем символа препроцессора).

Ответ 7

Вот там! Не переусердствуйте...

Я бы назвал это sloppier для более несогласованного интервала, чем что-либо еще. У меня было время, когда мне показалось, что лучше делать короткие инструкции в той же строке, что и их IF, хотя эти утверждения растягивают ее.

Встраиваемый стиль лучше для вертикальной краткости... легко может быть разбит на 4, больше строк

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

Лично я ненавижу следующий стиль, так как он настолько затянут, что затрудняет просмотр файла.

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

Ответ 8

указано выше. Но мониторы являются широкоэкранными и всеми, в наши дни, я вроде как не против.

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

Всегда кажется, что у вас слишком много горизонтального пространства, и на экране не хватает вертикального пространства!

Кроме того, если в коде кода уже есть директивы препроцессора, не используйте #if 0; если код уже имеет комментарии блока, не используйте /* */. Если у него уже есть оба варианта, обратитесь к редактору с ctrl + /, чтобы прокомментировать много строк. Если нет, вы набиты, удалите код прямо!

Ответ 9

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

Идиоматический и лаконичный. Если бы это коснулось более 2 или 3 раз, я бы скопировал и подстроил его. Это не очень удобно, если вы добавляете информацию о регистрации или другие условия.

#if 0
....
#endif

Хорошо включить блоки кода отладки или нет. Кроме того, во избежание ошибок компиляции, связанных с попыткой заблокировать комментарий, выполните следующие действия:

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

Так как комментарии блока C не вложены.

Ответ 10

Очень часто я использую более сжатый стиль, когда он поддерживает симметрию кода, а строки не слишком длинны. Возьмем следующий надуманный пример:

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;
}

и краткую версию:

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; }

Ошибки гораздо чаще будут прыгать прямо в ваше лицо.

Отказ от ответственности: этот пример надуман, как я уже сказал. Не стесняйтесь обсуждать использование strcmp, магических чисел, и если подход на основе таблицы будет лучше.;)

Ответ 11

#if 0 ... #endif довольно распространен в старшем C-коде. Причина в том, что комментарий с комментариями стиля C /* .... */ не работает, потому что комментарии не вложены.

Несмотря на то, что это распространено, я бы сказал, что в современном коде нет места. Люди делали это в старые времена, потому что их текстовые редакторы не могли автоматически блокировать большие комментарии комментариев. Более того, у них не было правильного управления исходным кодом, как сейчас. Нет никакого оправдания оставлять комментарий или # ifdef'd в производственном коде.