Должны ли мы высматривать ложный код?

Это относится к обсуждению в ответе и комментариям к этому вопросу: что происходит с отвращением к документации в отрасли? , В ответе утверждалось, что «код не может лгать» и, следовательно, должен быть местом для перехода, а не документацией. В нескольких комментариях указывалось, что «код может лгать». С обеих сторон есть истина, по крайней мере отчасти из-за того, как плохо и ненадлежащим образом обрабатывается документация.

Должны ли мы искать ложный код, сравнивая его с какой-либо существующей документацией? Или это обычно лучший источник того, что нужно делать? Если это гибкий код, менее ли он лжив, или этот код вообще не лжет?

По словам непрофессионала:

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

Есть несколько способов, которыми код может лгать, из которых я упомяну только несколько:

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

Чем короче, тем меньше врет. Это самоочевидно.

Чем менее сложен код, тем он прозрачнее. Так что вранье меньше.

Уловки тайного синтаксиса много лжи. Предпочитаю понятные, пошаговые алгоритмы. Они лгут меньше.

Хороший инструмент статического анализа кода может помочь вам найти ложный код.

Также хороший автоматический тестовый аккумулятор заставляет код говорить правду.

Код не может лгать.

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

Код, безусловно, может быть неверным . Это, безусловно, может вводить в заблуждение в названии или организации. Это, безусловно, может быть нечитаемым.

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

Вы задаете несколько вопросов.

Должны ли мы быть в поисках лживого кода?

Конечно!

Должны ли мы сравнивать [код] с какой-либо существующей документацией?

Это никогда не повредит, хотя, как упоминалось в других ответах, чаще всего это приведет к тому, что вы обнаружите проблемы в документации , а не в коде .

Или [код] обычно лучший источник того, что он должен делать?

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

• Сам код;
• Вызывающий код;
• Комментарии в этом коде;
• Документация;
• Юнит-тесты;
• Интеграционные и регрессионные тесты;
• Программист;
• Конечный пользователь;

Какой «лучший» источник (или их комбинация) зависит от вашей ситуации.

Если это гибкий код, менее ли он лжив, или этот код вообще не лжет?

Я не уверен, что вы подразумеваете под «гибким кодом», AFAIK «agile» обычно относится к процессу кодирования. Предположим, вы имеете в виду «код, созданный в процессе гибкого программирования», тогда я думаю, что можно с уверенностью сказать, что он все еще может лгать. Насколько вероятно, что это ложь, по сравнению с кодом, созданным, например, в проектах типа водопада, это субъективный вопрос (лично я не думаю, что есть большая связь).

Сноска
Все вышесказанное предполагает, что код может лгать, и что это простой (хотя и немного надуманный) пример:

public int DivideByTwo(int input) 
{
    return input / 3;
}

Это всего лишь один пример, где я бы сказал «ложь кода», у @ user61852 есть несколько других (недоступный код, сложность кода, не совпадающего со сложностью проблемы, плохое именование), и я думаю, что есть еще много. В Википедии есть несколько приличных сводок лжи , во многих из них можно найти код.

Обратите внимание, что если вы спорите с кем-то, убедитесь, что другой человек не имеет в виду «код не может лгать», что «код делает то, что делает». По сути, другой человек здесь определяет с помощью определения «ложь», которое настолько узко, что может объявить утверждение «код не может лгать» как аксиома / базовая истина. В этом случае, вероятно, лучше всего согласиться с его / ее аксиомой.

if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

Вы можете спорить о том, является ли слово «ложь» технически приемлемым, но этот код довольно ясно подразумевает, что x иногда будет больше 5, а иногда нет. Если вы посмотрите на всю программу и обнаружите, что эта функция всегда вызывается только в одном месте, и что x всегда имеет постоянную 6, то это ложь.

Более того, компилятор, возможно, заметил это и заменил этот блок кода просто

doSomething()

Если doADifferentThing не вызывается нигде в вашей программе, он может быть полностью удален из программы.

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