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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С уважением

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

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

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

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

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

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

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

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

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

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