Сколько дублированного кода Вы терпите? [закрытый]

In general, no. Во всяком случае, не для читабельности. Всегда есть способ рефакторить дублированный код в намеренно раскрывающийся общий метод, который читается как книга, IMO.

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

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

BH

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

Вы не сказали, какой язык, но в большинстве IDE это простой рефактор - > метод извлечения. Насколько это проще, и один метод с некоторыми аргументами гораздо более ремонтопригоден, чем 2 блока дублирующего кода.

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

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

Некоторые люди предполагают, что 3 или несколько копий являются порогом для рефакторинга. Я считаю, что если у вас есть двое, вы должны сделать это; найти другой клон (клоны) [или даже знать, что они могут существовать] в большой системе трудно, независимо от того, есть ли у вас два или три или более.

Теперь этот ответ предоставляется в контексте отсутствия каких-либо инструментов для поиска клонов. Если можно надёжно найти клоны, то изначальная причина рефактора (избегания ошибок обслуживания) менее настойчива (полезность иметь именованную абстракцию всё же реальна). Что вы действительно хотите, так это способ найти и отследить клоны; абстрагирование их - один из способов обеспечить, чтобы вы могли их «найти» (сделав поиск тривиальным).

Средство, которое может надежно находить клоны, может по крайней мере предотвратить ошибки обслуживания клонов при отказе обновления. Одним из таких инструментов (я автор) является CloneDR . CloneDR находит клоны, используя целевую структуру языка в качестве руководства, и, таким образом, находит клоны независимо от макета пробела, изменений в комментариях, переименованных переменных и т. д. (Он реализован для ряда языков, включая C, C++, Java, C #, COBOL и PHP). CloneDR найдет клоны в больших системах без каких-либо указаний. Отображаются обнаруженные клоны, а также антиунификатор , который по существу является абстракцией, которую вы могли бы написать вместо него. Его версии (для COBOL) теперь интегрируются с Eclipse и показывают, когда вы редактируете внутри клона в буфере, а также где другие клоны, чтобы вы могли проверять/пересматривать другие, пока вы там. (Одно, что вы можете сделать, это рефакторировать их:).

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

Лично я предпочитаю сохранять код понятным, прежде всего.

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

Учитывая это, я согласен, что DRY - это хорошая цель, которой нужно следовать, когда это практично.

Рефакторинг: Улучшение структуры существующего кода

Правило трех

Когда вы впервые что-то делаете, вы просто сделай это. Второй раз
что-то похожее, вы лукавите при дублировании, но вы делаете дубликат
в любом случае. Третий раз, когда вы делаете нечто подобное, вы рефактируете.

Три удара и рефактор.

Кодеры на работе

Сейбель: Поэтому для каждого из этих XII вызовов вы пишете внедрение.
Вы когда-нибудь находили, что накапливали много биты очень похожего кода?

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

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

При этом здесь есть проблемы.

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

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

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

Заявление, что это повредит читаемости, говорит только о том, что вы плохо выбираете имена: -)

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

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

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

Часто дублирование кода LOGIC происходит, когда два объекта с разными базовыми классами имеют сходство в том, как они работают. Например, 2 GUI-компонента, которые оба отображают значения, но не реализуют общий интерфейс для доступа к этим значениям. Рефакторинг такой системы либо требует, чтобы методы брали больше общих объектов, чем нужно, с последующей проверкой типов и приведением, либо иерархия классов должна быть переосмыслена и реструктурирована.

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

вы не сказали, на каком языке, но в большинстве IDE это простой рефакторинг -> метод извлечения. Насколько это проще, и один метод с некоторыми аргументами намного проще в обслуживании, чем 2 блока повторяющегося кода.

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

В большинстве языков извлечение блока в метод с подходящим названием редко может повредить вашей читабельности.

Это ваш кодекс с вашими стандартами, но мой основной ответ на ваше «сколько?» is none ...

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

Тем не менее, здесь есть проблемы.

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

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

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

Лучшая строка кода - это не написанная строка кода.