Я понимаю, что Ваш вопрос принадлежит C++, но когда дело доходит до C ответ может быть найден в K& R, страницы 72-73:
, Кроме того, если объявление функции не включает аргументы, как в
double atof();
, который также взят, чтобы означать, что ничто не должно быть принято об аргументах atof; вся проверка параметра выключена. Это особое значение списка пустого аргумента предназначается, чтобы разрешить более старым программам C компилировать с новыми компиляторами. Но это - плохая идея использовать его с новыми программами. Если функция берет аргументы, объявите их; если это не берет аргументов, используйте пусто.
Требуются ли хотя бы минимальные усилия, чтобы прочитать этот дополнительный (бесполезный, как вы добавили) код?
Если да (а я думаю, что это так), то его не должно быть в код. Подобный код загрязнен лишними фрагментами, которые бесполезны, они есть «на всякий случай».
«Поздний рефакторинг» этих вещей может быть болезненным, через 6-12 месяцев, кто вспомнит, действительно ли это использовалось?
Хороший контроль версий означает, что ненужный код или код, который больше не требуется, следует удалить. Его всегда можно будет получить из системы управления версиями позже.
Я стараюсь следовать принципу ЯГНИ , поэтому меня это тоже беспокоит.
На самом деле это не нравится.
Потому что я тогда потратьте драгоценное время, пытаясь понять, почему он там. Предполагая, что если он там, то он существует по какой-то причине, и если я не вижу причины, то есть шанс, что я упускаю что-то важное, что мне следует понять, прежде чем я начну возиться с кодом. Меня раздражает, когда я понимаю, что только что потратил час, пытаясь понять, почему или что делает какой-то фрагмент кода, который просто оставил там какой-то разработчик, слишком ленивый, чтобы вернуться и удалить его.
Бесполезный однострочный код можно и нужно удалить.
Бесполезный код, на написание которого потребовалось время, можно и нужно удалить ... но ответственные люди, как правило, испытывают тошноту по этому поводу. Возможно, лучшее решение - создать проект ProbablyUselessButWhoKnows, в котором каждый сможет проверить бессмысленный код, который может быть использован снова через два или три года. По крайней мере, таким образом людям не нужно нервничать, удаляя его.
(Да, теоретически вы можете вывести его из системы управления версиями, но старый удаленный код в системе управления версиями трудно обнаружить.)
В коммерческом проекте - я бы сказал нет, особенно если кто-то может разобрать его для чтения, а затем будет момент WTF.
В домашнем проекте - конечно, почему бы и нет, я часто сохраняю некоторые фрагменты для дальнейшего использования.
Мое практическое правило,
Если оно не используется, избавьтесь от него.
Все лишние комментарии и атрибуты - это просто шум и помогают сделать ваш код нечитаемым. Если их оставить там, они поощряют больше избыточного кода в вашей кодовой базе. Так что удали его.
Ну, я не могу комментировать этот конкретный фрагмент кода, не зная вашего опыта, но я лично строго следую правилу не иметь ничего в коде, если мне это действительно не нужно. Или, по крайней мере, знаю, что когда-нибудь это может быть полезно для того, что я уже имею в виду.
Казалось бы, совершенство достигается не тогда, когда больше ничего нельзя добавить, а когда больше ничего нельзя удалить. - Антуан де Сент-Экзюпери
Это неверный код.
Плохой код - обычная практика.
При этом, как говорится, иногда не стоит прилагать усилия для изменения того, что не "сломано".
Думаю, смысл бесполезного в том, что он не может и не будет использоваться. Я также считаю, что открытая дверь очень открыта.
Если есть активный план использования этой дополнительной функции, оставьте ее.
Если вы знаете, что она никогда не будет использоваться, или если этот план перестал быть актуальным 6 месяцев назад, то откажитесь от него. Я бы сначала прокомментировал это, а потом полностью удалил.
Я занимаюсь пересмотром множества переменных, которые были общедоступными, но на самом деле нуждались только в защите или приватности просто потому, что они не имеют смысла с точки зрения API - это и ничто их не использует.