Вы используете специальные комментарии к исправлениям ошибок в Вашем коде?
Предположим, что мы стоим в firstView, идем в DetailView и хотим передавать данные из firstView в Detailview. Чтобы сделать это с помощью раскадровки, у firstView у нас будет метод:
override func prepareForSegue(segue: UIStoryboardSegue!, sender: AnyObject!) {
if (segue.identifier == "segueTest") {
//Checking identifier is crucial as there might be multiple
// segues attached to same view
var detailVC = segue!.destinationViewController as DetailViewController;
detailVC.toPass = textField.text
}
}
, а затем в класс DetailView мы объявили переменную:
var toPass: String!
, после чего вы можете используйте переменную toPass (конечно, вы можете изменить тип переменной так, как хотите, в этом EX я просто демо для типа строки).
20 ответов
Я не вставляю комментарии как этот, система управления исходным кодом уже поддерживает ту историю, и я уже могу зарегистрировать историю файла.
я действительно вставляю комментарии, которые описывают, почему что-то неочевидное делается все же. Таким образом, если исправление ошибки делает код менее предсказуемым и ясным, то я объясняю почему.
Когда я делаю bugfixes/enhancements в сторонних библиотеках/компоненте, я часто делаю некоторые комментарии. Это помогает, находят и перемещают изменения, если я должен использовать более новую версию библиотеки/компонента.
В моем собственном коде I редко комментарии bugfixes.
Если код будет на живой платформе, далеко от прямого доступа до репозитория управления исходным кодом, то я добавлю комментарии для выделения изменений, внесенных как часть фиксации для ошибки в живой системе.
Иначе, нет сообщение, что Вы входите при регистрации, должно содержать всю информацию, в которой Вы нуждаетесь.
аплодисменты,
Rob
Не копируйте метаданные, которые Ваш VCS собирается сохранить для Вас. Даты и имена должны быть в автоматически добавлены VCS. Номера билетов, менеджер/имена пользователей, который запросил изменение, и т.д. должны быть в комментариях VCS, не коде.
, А не это:
//$DATE$NAME$TICKET//полезный комментарий следующей плохой душе
я сделал бы это:
//полезный комментарий следующей плохой душе
Если Вы добавите комментарии как этот после нескольких лет поддержания кода, то у Вас будет столько комментариев исправления ошибки, Вы не смогли бы прочитать код.
, Но если Вы изменяете что-то, что выглядит правильным (но имеют тонкую ошибку) во что-то, что более сложно, хорошо добавить короткий комментарий, объясняющий, что Вы сделали, так, чтобы следующий программист, который поддержит этот код, не возвращал его, потому что он (или она) думает, что Вы сверхусложнили вещи ни на каком серьезном основании.
Нет. Я использую подверсию и всегда ввожу описание моей мотивации для фиксации изменения. Я обычно не вновь заявляю о решении на английском языке, вместо этого я суммирую внесенные изменения.
я работал в ряде проектов, куда они помещают комментарии в код, когда исправления ошибок были сделаны. Интересно, и вероятно не по совпадению, они были проектами, которые или не использовали вида инструмента управления исходным кодом или получили мандат следовать за этим видом конвенции указом от управления.
Вполне честно, я действительно не вижу значение в выполнении этого для большинства ситуаций. Если я захочу знать то, что изменилось, то я посмотрю на журнал подверсии и различное
Просто мои два цента.
Для определения местоположения определенный комментарий, мы используем DKBUGBUG - что означает фиксацию David Kelley, и рецензент может легко идентификационные данные, Конечно, мы добавим Дату и другое число отслеживания ошибок VSTS и т.д. наряду с этим.
Часто комментарий как этот более сбивает с толку, поскольку у Вас действительно нет контекста относительно того, на что исходный код был похож, или исходное плохое поведение.
В целом, если Ваше исправление ошибки теперь делает код выполненным ПРАВИЛЬНО, просто оставьте его без комментариев. Нет никакой потребности прокомментировать правильный код.
Иногда исправление ошибки заставляет вещи выглядеть нечетными, или исправление ошибки тестирует на что-то, что необычно. Затем могло бы быть уместно иметь комментарий - обычно, комментарий должен вернуться к "числу ошибки" от Вашей базы данных ошибки. Например, у Вас мог бы быть комментарий, в котором говорится "Ошибка 123 - Счет на нечетное поведение, когда пользователь находится в разрешении экрана 640 на 480".
Нет я не делаю, и я очень не хочу иметь граффити как этот мусор код. Числа ошибки могут быть прослежены в сообщении о фиксации к системе управления версиями, и сценариями для продвижения соответствующих сообщений о фиксации в систему отслеживания ошибок. Я не полагаю, что они принадлежат исходного кода, где будущие редактирования просто перепутают вещи.
Тот стиль комментария чрезвычайно ценен в среде мультиразработчика, где существует диапазон навыков и / или знания о бизнесе через разработчиков (например, - везде).
опытному хорошо осведомленному разработчику причина для разнообразия может быть очевидной, но для более новых разработчиков, которых комментарий заставит их думать дважды и сделать больше расследования прежде, чем смешать с нею. Это также помогает им узнать больше, как система работает.
, О, и примечание на основе опыта о "Я просто поместил это в систему управления исходным кодом" комментарии:
, Если это не находится в источнике, этого не произошло.
я не могу считать количество раз, исходная история для проектов была потеряна из-за неопытности с программным обеспечением управления исходным кодом, неподходящие модели ветвящегося процесса и т.д. существует, только один помещает, история изменений не может быть потеряна - и это находится в исходном файле.
я обычно поместил его там сначала, затем вырезал и вставил тот же комментарий, когда я регистрирую его.
Пока я действительно склонен видеть некоторые комментарии к ошибкам в коде на работе, мое персональное предпочтение связывается, код соглашаются на одну ошибку. Когда я говорю, что тот действительно имею в виду одну ошибку. Впоследствии можно всегда смотреть на внесенные изменения и знать, которые прослушивают, к ним относились.
Я делаю это, если исправление ошибки включает что-то, что это не просто, но как правило если bugfix требует долгого объяснения, я беру его в качестве знака, что фиксация не была разработана хорошо. Иногда я должен работать вокруг открытого интерфейса, который не может измениться так, это имеет тенденцию быть источником этих видов комментариев, например:
// <date> [my name] - Bug xxxxx happens when the foo parameter is null, but
// some customers want the behavior. Jump through some hoops to find a default value.
В других случаях сообщение о фиксации управления исходным кодом - то, что я использую для аннотирования изменения.
Комментарии как это - то, почему Подверсия позволяет Вам ввести запись в журнале на каждой фиксации. Это - то, куда необходимо поместить этот материал, не в коде.
В то время как это может походить на хорошую идею в то время, она быстро выходит из-под контроля. Такая информация может быть лучше получена с помощью хорошей комбинации средства отслеживания ошибки и системы управления исходным кодом. Конечно, если бы существует что-то хитрое продолжение, комментарий, описывающий ситуацию, был бы полезен в любом случае, но не дата, имя или число ошибки.
кодовая база, я в настоящее время продолжаю работать на работе, является чем-то как 20 лет, и они, кажется, добавили много комментариев как это несколько лет назад. К счастью, они прекратили делать его спустя несколько лет после того, как они преобразовали все в CVS в конце 90-х. Однако такие комментарии все еще замусорены всюду по коду, и политика теперь, "удаляют их, если Вы работаете непосредственно над тем кодом, но иначе оставляете их". За ними часто действительно трудно следовать особенно, если тот же код добавляется и несколько раз удаляется (да, это происходит). Они также не содержат дату, но содержат число ошибки, которое необходимо было бы пойти посмотреть в архаичной системе для нахождения даты, таким образом, никто не делает.
Я обычно добавляю свое имя, свой адрес электронной почты и дату наряду с кратким описанием того, что я изменил, Поэтому как консультант, я часто исправляю чужой код.
// Glenn F. Henriksen (<email@company.no) - 2008-09-23
// <Short description>
Тот способ, которым владельцы кодов или люди, входящие после меня, могут выяснить то, что произошло и они могут связаться со мной, если они имеют к.
(да, к сожалению, как правило, у них нет управления исходным кодом... для внутреннего материала, я использую TFS, отслеживающий)
Только если решение было особенно умно или трудно понять.
Я склонен не комментировать в фактическом источнике, потому что может быть трудно быть в курсе. Однако я действительно помещаю соединение комментариев в мой журнал управления исходным кодом и систему отслеживания ошибок. например, Я мог бы выполнить в чем-то вроде этого По необходимости:
[идентификатор ошибки] проблема с xyz диалоговым окном. Перемещенный код калибровки к abc и теперь инициализирует позже.
Затем в моей системе отслеживания ошибок я сделаю что-то как:
Фиксированный в changelist 1234.
Перемещенный код калибровки к abc и теперь инициализируют позже.
, поскольку затем хороший исторический маркер оставляют. Также это помогает, если Вы хотите знать, почему конкретная строка кода является определенным путем, можно просто посмотреть на историю файла. После того как Вы нашли строку кода, можно читать, моя фиксация комментируют и ясно видят, для какой ошибки это было и как я зафиксировал ее.
Со временем они могут накопить и добавить помеху. Лучше ясно дать понять код, добавить любые комментарии для связанных глюков, которые не могут быть очевидными и сохранить деталь ошибки в системе слежения и репозитории.
Я не работаю над проектами Multi-Person, но иногда я добавляю комментарии о определенной ошибке к тесту подразделения.
Помните, что такая вещь, как ошибки, просто недостаточное тестирование.
Поскольку я использую как можно больше TDD (все остальное - социальное самоубийство, потому что любой другой метод заставит вас работать бесконечно), я редко исправляю ошибки.
В большинстве случаев я добавляю в код специальные замечания, подобные этому:
// I KNOW this may look strange to you, but I have to use
// this special implementation here - if you don't understand that,
// maybe you are the wrong person for the job.
Звучит резко, но большинство людей, называющих себя «разработчиками», не заслуживают других замечаний.