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

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

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

Недавно я начал следовать советам дяди Боба Чистый код , и я пытаюсь преобразовать комментарии в функции, которые заключают (извлекают) закомментированный код в функцию, которая по крайней мере столь же значимый, как и заменяемый им комментарий.

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

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

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

Когда я нахожу бесполезные комментарии, созданные GhostDoc, я иногда просто удаляю их:

Какова цель этих комментариев?

/// <summary>
/// Saves the form properties.
/// </summary>
/// <param name="form">The form.</param>
/// <param name="propertyNames">The property names.</param>
void SaveFormProperties(Form form, string[] propertyNames);

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

Тем не менее, если вы торопитесь, нет смысла тратить слишком много времени на обновление комментариев. Добавление одного к эффекту «Это устарело» решает проблему сохранения навигации, не оставляя сомнений в ее точности.

Если ваша документация создается на основе комментариев (я все равно настоятельно рекомендую это), то да, я тщательно синхронизирую комментарии с кодом.

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

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

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

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

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

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

Я бы исправил комментарии.

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

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

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

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

Я всегда исправляю комментарии - в первую очередь потому, что я обычно работаю над фрагментом кода. Для меня это может быть что-то вроде ОКР, но мне просто нравится код, над которым я работаю, чтобы он выглядел красиво - хорошие имена переменных, форматирование (теперь это не проблема современных IDE) и комментарии.

Я не верю код можно «рефакторировать до уровня самодокументирования». Его можно реорганизовать до такой степени, что нужны только комментарии для функций, процедур, переменных-членов, классов и т. Д., Потому что каждый вызов функции занимает всего 1-5 строк. Исходя из опыта работы с Лиспом, я люблю программировать через декомпозицию - намного проще, тестируемо и легче доказать правильность.

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

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

second = (int) (milliseconds / 1000);

Если вы спрашиваете, как мы можем узнать время с такой точностью взгляните на ответ Эстебана ... кристалл кварца вибрирует в определенный период времени, скажем, 0,00001 секунды. Мы просто делаем схему, которая считает вибрации. Когда мы достигли 100000 колебаний, мы объявляем, что прошла секунда, и обновляем часы.

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

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

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

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

Это похоже на вопрос переформатирования - изменение интервала, изменение положения открывающих фигурных скобок и т. Д. И многое зависит от владельца. Собираетесь ли вы находиться в папке в 20 раз чаще, чем парень рядом с вами? Или на 1/20 чаще? Если это последнее, неужели вы действительно хотите его дезориентировать?

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