Регистрация “прокомментированных” [закрытый] код

Это вернет счет результатов за каждую минуту (где у вас есть записи) за последний час

SELECT DATEPART(n, time_stamp) AS minute, COUNT(*) as results
FROM table_name 
WHERE time_stamp > DATEADD(hh, -1, GETDATE())
GROUP BY DATEPART(n, time_stamp)

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

WITH numbers ( num ) AS (
    SELECT 1 UNION ALL
    SELECT 1 + num FROM numbers WHERE num < 60 )
SELECT num AS minute,
    (SELECT COUNT(*) AS results
    FROM table_name
    WHERE DATEPART(n, time_stamp) = num
    AND time_stamp > DATEADD(hh, -1, GETDATE())
FROM numbers

Чтобы увидеть результаты, замените DATEADD (hh, -1, GETDATE ()) на DATEADD ( mi, -15, GETDATE ()), и вы получите результаты за последние 15 минут и 0 за другие минуты.

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

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

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

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

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

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

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

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

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

Just echoing the chorus. Discourage this at all costs. It makes the code harder to read and leaves folks wondering whats good/bad about that code that isnt even part the application at the present time. You can always find changes by comparing revisions. If there was some major surgery and code was commented out en-masse the dev should have noted it in the revision notes on checkin/merge.

incomplete/experimental code should be in a branch to be developed to completion. the head/trunk should be the mainline that always compiles and is whats shipping. once the experimental branch is complete it/accepted it should be merged into the head/mainline. There is even an IEEE standard (IEEE 1042) describing this if you need support documentation.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это показывает принципиальное различие в двух школах мысли: те, кто проверяет только в рабочем коде, что они удовлетворены и «Чувство достойно сохранения», и те, кто проверяет свою работу, чтобы контроль версий был там, чтобы защитить их от потери данных.

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

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

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

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

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

Кстати: Хорошие редакторы помогут сохранить старые версии. Например, в Emacs я установил сохраненные старые версии и сохраненные старые версии равными 10, что позволяет хранить последние 10 сохранений моих файлов. Вы могли бы рассмотреть это как способ помочь вашему аргументу против толпы revision-control-as-backup. Тем не менее, вы никогда не выиграете спор.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Закомментированный код никогда не должен регистрироваться с целью ведения истории. В этом смысл контроля над источниками.

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

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

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

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

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

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

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

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

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

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

/* 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

(вы понимаете)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, у вас может быть

#if JOEBLO
// This code is experimental

// ... code goes here ...

#endif // JOEBLO

Относительно ответа Рекса М , Я думаю, что иногда бывают случаи, когда инкрементная регистрация, которую вы хотите выполнить (для записи прогресса), не работает достаточно хорошо, чтобы включить ее для всех. В таких случаях #define полезен.

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

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

Думаю, такая функция будет полезна для всех: