Должен ли я удалить код, на который нет ссылок?

118

Я работаю над кодовой базой среднего размера (100 тыс. Строк), все это относительно новый код (менее года) и имеет хороший охват модульных тестов.

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

Должен ли я удалить этот код, если я уверен, что он больше не нужен?

Причины удалить это:

  • Меньше кода, меньше ошибок
  • Меньше кода легче переварить другим
  • Все еще находится под контролем источника

Причины сохранить это:

  • Может использоваться как ссылка
  • Это может быть полезно когда-нибудь
  • Возможно, он был написан для «округления» функциональности класса
Саймон Хаттон
источник
22
«Меньше кода, меньше ошибок» - если они действительно никогда не используются, они вряд ли вызовут ошибки
Конрад Моравский
19
@Morawski Но если его оставить, он когда-нибудь будет использован. И поскольку он не был сохранен, в нем будут ошибки, которые затем появятся.
DJClayworth
9
Я обычно комментирую это и тесты, которые зависят от него, и затем оставляю комментарий 'TODO' с датой. Как только он не использовался в течение года, я бросил его. Другие рекомендуют просто удалить его сейчас, но я нахожу это трудным сделать, особенно если кажется, что код когда-то был полезным.
Работа
31
@Job Если я сталкиваюсь с закомментированным кодом, он удаляется. Никаких оправданий. Закомментированный код просто кричит: «Я не доверяю нашей системе контроля версий». мне.
Кристоф Провост
26
@Kristof Провост, как вы узнали бы, что полезный код был когда-то в исходном файле A там, если его больше нет? Конечно, вы всегда можете проверить историю файла, в котором вы находитесь, но как часто вы думаете про себя: «Хм ... Мне нужно изменить / реализовать функцию здесь. Или мне нужно проверить, как это работало 5 лет назад БЫСТРО. Интересно, кто-нибудь уже реализовал это и затем удалил это ... позвольте мне проверить историю ". Я не защищаю эту грязную чушь, но есть обстоятельства, когда вы не используете код в работе, но иногда вам это может понадобиться для отладки и т. Д.
Работа

Ответы:

219

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

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

DeadMG
источник
30
Я согласен с его удалением, но у меня были случаи, когда я что-то ломал, потому что кто-то использовал «неиспользуемый» код через рефлексию. Так что надо быть осторожным в любом случае.
Сокол
14
@Falcon, это хорошая причина, чтобы удалить его как можно скорее, прежде чем люди начнут использовать его или обнаружат необходимость сделать его публичным.
StuperUser
6
@Falcon: это утверждение ОП, что код не используется.
DeadMG
4
@StuperUser: я полностью согласен. Но нужно быть осторожным и готовиться к неожиданностям.
Сокол
18
Если вы удалите его, и ваши юнит-тесты и регрессионные тесты пройдут, но продукт выйдет из строя, это станет веским основанием для настройки некоторых типов инструментов покрытия кода.
Эндрю Т Финнелл
43

Все причины убрать его стоят.

Причины сохранить это:

  • Может использоваться как ссылка
  • Это может быть полезно когда-нибудь
  • Возможно, он был написан для «округления» функциональности класса

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

StuperUser
источник
1
Да, ссылочный код не должен оставаться в живом коде.
xdazz
Мне кажется, вы также получаете эти преимущества, просто комментируя большие куски.
Стив Беннетт
@SteveBennett Действительно, но вы неправильно поняли смысл этого ответа. Я перечисляю преимущества от комментариев, суть в том, что вы получите все эти И БОЛЬШЕ преимуществ от контроля версий (что вы увидите в других ответах).
StuperUser
Я конечно не против VCS. :) (Тем не менее, я заметил, что после удаления материала из текущей версии он становится гораздо менее заметным, чем другие подходы, например, сохранение его в текстовом файле без ссылок, в вики, в комментариях и т. Д.)
Стив Беннетт
@Steve Bennet - Может быть «менее видимым», чем комментарии в текущей версии файла, но тривиально проверить историю VCS отдельного файла, и я бы сказал, значительно проще, чем txt-file / wiki / etc. .. подходит.
Зак Лысобей,
23

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

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

Николас Смит
источник
40
Чтобы немного улучшить вашу аналогию, это все равно, что держать почти полностью разряженные батареи приклеенными к пульту дистанционного управления, а не в коробке рядом с новыми батареями в хранилище с надписью «использованные, но не разряженные батареи».
Скотт Уитлок
Плюс 1 за лучшее улучшение!
Николас Смит
15

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

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

Мой подход: (1) если вы используете его один раз, оставьте только то, что вам действительно нужно; (2) если вы используете его дважды, скопируйте и адаптируйте его во второй раз; (3) если вы используете его более двух раз, сделайте из него четко определенный, стабильный модуль и используйте этот модуль по мере необходимости.

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

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

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

Вообще, я бы поклонился ЯГНИ по этому поводу. Если «вам это не понадобится», то это просто занимает место в вашей кодовой базе, модульных тестах и ​​сборках. Возможно, вам это понадобится, но вам также может понадобиться полностью переписать его, потому что в промежутке между этим моментом и когда вам понадобится что-то подобное, многое может измениться.

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

Keiths
источник
8

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

Для битов, которые трудно было правильно понять с самого начала и которые, скорее всего, воскреснут, я бы оставил их чуть более «живыми», чем просто в управлении исходным кодом. Люди не будут знать / помнить, что они существуют - говоря: «Вы можете просто найти это в системе контроля версий», предполагается, что вы знаете / помните, что это там! В подобных случаях рассмотрите возможность устаревания (с использованием «assert (false)» showtopper) или комментирования.

Эд Стауб
источник
5
+1 за "высказывание" вы можете просто найти его в системе контроля версий "предполагает, что вы знаете / помните, что он там есть!" - иногда я нахожу маленькие напоминания о коде, который был вырезан, чтобы быть полезным, по той или иной причине.
Стивен
3

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

Для интересных трупов кода я использую archiveветку в своих системах контроля версий.

phresnel
источник
3

«Может использоваться как ссылка». Я бы не стал соглашаться с тем, что есть веская причина оставить неиспользованный код. Часто только небольшая часть неиспользуемого кода демонстрирует что-то интересное. Есть несколько способов документировать и хранить полезный, но неиспользуемый код.

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

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

Мой любимый способ хранения удаленного кода, если он окажется полезным в будущем, - это создание вторичного справочного документа, содержащего все различные фрагменты стоящего удаленного кода. Каждый блок кода помечен кратким упоминанием о том, откуда он появился или о чем-либо еще уместном запомнить, например, когда он был удален или номер редакции, в которой он был последним в коде. Все удаленное, но «потенциально полезное», находится в одном месте, легко доступно для поиска, но не требует постоянных усилий для поддержки и тестирования на постоянной основе (это тестирование откладывается до любой точки, в которой код повторно вводится).

Джессика Браун
источник
2

Хорошая причина сохранить неиспользуемые методы: они могут быть использованы в других ветках / тегах!

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

davorp
источник
Это не имеет смысла для меня: если он не используется в этой ветви, удалите его из этой ветви. Если другой филиал использует его, он останется там.
Слеське
1

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

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

Но, пожалуйста, прежде чем удалять его, убедитесь, что он нигде не используется. Visual Studio имеет функцию под названием « Найти все ссылки», которая ищет все решение и находит любую ссылку на текущую переменную, метод, свойство, класс, интерфейс и т. Д. Прежде чем удалять часть моего кода, я всегда проверяю, нет ли ссылки.

Саид Нямати
источник
1

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

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

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

Карл Билефельдт
источник
1

Ничто не занимает меньше времени, чем отсутствие кода.

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

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

Если нет ничего, никто не потеряет время с этим.

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

неизвестный пользователь
источник
1

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

Длинные комментарии старого кода отвлекают и затрудняют навигацию.

С уважением

Лука Ботти
источник
1

Следуйте этому простому алгоритму:

  1. Это резервное копирование в SCM? Если да, перейдите к 3.
  2. Настройте SCM.
  3. Выбрось вещи .

Все ваши очки в пользу удаления действительны.

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

Это называется «мертвый код» по причине. Пусть это умрет и покойся с миром.

haylem
источник
0

Это останется в контроле источника; он не должен оставаться в активной кодовой базе.

Единственное исключение - если код завершает проектирование, и пока вы не используете код, вы в конечном итоге планируете сделать код общедоступным, и другие могут захотеть эту базовую функциональность. Затем просто разработайте тесты, чтобы убедиться, что эти части кода работают так, чтобы имитировать то, как вы предлагаете другим, использовать эти части кода. Однако, если вы даже подумываете об удалении кода и не можете найти вескую причину его сохранения, он должен пойти. Неиспользуемый код делает больше работы для всех (труднее читать код; код может быть поврежден; больше работы для обслуживания и т. Д.)

доктор джимбоб
источник
0

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

Без сомнения, неиспользованный код - это неприятный запах.

ОБНОВЛЕНИЕ: я только заметил, что Эд Стауб дал очень похожий ответ.

Али
источник