Регистрация «закомментированного» кода [закрыто]

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

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

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

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

В любом случае, что ты думаешь? Считаете ли вы, что "закомментированный" код полезно иметь в репозитории?

Мне очень интересно услышать от других по этой теме.

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

Изменить: нет веской причины, по которой мы не используем частные или индивидуальные ветки. Я не согласен с этой концепцией. Просто мы еще не настроили это таким образом. Возможно, это золотая середина. Пока мы используем стеллажи TFS.

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

Вот принципы, которым я научился и которым стараюсь следовать:

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

Это означает:

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

Итак, НЕТ! Если код не готов для перехода к следующему этапу (в зависимости от того, что вам подходит: IntTest / QA / UAT / PreProd / Prod), его не следует передавать в магистраль или ветвь с несколькими разработчиками. Период.

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

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

«Никогда» редко бывает хорошим словом для использования в рекомендациях.

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

По большей части комментирование мертвого кода не требуется в хорошо управляемой системе с контролем изменений. Но не весь закомментированный код «мертв».

Закомментированный код никогда не следует возвращать для сохранения истории. Это точка управления версиями.

Здесь много говорят об идеалах. Может быть, в отличие от всех, мне приходится работать над несколькими проектами с множественными перерывами, а «реальный мир» иногда прерывает мой рабочий день.

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

При необходимости создам собственную рабочую ветку для фиксации частичных изменений.

Один случай, когда я оставляю закомментированный код:

// This approach doesn't work
// Blah, blah, blah

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

Я бы, конечно, настоятельно не рекомендовал проверять закомментированный код. Однако я бы не стал категорически запрещать это. Иногда (если редко) уместно проверять закомментированный код в системе контроля версий. Сказать «никогда так не делай» - слишком ограничительно.

Я думаю, что все мы согласны с этим:

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

Некоторые из них говорят, что есть другие категории, такие как временно удаленный код или инкрементное, но неполное улучшение, которое включает небольшой объем закомментированного кода в качестве документации о том, что будет дальше, или очень короткое (в идеале 1 строка) фрагмент прокомментированного код показывает то, что никогда не должно следует добавлять повторно. Закомментированный код ВСЕГДА должен сопровождаться комментарием, в котором говорится, почему он закомментирован (а не просто удален), и указывается ожидаемое время жизни закомментированного кода. Например, «Следующий код приносит больше вреда, чем пользы, поэтому закомментирован, но его необходимо заменить перед выпуском XXX».

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

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

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

Рекс М сказал: 1) Проверяйте только полную функциональность, 2) [Если] задача слишком велика - разбейте ее на более мелкие выполняемые задачи.

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

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

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

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

Я думаю, что никогда не бывает слишком сильным условием.

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

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

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

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

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

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

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

Следующий разработчик, который увидит этот закомментированный код, не поймет, что это работа. Он свободен изменить это? Это мертвый код? Он не знает.

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

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

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

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

Я предполагаю, что вы из лагеря "хорошего кода", а он из лагеря "рабочего кода".

[РЕДАКТИРОВАТЬ]

Судя по комментариям, да, я правильно понял.

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

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

По моему опыту, переключатели разработчика - это закомментированный код.

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

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

Еще одна причина для отмеченного закомментированного кода:

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

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

Эта практика может показаться противоречащей заявленной вами цели реализации непрерывной интеграции.

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

Мое мнение: если разработчики работают над собственными ветками или в своей собственной песочнице, они должны иметь возможность проверять все, что захотят. Когда они проверяют код в общей ветке (функциональная ветка или ветка команды, или, конечно, MAIN / trunk), код должен быть как можно более чистым (без закомментированного кода, без FIXME и т. Д.).

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

Чтобы уравновесить эту слабость, убедитесь, что все знают, что закомментированный код имеет срок годности. Любой человек может удалить закомментированный код, если он существует в течение полной недели и никогда не был активен. (Замените «неделю» на то, что кажется вам правильным.) Таким образом, вы оставляете за собой право убирать беспорядок, когда вы его видите, без слишком прямого вмешательства в личный стиль людей.

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

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

Я считаю, что это усложняет код и затрудняет чтение.

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

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

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Скорее, чем на индивидуальной основе, например:

// My commented code start here
// My commented code line 1
// My commented code line 2

(вы поняли идею)

Причина, по которой я буду проявлять крайнюю осторожность, заключается в том, что в зависимости от технологии вы должны быть очень осторожны с используемым инструментом сравнения / слияния. С определенной системой управления исходным кодом и определенным языком инструмент сравнения / слияния можно легко спутать. Например, стандартное сравнение / слияние ClearCase, как известно, плохо подходит для слияния файлов .xml.

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

Но если код проходит сборку, он может стать активным, когда его там не должно быть, и с точки зрения CM это может быть кошмарным сценарием. QA обычно проверяет, что должно быть там, они не проверяют код, которого там не должно быть, поэтому ваш код может оказаться в производстве, прежде чем вы это узнаете, и к тому времени, когда он будет реализован, код есть, когда он не следует, затраты на обслуживание многократно увеличились (поскольку «ошибка» будет обнаружена в производстве или заказчиком, в худшем месте или в любое время).

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

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

Даже тогда, когда мы оглядываемся более чем на 3 версии, практически никогда не бывает.

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

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

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

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

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

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

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

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

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

Я думаю, что закомментированный код считается «пустой тратой».

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

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

Закомментированный код просто вызовет вопросы у других разработчиков, что приведет к потере времени и энергии.

Вам нужно задать вопрос " почему » код закомментирован. Некоторые предложения:

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

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

Если вы комментируете код из-за того, что «что-то не работает», то ИСПОЛЬЗУЙТЕ ЭТО ! Распространенный сценарий - «сломанные тесты» или «задачи» . Если они у вас есть, вы сэкономите много времени, исправив их или просто избавившись от них. Если их можно «сломать» на какое-то время, то, скорее всего, они сломаются навсегда.

Все эти потенциальные сценарии (и те, которые я здесь не упоминал) - пустая трата времени и усилий. Закомментированный код может показаться небольшой проблемой, но может быть индикатором более серьезной проблемы в вашей команде.

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

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

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

В комментарии вы упоминаете, что не используете частные ветки. Мой вопрос к вам: почему бы и нет? Хорошо, я ничего не знаю о TFS, так что, возможно, на то есть веские причины. Однако после года использования git я должен сказать, что хороший DVCS полностью снимает это напряжение. Есть случаи, когда я считаю, что комментирование кода полезно, когда я создаю замену, но я теряю сон из-за этого, если я навязываю его другим. Возможность локального ветвления означает, что я могу сохранять значимые коммиты для своего отдельного процесса, не беспокоясь о временных беспорядках (или даже уведомляя) последующих разработчиков.

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

неполный / экспериментальный код должен быть в ветке, которую нужно разработать до конца. голова / ствол должны быть основной линией, которая всегда компилируется и отправляется. как только экспериментальная ветка будет завершена / принята, она должна быть объединена с head / mainline. Существует даже стандарт IEEE (IEEE 1042), описывающий это, если вам нужна вспомогательная документация.

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

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

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

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

1. Если у вас есть частный филиал и
2. У вас нет времени, чтобы код компилировался без ошибок и
3. Вы собираетесь в длительный отпуск и
4. Вы не доверяете своей VCS, как если бы вы использовали Visual Source Safe OR .
   [РЕДАКТИРОВАТЬ]
5. У вас есть незаметная ошибка, которая может быть повторно введена, если неверный код не будет оставлен в качестве напоминания. (хороший момент из других ответов).

Для №4 почти нет оправдания, потому что существует множество свободно доступных и надежных систем VCS, и Git является лучшим примером .

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

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

[РЕДАКТИРОВАТЬ] Я бы добавил, что необходимо различать два основных сценария:

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

Просто скажите «НЕТ» рубцам!

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

Тем не менее, я вычеркиваю старый закомментированный код из предыдущей регистрации.

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

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

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

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

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

Также было бы хорошо знать, кто прокомментировал этот код, чтобы их можно было спросить, если необходимо какое-то обоснование.

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

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

С DVCS (например, git, bazaar или mercurial) это очень просто, так как не требует изменений в центральном репозитории. В противном случае, возможно, вы могли бы поговорить о предоставлении разработчикам их собственных веток на сервере, если они работают над определенными функциями, на что у них уйдет достаточно много времени (например, дни).

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

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

Именно система VCS должна помочь разработчику в этом рабочем процессе (git - отличная система VCS, которая отлично с ней работает).