Я написал следующий код:
if (boutique == null) {
boutique = new Boutique();
boutique.setSite(site);
boutique.setUrlLogo(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getLogo());
boutique.setUrlBoutique(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getUrl());
boutique.setNom(fluxBoutique.getNom());
boutique.setSelected(false);
boutique.setIdWebSC(fluxBoutique.getId());
boutique.setDateModification(new Date());
boutiqueDao.persist(boutique);
} else {
boutique.setSite(site);
boutique.setUrlLogo(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getLogo());
boutique.setUrlBoutique(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getUrl());
boutique.setNom(fluxBoutique.getNom());
//boutique.setSelected(false);
boutique.setIdWebSC(fluxBoutique.getId());
boutique.setDateModification(new Date());
boutiqueDao.merge(boutique);
}
Здесь есть закомментированная строка. Но я думаю, что это делает код более понятным, делая очевидной разницу между if
и else
. Разница еще более заметна с помощью цветовой подсветки.
Может ли комментирование такого кода быть хорошей идеей?
источник
Самая большая проблема с этим кодом состоит в том, что вы дублировали эти 6 строк. Как только вы устраните это дублирование, этот комментарий становится бесполезным.
Если вы создадите
boutiqueDao.mergeOrPersist
метод, вы можете переписать его так:Код, который создает или обновляет определенный объект, является обычным, поэтому вы должны решить его один раз, например, путем создания
mergeOrPersist
метода. Вы, конечно, не должны дублировать весь код назначения для этих двух случаев.Многие ORM каким-то образом имеют встроенную поддержку. Например, они могут создать новую строку, если она
id
равна нулю, и обновить существующую строку, еслиid
она не равна нулю. Точная форма зависит от рассматриваемого ORM, и, поскольку я не знаком с используемой вами технологией, я не могу вам с этим помочь.Если вы не хотите создавать
mergeOrPersist
метод, вы должны устранить дублирование каким-либо другим способом, например, введяisNewBoutique
флаг. Это может быть не красиво, но это все же намного лучше, чем дублирование всей логики назначения.источник
Это абсолютно ужасающая идея. Это не проясняет, что цель. Разработчик закомментировал строку по ошибке? Чтобы что-то проверить? В чем дело?!
Помимо того, что я вижу 6 линий, которые абсолютно равны в обоих случаях. Скорее, вы должны предотвратить это дублирование кода. Тогда будет понятнее, что в одном случае вы дополнительно вызовите setSelected.
источник
Нет, это ужасная идея. Основываясь на этом фрагменте кода, мне приходят в голову следующие мысли:
После просмотра тысяч строк закомментированного кода я делаю единственную разумную вещь, когда вижу это: я немедленно удаляю его.
Нет никакой разумной причины проверять закомментированный код в хранилище.
Кроме того, ваш код использует много дублирования. Я предлагаю вам как можно скорее оптимизировать это для удобства чтения.
источник
Я просто хотел бы добавить к ответу CodesInChaos, указав, что вы можете еще больше реорганизовать его в небольшие методы . Разделение общей функциональности по составу позволяет избежать условных выражений:
источник
null
объекты, тем лучше (я считаю, что это решение является хорошим примером).boutiqueDao
качестве входных данныхcreate
иupdate
.Хотя это явно не очень хороший случай для закомментированного кода, есть ситуация, которая, я думаю, оправдывает это:
Это предупреждение тому, кто увидит это позже, что очевидного улучшения нет.
Редактировать: я говорю о чем-то маленьком. Если он большой, ты объясни вместо этого.
источник
// the following part done like it is because of X
? Объясните , почему вы сделали что - то, как вы сделали, не то, почему вы сделали не на него в каком - то конкретном пути. В вашем конкретном примере это полностью исключает необходимость в потенциально большом блоке закомментированного кода. (Я не понизил голос, но могу понять, почему за него проголосовали.)n
мало, и экспоненциальный алгоритм гораздо быстрее. Еслиn
впоследствии что- то изменится, как будущий разработчик, следящий за моим проектом, узнает о другой реализации кода, скрытого в сотнях коммитов в управлении исходным кодом?В этом конкретном примере я считаю закомментированный код очень неоднозначным, в основном по причинам, изложенным в ответе Дибкке . Другие предложили способы, которыми вы могли бы реорганизовать код, чтобы избежать даже соблазна сделать это, хотя, если это невозможно по какой-то причине (например, строки похожи, но не достаточно близко), я был бы признателен за комментарий, подобный следующему:
Тем не менее, я думаю, что есть некоторые ситуации, когда выход (или даже добавление закомментированного) кода не предосудителен. При использовании чего-то вроде MATLAB или NumPY часто можно написать эквивалентный код, который либо 1) выполняет итерацию по массиву, обрабатывая один элемент за раз, либо 2) обрабатывает весь массив одновременно. В некоторых случаях последнее намного быстрее, но также намного сложнее для чтения. Если я заменю некоторый код его векторизованным эквивалентом, я вставлю исходный код в соседний комментарий, например так:
Очевидно, что нужно позаботиться о том, чтобы две версии действительно делали одно и то же, и чтобы комментарий либо синхронизировался с реальным кодом, либо удалялся в случае изменения кода. Очевидно, обычные предостережения о преждевременной оптимизации также применимы ...
источник
Единственный раз, когда я видел закомментированный код, который был полезен, был в конфигурационных файлах, где код для каждого параметра предоставляется, но комментировался, облегчая включение настроек, просто удаляя маркеры комментариев:
В этом случае закомментированный код помогает документировать все доступные параметры и способы их использования. Также общепринятым является использование значений по умолчанию, поэтому код также документирует настройки по умолчанию.
источник
Вообще говоря, код является только самодокументированным для человека, который написал код. Если документация требуется, напишите документацию. Недопустимо ожидать, что разработчик, плохо знакомый с базой исходного кода, будет сидеть читать тысячи строк кода, пытаясь выяснить на высоком уровне, что происходит.
В этом случае цель закомментированной строки кода состоит в том, чтобы показать разницу между двумя экземплярами дублированного кода. Вместо того, чтобы пытаться скрытно документировать разницу с помощью комментария, перепишите код, чтобы он имел смысл. Затем, если вы все еще чувствуете необходимость прокомментировать код, напишите соответствующий комментарий.
источник
Нет, прокомментированный код становится устаревшим и вскоре становится хуже, чем бесполезным, он часто вреден, так как он цементирует некоторый аспект реализации наряду со всеми текущими предположениями.
Комментарии должны включать сведения об интерфейсе и предполагаемую функцию; «предназначенная функция»: может включать, сначала мы пробуем это, затем мы пробуем это, затем мы терпим неудачу таким образом.
Программисты, которых я видел, стараются оставлять вещи в комментариях, просто любят то, что они написали, не хотят потерять это, даже если это ничего не добавляет к готовому продукту.
источник
Это может быть в очень редких случаях, но не так, как вы это сделали. Другие ответы довольно хорошо прояснили причины этого.
Одним из редких случаев является спецификация RPM- шаблона, которую мы используем в моем магазине в качестве отправной точки для всех новых пакетов, в основном, чтобы не пропустить ничего важного. Большинство, но не все наши пакеты имеют архив с исходными текстами, который имеет стандартное имя и указывается с помощью тега:
Для пакетов без исходных текстов мы закомментируем тег и добавим еще один комментарий над ним, чтобы сохранить стандартный формат и указать, что кто-то остановился и подумал о проблеме как о части процесса разработки:
Вы не добавляете код, который, как вы знаете, не будет использоваться, потому что, как уже говорили другие, его можно принять за то, что там находится. Может. Тем не менее, полезно добавить комментарий, объясняющий, почему отсутствует код, который можно было бы ожидать:
источник
Закомментированный код не используется приложением, поэтому он должен сопровождаться дополнительными комментариями, указывающими, почему он не используется. Но в этом контексте бывают ситуации, когда закомментированный код может быть полезен.
Мне приходит в голову случай, когда вы решаете проблему, используя общий и привлекательный подход, но затем оказывается, что требования вашей реальной проблемы немного отличаются от этой проблемы. Особенно, если ваши требования требуют значительно большего количества кода, соблазн для сопровождающих «оптимизировать» код с использованием старого подхода, вероятно, будет сильным, но это только вернет ошибку. Сохранение «неправильной» реализации в комментариях поможет развеять это, потому что вы можете использовать ее, чтобы проиллюстрировать, почему именно такой подход неверен в этой ситуации.
Я не могу представить, чтобы это происходило очень часто. Обычно, этого должно быть достаточно, чтобы объяснить вещи, не включая пример «неправильной» реализации. Но я могу представить себе случай, когда этого недостаточно, поэтому вопрос заключается в том, может ли оно быть полезным, да, может. Просто не большую часть времени.
источник
Это не выглядит хорошим приятелем.
Код с комментариями ... просто не код. Код для реализации логики. Сделать код более читабельным сам по себе - это искусство. Как @CodesInChaos уже предположил, что повторяющиеся строки кода не очень хорошая реализация логики .
Вы действительно думаете, что один настоящий программист предпочтет удобочитаемость, а не логическую реализацию? (кстати, у нас есть комментарии и «дополнения» для добавления в наше логическое представление).
Насколько мне известно, нужно написать код для компилятора, и это хорошо - если «он» понимает этот код. Для удобства чтения Комментарии хороши для разработчиков (в долгосрочной перспективе), для людей, повторно использующих этот код (например, для тестировщиков).
В противном случае вы можете попробовать что-то более гибкое здесь, что-то вроде
boutique.setSite (сайт) можно заменить на
setsiteof.boutique (сайт). Существуют различные аспекты и перспективы ООП, благодаря которым вы можете повысить читабельность.
Хотя этот код на первый взгляд кажется очень привлекательным, и можно подумать, что он нашел способ удобочитаемости для человека, в то время как компилятор также отлично справляется со своей задачей, и мы все начнем следовать этой практике, но это приведет к нечеткому файлу, который станет менее читабельным. со временем и более сложным, поскольку он расширит свой путь вниз.
источник