Любая веская причина для дублирования кода?

Лень, это единственная причина, о которой я могу думать.

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

До сих пор оставляет неприятный привкус во рту.

Помимо неопытности, могут появиться повторяющиеся вхождения кода:

Нет времени на надлежащий рефакторинг

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

Обобщение кода невозможно/некрасиво из-за языковых ограничений

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

Вы не уверены, что вообще будет обобщение

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

Добавлю еще, если что-то еще вспомню.

Добавлено позже...

Развертывание цикла

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

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

Do_A_Policy()
{
  printf("%d",1);
  printf("%d",2);
}

Do_B_Policy()
{
  printf("%d",1);
  printf("%d",2);
}

Теперь вы можете предотвратить «дублирование кода» с помощью такой функции:

first_policy()
{
printf("%d",1);
printf("%d",2);
}

Do_A_Policy()
{
first_policy()
}

Do_B_Policy()
{
first_policy()
}

Однако существует риск того, что какой-то другой программист захочет изменить Do_A_Policy() и сделает это, изменив first_policy(), что вызовет побочный эффект изменения Do_B_Policy(), побочный эффект, о котором программист может не знать. так что такого рода «дублирование кода» может служить защитным механизмом от подобных изменений в программе в будущем.

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

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

Пример (псевдокод):

procedure setPropertyStart(adress, mode, value)
begin
  d:=getObject(adress)
  case mode do
  begin
    single: 
       d.setStart(SingleMode, value);
    delta:
       //do some calculations
       d.setStart(DeltaSingle, calculatedValue);
   ...
end;

procedure setPropertyStop(adress, mode, value)
begin
  d:=getObject(adress)
  case mode do
  begin
    single: 
       d.setStop(SingleMode, value);
    delta:
       //do some calculations
       d.setStop(DeltaSingle, calculatedValue);
   ...
end;

Вы можете каким-то образом реорганизовать вызов метода (setXXX), но в зависимости от языка это может быть сложно (особенно с наследованием). Это дублирование кода, так как большая часть тела одинакова для каждого свойства, но бывает сложно реорганизовать общие части.

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

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

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

Тем не менее, я не могу придумать никакого разумного способа оправдать дублирование кода. Посмотрите, почему это плохо.

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

Для такого дублирования кода (множество строк дублируется много раз) я бы сказал:

• либо лень (вы просто вставляете какой-то код здесь и там, не беспокоясь о том, какое влияние он может оказать на другие части приложения — при написании новой функции и использовании ее в двух местах, я полагаю, некоторое влияние)
• или незнание какой-либо передовой практики (повторное использование кода, разделение разных задач в разных функциях/методах)

Вероятно, первое решение из того, что я обычно видел :-(

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