Подтвердить что ты не робот

Недостижимый код: ошибка или предупреждение?

Это вопрос дизайна языка:

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

Лично я сильно чувствую, что это должна быть ошибка: если программист пишет фрагмент кода, он всегда должен быть с намерением фактически запустить его в каком-то сценарии. Но компилятор С#, например, не согласен с этим и просто сообщает о предупреждении.

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

Вот несколько примеров фрагментов кода, где некоторые утверждения явно недостижимы:

return;
foo();

-

throw new Exception();
foo();

-

if (...) {
  return;
} else {
  throw new Exception();
}
foo();
4b9b3361

Ответ 1

Вообще говоря, это должна быть ошибка.

Единственное исключение приходит мне на ум:

if (false) {
  doStuffThatITemporarilyDisabled();
}

Некоторые разработчики могут жаловаться, если ваш компилятор отказывается от компиляции для такого кода.

Ответ 2

Ошибка означает, что компилятор физически неспособен справиться с вашим кодом.

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

Мне кажется, что это очень ясно для меня - это должно быть предупреждение.

Кроме того, что касается случая, когда я решил сократить метод для целей отладки:

public bool ShowMenu()
{
    return true;
    /* The standard implementation goes here */
}

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

Ответ 3

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

Ответ 4

Я думаю, что предупреждение подходит. Затем пользователь может решить использовать ваш ДРУГОЙ переключатель, который говорит "относиться ко всем предупреждениям как к ошибкам", когда он делает сборку Release. Уполномочивать разработчика всегда лучше, чем навязывать ему практически случайные варианты.

Ответ 5

Я думаю, это должно быть предупреждение.

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

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

Ответ 6

Если вы указали язык:

  • Полагает, что мертвый код является ошибкой.
  • Не поддерживает предварительную обработку текстового уровня C-стиля
  • Недостатки комментариев в блочном стиле, которые могут вставляться с комментариями в стиле строки

... тогда это действительно сосать. Крайне важно иметь возможность отключать большие блоки кода без необходимости физически вырезать их из файла.

Ответ 7

Я бы предпочел (доказуемо) недостижимый код, чтобы получить предупреждение или уведомление (например, предупреждение, но без отрицательных коннотаций). В основном потому, что это упрощает создание кода.

Ответ 8

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

например:

int i = 2, j = 3;
int result = 0;

// FIXME: Commented out for now because I have to recheck calculation
if (false) {
  result = i*2+j+3+i*j;
}

System.out.println("Result of difficult calculation = "+result);

Если вы поместите список "result = я * 2 + j + 3 + ij;" просто в /комментарии */, вы уверены, что когда вы удаляете или переименовываете определенные переменные (например, i), вы не получаете ошибку.

Ответ 9

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

Ответ 10

Я думаю, что это должно быть предупреждение по той же причине, что и Роальт. Хороший компилятор также должен исключать компиляцию этого кода.

Ответ 11

Я все еще не понимаю, почему Java реализует мертвый код как ошибку. Я использую C и Objective-C, у которых есть препроцессоры, поэтому я могу легко использовать директивы препроцессора для включения (или маскировки) функции/метода, например:

// C code
#define ENABLE_FOO //Comment off this to turn off foo(void);
int foo(void)
{
#ifdef ENABLE_FOO
    // Do actual stuff.
    int returnVaue = 2;
    // ...
    return returnValue;
#else
    return 0; // Turned off
#endif
}
// Compiling using clang, enforcing dead code detection:
// clang main.c -Wall -Werror

или, как в Objective-C, с доступным отражением:

// Class
#define MYCLASS_ENABLE_FOO // Comment off to enable -[MyClass foo]
@interface MyClass : NSObject
#ifdef MYCLASS_ENABLE_FOO
- (int)foo;
#endif
@end
// The like is done in implementation.
// Invoking:
int main(int argc, char **argv)
{
    MyClass *object = [[MyClass alloc] init];
    int value = ([object respondsToSelector:@selector(foo)]) ? // Introspection.
                [object foo] : 0;
    printf("Value: %d", value);
    return 0;
}

Ответ 12

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

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

В случае кода для отладки/тестирования баланс способствует тому, что он является предупреждением. Очень удобно иметь возможность отключать части кода для отладки или тестирования.

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