Что я должен поместить в комментарии заголовка в верхней части исходных файлов?
Простым способом,
var a =20; function a(){this.a=10; console.log(a);}
//20, since the context here is window.
Другой экземпляр:
var a = 20;
function ex(){
this.a = 10;
function inner(){
console.log(this.a); //can you guess the output of this line.
}
inner();
}
var test = new ex();
Ans: Консоль будет печатать 20.
Причина, функция выполняет свой собственный стек, в этом примере функция ex выполняется с оператором new, поэтому будет создан контекст, и когда inner будет выполнен, JS создаст новый стек и выполнит inner, но существует локальный контекст.
Итак, если мы хотим, чтобы функция inner имела локальный контекст, который является ex, нам нужно привязать контекст к внутренней функции .
Стрелки решают эту проблему, вместо того, чтобы принимать Global context, они берут local context, если они существуют. В given example, он примет значение new ex() как this.
Итак, во всех случаях, когда привязка является явной, Arrows решает проблему по умолчанию.
10 ответов
Дата создания, дата изменения и автор, который последний раз изменял файл, должны храниться в исходном управляющем программном обеспечении.
Обычно я ставлю:
- основное назначение файла и вещи внутри файла.
- Проект/модуль, к которому принадлежит файл.
- Лицензия, связанная с файлом (и файлом LICENSE в корне проекта).
- Кто отвечает за файл (либо команда, человек, либо и то, и другое)
В большинстве организаций все файлы исходных текстов должны начинаться с правовой рекламы. Если вам действительно повезло, то это всего лишь один лайнер, но в большинстве случаев это действительно длинный блок легальности. В результате, немногие люди когда-либо читали это. Наш глаз просто переходит к первому программному элементу, а затем к его документации.
Итак, если вы хотите что-нибудь записать, напишите это вместе с самым верхним программным элементом, а не с файлом.
Любая другая бухгалтерская информация должна, как правило, быть частью вашего контроля версий, а не поддерживаться (плохо) в самом файле.
Вы не упоминали, что используете систему контроля версий, и ваш комментарий в ответе Neil N подтверждает это для вашего старого кода. Хотя использование системы контроля версий - это лучший способ, я также сталкивался со многими ситуациями, когда затраты на старый код не оплачивались бы спонсором проекта. Если у вас нет централизованной истории изменений для проекта, то историю изменений можно поместить в модули. Хорошо, что вы используете систему контроля версий для вашего нового кода.
Your company name
All rights reserved (c) year - or reference to appropriate license
Project or library this file is for
Module it belongs to
Description of what it contains
History
-------
01/08/2010 - Programmer - version
Initial creation.
01/09/2010 - Programmer - version
Change description.
01/10/2010 - Programmer - version
Change description.
Многое зависит от того, используете ли вы инструмент генерации автомашины или нет.
В то время как я согласен со многими комментариями, если вы используете Javadoc или какой-то другой инструмент для создания документации, который зависит от комментариев, вы, очевидно, должны включать то, что он хочет видеть.
Сальса делает несколько хороших предложений. Я бы добавил, что сервер разработки Django - отличная среда для отслеживания этих вещей. Иногда я даже запускаю его из производственного каталога (hasp!) с ./manage.py runserver 0.0.0.0: 8000 , так что я знаю , что выполняю тот же код.
Надо признать, что иногда что-то провалится под Apache, а не под dev-сервером, но это намек сам по себе.
-121--4998566-При копировании файлов вне Visual Studio (например, в проводнике Windows) необходимо скопировать все три файла.
Но при работе в Visual Studio необходимо скопировать только базовый файл .vb ; .designer.vb и .resx будут скопированы автоматически. Как это сделать? Щелкните правой кнопкой мыши по файлу проекта в обозревателе решений и выберите Добавить - > Существующие Пункты .
-121--4132877-В дополнение к приведенному выше комментарию о лицензии, проекте, которому он принадлежит, и т.д. Я также склонен ставить «странные» требования в верхней части (например, «built with version X of library Y»), чтобы вы или человек, который забирает его после того, как вы не измените то, на что полагается программа, не осознавая этого (или, если они это сделают, они, по крайней мере, будут знать, что изменить обратно)
включают следующую информацию:
- Что это файл для . Это очень полезный знание, и это важнее всего, чем все остальное. Вы должны сказать читателю, почему есть такой файл, почему вы группировали функции в отдельном файле / пакете / модуле и почему они используются. Может быть, кратко, одна или две линии, но это должно быть там.
- Правовые материалы , если простые.
- Оставьте место для специальных команд консольных редакторов, таких как Emacs.
- Добавьте специальные команды, которые требуют вашей системы автоматической документирования.
Вещи, которые вы должны , не включают , включают
- , которые создали файл
- , когда он был создан
- , который изменил его в последний раз
- , когда он был последним изменен
- То, что было добавлено последней модификацией
. Вы можете - и должен - получить его через систему управления версией, где она постоянно и автоматически сохраняется. Не говоря уже о том, что большинство этих очков просто бесполезны.
Те полезные поля, которые вы упомянули, являются хорошими. Кто изменил файл и когда.
Ваше программное обеспечение для управления версией должно разрешить встраивание ключевых слов в комментарии. Например, в CVS $ ID $ будет разрешаться в файл, модифицированный дату / время, и пользователь, который изменил файл. Он будет автоматически сохраняться в курсе каждой регистрации.
Какие поля вам нужны? Если вы должны спросить, нанести ли некоторую информацию там, вам действительно не нужна эта информация. Если вы не вынуждены, по какой-то бюрократической некомпетентности вашего работодателя, я не понимаю, почему вы должны искать больше информации, чем вы уже чувствуете, должны быть там. \
Это кажется умирающей практикой.
Некоторые люди здесь в Stackoverflow против кодовых комментариев в целом (рассуждение того, что код должен быть написан, чтобы быть самоснабжением), пока я не пойду так далеко, некоторые из точек толпы анти-комментария имеют смысл, такие как Факт, что комментарии, как правило, устареют.
Заголовок блоков комментариев страдают от этих симптомов еще больше. Каждая организация, которую я был с тем, что имел эти заголовочные блоки, они устарели. У них есть автор имени некоторых парня, который даже не работает там больше, описание, которое не соответствует коду вообще (при условии, что он когда-либо делал) и последняя модифицированная дата, которая однажды по сравнению с историей управления версиями, кажется, пропущена его последние дюжины обновлений.
На моем личном мнении сохраняйте комментарии близко к коду. Если вы хотите узнать цель, и / или история файла кода, используйте вашу систему управления версиями.
Вернувшись в 2002 году, когда я был прямым из колледжа, и рабочие места были немногие и далеко между до Dot-Combust, я присоединился к сервисной компании, которая использовалась для создания программного обеспечения для их клиентов в Ява. Мне пришлось сидеть в кабинете клиента (который был Ramshackle Room в электрической подзаконе, оснащенной AC, чтобы сохранить работу серверов), совместно используя стулья / шт с другими парнями в команде. Другие инженеры (если я смогу позвонить им инженеров;) в группе, используемой для внесения изменений AD-HOC для исходного кода, компилируйте файлы и помещают их в производство.
- Нет способа выяснить, кто сделал то, что изменение.
- Нет способа выяснить, почему любые изменения были сделаны.
- Нет способа перейти к предыдущей версии кода, если только инженер не «запомнил», что он изменен.
- Резервное копирование: копировать файлы с производственного сервера, которые были заменены новыми файлами.
- Местоположение резервного копирования: домашний каталог инженера, копировавшись над файлами на производственный сервер.
Отчеты о производственных серверах, происходящих спускаясь из-за непоколебимых попыток копирования файлов на сервер (пропущенный файл, который будет скопирован, резервные копии, полученные заблокированные или неправильные файлы, скопированные или не все файлы скопированы), были встречены с пожиманием (О нет, это вниз? Давайте посмотрим, что произошло; Эй, кто изменил то, что недавно ... УМММ ...).
В те дни, проведев несколько неприятных дней, пытаясь выяснить, кто и сжимает позади кода, я разработал систему для комментариев в списке в заголовке исходного файла, который подробно описан следующее:
- Дата Изменения сделаны
- , которые сделали изменение
- , почему было сделано изменение
через два месяца спустя, когда список угрожал оспаривать размер исходного кода в файле, менеджер имел яркое представление о получении источника Система управления версиями.
Мне никогда не нужно было поместить какие-либо комментарии в заголовки исходных файлов (за исключением уведомлений об авторских правах) в любой компании, с которой я работал с тех пор. В моей нынешней компании все остальное в основном самоочевидно, глядя на код или собираюсь в систему отчетности ошибок, которая интегрирована с системой управления исходной версией.