Лучшие практики для комментариев управления версиями
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
10 ответов
Каждая функция имеет ticket/issue/bugreport/task/whatever-you-call-it, и на номер билета всегда ссылаются в комментарии регистрации. Это дает контекст.
Я рекомендовал бы не использовать/перегружать Вашу систему управления версиями для этого. Я предложил бы программное обеспечение отслеживания ошибки в качестве лучшего соответствия.
Для одного, не кажется уместным сделать, чтобы разработчики добавили весь контекст и дублированную информацию в сообщении о фиксации, которое уже находится в документе требований или системе проблемы/дефекта.
можно использовать инструмент для сбора соответствующих мер/номеров выпуска, которые находятся в комментариях фиксации и затем идут, собирают тех, которые из другого репозитория, но я думаю, что это - ошибка в основном заставить пересмотр оснастить внешнюю вещь направления.
необходимо определить то, что Источник/версия repository/SVN - это для управления исходными файлами или это также для записи информации о версии. Я думаю, что это не должно быть перегружено.
Мы пытаемся сохранить это простым: пишут одно предложение, описывающее изменение, которое Вы фиксируете. , Если разработчику нужны два или больше предложения для описания фиксации, то, возможно, фиксация является двумя несвязанными обрабатываемыми деталями. То, когда фиксации как это заканчиваются в управлении версиями, затем трудно вернуться, фиксирует в изоляции.
Другая информация, которую нам нравится включать в наш комментарий фиксации, дефект / функция номер , который фиксация фиксирует / реализации. Не вся работа, которую мы делаем, связана с дефектом в нашей системе отслеживания задач, таким образом, это не обязательно.
Одна последняя информация, что мы вставляем наши комментарии фиксации, имя одного рецензента кода . Это - человек, который сделал проверку работоспособности на изменениях, прежде чем фиксация произойдет.
Я рекомендую функциональные комментарии. Комментарии должны дать сводку того, что было изменено. Если что-то было изменено, и почему. Каждая фиксация должна быть объяснимой, если Вы не можете объяснить это ясно, Вы, вероятно, не должны регистрировать его.
самая важная вещь помнить при использовании журналов управления исходным кодом, они там для определения то, когда и что было изменено. Чем более функциональный, и подробный, тем лучше. фиксации должны быть сделаны в крохотных частях, которые могут быть объяснены с крохотными комментариями.
Мое персональное предпочтение является этим стилем:
ОБНОВИЛ систему регистрации ошибок.
- Добавленный ошибка прежней версии при парсинге стандартной программы с помощью regex для получения кодов ошибок прежней версии.
- Измененный текст в сообщениях об ошибках базы данных, для исправления орфографических ошибок.
- Удаленный прокомментировал разделы кода, потому что они больше не использовались.
Ключ - то, что является Вами собирающийся делать с комментариями. Если Вы создаете информацию о версии, то можно сделать, как Вы предположили. Однако я рекомендовал бы вместо этого, что Вы отслеживаете информацию о версии где-то в другом месте, такой как в инструменте управления проектами или отслеживания ошибок.
Что касается связанных с разработчиками комментариев, мы обычно просили, чтобы люди объяснили, что они делают, одно объяснение предложения. Это не должно быть слишком формально, главным образом потому что, если это - люди, выразит несогласие с ним. Плюс, если Вы знаете, кто сделал это, и у Вас есть быстрый комментарий, можно обычно прослеживать проблему и находить человека.
Также при использовании инструмента как FogBugz можно связать регистрацию SVN с номером дела. Что означает, что можно искать случай для получения полного обсуждения, комментариев, снимков экрана, и т.д. Который является намного большей информацией, чем Вы могли когда-либо входить в комментарий регистрации.
Согласитесь с Воспоминанием, но необходимо также записать немного о том, почему Вы реализовали изменение / исправление ошибки путем, Вы сделали. Если Вы живо в регистрации часто, необходимо также включать В DO's, чтобы позволить одному из коллег выполнить задачу.
Внесение моих небольших изменений помогает: Я могу предоставить подробные описания своих изменений этот путь.
комментарии регистрации должны быть информацией, которую хочет разработчик: это включает рефакторинги, мотивацию позади кода, и т.д.
На наших проектах мы всегда рекомендуем предоставлять некоторую деталь тому, о чем фиксация и помогать в не необходимости копировать информацию как проблема, мы используем Trac и интегрировали наш репозиторий. Преимущество состоит в том, что можно затем сослаться на билет проблемы в комментарии и только заявить разрешение или шаги выполненной работы. Trac затем автоматически связывает ссылочный номер с числом первичного размещения и применяет Ваше сообщение о фиксации как комментарий к проблеме. Затем, когда Вы хотите видеть то, что было сделано, можно просто считать проблемы в Trac и иметь полный контекст.
Относительно информации о версии мы нашли, что, беря список проблем в рамках выпуска и с помощью информации о фиксации, поскольку основание для комментариев хорошо работало. Обычно у Вас не будет информации о версии, которая имеет необработанные сообщения о фиксации в них, поскольку Ваши клиенты действительно не заботятся о каждом небольшом изменении или даже уровне детализации, который может быть включен в комментарий. Таким образом, необходимо было бы обычно делать изрядное количество редактирования для выделения основных изменений и исправлений ошибок, реализованных в том выпуске.
Я сказал бы, чтобы попытаться следовать за стилем журнала изменений. Первая строка должна быть кратким изложением и включать проблему/номер билета (если таковые имеются). Это должно возможно сопровождаться пустой строкой в зависимости от того, как Ваш VCS обрабатывает многострочные сообщения о фиксации, затем более полное многострочное описание. Я сказал бы, что неблагоразумно наложить любое строгое форматирование, так как это будет препятствовать частым фиксациям, но пока важные фиксации (те закрывающие проблемы или существенные изменения) сделаны таким образом, необходимо быть в порядке.
при использовании чего-то как Trac или сводка новостей + svn интеграция это может выбрать номера выпуска из сообщений о фиксации. Я всегда помещал бы их в первую строку, так как они так полезны.
Редактирование: Учитывая, что это - безусловно моя большая часть ответа downvoted, я думаю, что стоит подчеркнуть то, что скрыто в последнем абзаце: я - единоличный владелец. Я имею 100%-е владение этих проектов и не работаю с другими разработчиками. В магазине больше чем с одним разработчиком все, что я говорю в этом ответе, может быть абсолютно непригодным.
я подписываюсь на DRY здесь как во всех вещах.
я почти никогда не добавляю комментарий к своим фиксациям. Комментарий почти всегда повторяет меня. Ответ на вопрос, "что изменилось в этой фиксации"? находится почти всегда в различном
, Когда я смотрю на файл, и я спрашиваю "что, черт возьми, произошло здесь?", первая вещь, которую я делаю, посмотреть на разность с предыдущей версией. 90% времени, ответ сразу очевиден, или потому что самоочевидный код или потому что было что-то не самоочевидное, который я прокомментировал в коде. Если это не, я коррелирую даты версии файла с системой отслеживания ошибок, и ответ там.
Это всегда работает. Это иногда требует, чтобы немного расследования поняло что-то, потому что я не прокомментировал свой код соответственно. Но я никогда не не мог найти ответ справедливо быстро.
единственное время я добавляю, что комментарий к журналу фиксации - когда я знаю, что разность не собирается помогать мне. Например, когда я сортирую участников класса: единственная вещь, которую разность собирается сказать мне в этом случае, состоит в том, что что-то очень большое произошло. Когда я делаю это, я фиксирую файл, как только я зафиксировал его. Нет никакого соответствующего места для комментария изменения того объема в файле, таким образом, я добавляю комментарий о том, что единственное изменение в этой версии переупорядочивает участников.
("Почему Вы не прокомментировали бы изменение как этот в истории пересмотра наверху файла?" Вы могли бы спросить. Я не сохраняю историю пересмотра наверху своих файлов. Это было страшным, break-the-habit-of-a-lifetime изменяются для создания, и я никогда не сожалел о нем на мгновение. Историей пересмотра является Подверсия.)
, Если у меня не было 100%-го владения проекта, это могло бы отличаться. Могло бы быть слишком трудно коррелировать фиксации с исправлениями ошибок. Могло бы быть слишком трудно обучить других разработчиков кодировать к стилю, который позволяет полагаться на управление версиями эффективно. Я должен был бы видеть.