Как закомментировать php код

Шпаргалка как правильно закомментировать код в HTML, XML, CSS, PHP, JavaScript

• Stats: 8030 2
• Author: admin
• Category: Статті, Шпаргалка
• Comments: Комментариев нет
• Tags: css, HTML ++, JavaScript, PHP, XML, Закомментировать CSS, закомментировать HTML, Закомментировать JavaScript, Закомментировать PHP, Закомментировать XML, закомментировать код

Закомментировать HTML

< ! -- < div class = "redblock" > < p >This is some HTML in

the redblock class . < / p > < / div >— >

Закомментировать CSS

Закомментировать PHP

Закомментировать JavaScript

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

Похожие материалы:

Оформление ФОП в Украине в 2018 году через Интернет. Пошаговая инструкция — положительный исход!

Google открывает домен .dev для всех желающих

Google может начать более детально оценивать скорость загрузки в ранжировании

admin

создание сайтов, seo, smm

Как закомментировать кусок кода в VS Code?

Недавно перешёл на этот редактор кода, и возникают проблемы с комментированием: раньше работал в Sublime, там всё решалось выделением необходимого куска кода и сочетанием клавиш Ctrl + Shift + / .

Отслеживать
задан 20 июн 2020 в 16:30
Никита Попов Никита Попов
327 1 1 золотой знак 2 2 серебряных знака 15 15 бронзовых знаков

4 ответа 4

Сортировка: Сброс на вариант по умолчанию

Ctrl + / — закомментировать / раскомментировать.

Отслеживать
ответ дан 29 авг 2020 в 18:42
56 2 2 бронзовых знака

shift + alt + a закомментировать

Отслеживать
67.9k 216 216 золотых знаков 77 77 серебряных знаков 219 219 бронзовых знаков
ответ дан 15 апр 2021 в 9:38
21 1 1 бронзовый знак

VSCod автоматически определяет какого вида комментарий создать:

• HTML — вот в таком виде:
• CSS — вот в таком виде: /*данные*/

В другом виде, типа «//» и ещё варианты у меня не срабатывают (может кто подскажет).

Закомментировать / Раскомментировать:

(где «/» — не на цифровом блоке);

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

2.) shift + alt + a

• создать новый в любом месте;
• то, что выделено.

Как закомментировать в PhpStorm целый блок одной клавишей

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

Комментарии: плохие и хорошие

Возможность комментирования кода доступна на большинстве языков программирования (возможно, на всех, но с разной степенью доступности). Как правило, словесные разъяснения используются для того, чтобы помочь в дальнейшей разработке другим членами команды, или просто напомнить себе о том, что для этого участка нужны исправления (“FIX ME”).

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

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

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

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

Иногда подобное чувство одолевает и профессионалов. К примеру, когда все выглядит удивительно криво — должно же быть решение получше. Чтобы уберечь последователей от поиска лучшего, программист может оставить такую записку: #time_spent_here=24h

После таких слов мало кто захочет тратить столько времени. Таким образом, вы предупреждаете, что множество разных вариантов уже перебрали. В то же время, стоит избегать таких выпадов: #i_hate_this, #try_to_do_better_ass%%le. Подобным образом вы проявляете лишь непрофессиональное отношение. Не стоит компрометировать себя и работодателя.

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

Тег, как элемент функционала

Несмотря на то, что комментирование задумывалось как разъяснение и помощь при командной разработке, этими функциями пользуются не так часто. Как правило, теги ставят там, где хотят остановить выполнение кода. Представим, что у вас есть PHP, встроенный в HTML. И вы не хотите его cтирать, а лишь желаете посмотреть, как выглядит страница без него. Для этого необходимо соблюдать такой синтаксис:

Стандарты оформления кода PHP

Использование стандартов при разработки проектов на SIMAI Framework позволяют создавать единоообразный код доступный и понятный для дальнейшей работы с ним.

Введение

Почему стандартизация так важна

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

• программисты могут прочитать код и легко разобраться, что в нём происходит;
• новые программисты быстрее вписываются в проект;
• новые люди в PHP избавлены от необходимости разрабатывать свой персональный стиль и стоять насмерть, защищая его;
• новые люди в PHP избавлены от «необходимости» допускать те же самые ошибки, которые всегда допускают новички;
• в устойчивых системах люди делают меньше ошибок;

Принятие стандарта

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

Выбирайте правильные имена

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

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

И если вы вдруг обнаружили, что все объекты вашего кода называются Фигня и Штуковина, то такой код вам стоит серьёзно пересмотреть.

Формирование имён

Имена классов

• Давайте классу имя тогда, когда вы знаете, что этот класс будет делать, как и для чего. Если вы этого не знаете, то вполне возможно, вы не продумали до конца концепцию модуля;
• Наличие имён, составленных более чем из трёх слов, может привести к тому, что система будет путать различные объекты программы. Пересмотрите код программы. Прогоните код через контроль циклически избыточного кода CRC и посмотрите, не берут ли ваши объекты на себя больше задач, чем вы планировали;
• Не поддавайтесь искушению присвоить производному классу имя производное от имени родительского класса. Лучше будет, если класс будет жить своей жизнью, кто бы ни был его родительским классом;
• Иногда помогают суффиксы. Например, если в вашей системе используются различные агенты, то имя типа DownloadAgent несёт достаточную смысловую нагрузку;
• В качестве разделителей слов используйте заглавные буквы, строчные — для остальной части слов;
• Первая буква в имени — заглавная;
• Никаких underscore-ов (‘_’).

class NameOneTwo;
class Name;

Имена методов

Как правило функция или метод совершают какое-либо действие, поэтому желательно, чтобы из имени было понятно, какое именно действие будет совершаться: CheckForErrors() [ИщиОшибки()] вместо ErrorCheck() [ПоискОшибок()]; DumpDataToFile() [СваливайДанныеВФайл()] вместо DataFile() [ФайлДанных()]. Кроме того, так легче будет отличить метод от класса.

Иногда помогают суффиксы:

• Max — чтобы показать максимальное значение;
• Cnt [count: количество, подсчёт] — чтобы показать текущее значение какого-либо счётчика;
• Key — чтобы показать ключевое значение. Например: RetryMax содержит максимальное количество возможных попыток, а RetryCnt — номер текущей попытки;

Префиксы тоже иногда нелишни:

• Is — для обозначения вопроса. Где ни встретится вам Is, вы всегда будете знать, что это вопрос;
• Get — получить значение;
• Set — установить значение.

Например: IsHitRetryLimit() [примерно: это ли последняя попытка?].

Никаких аббревиатур заглавными буквами

При формировании имён, содержащих сокращения, люди используют свои интуитивные системы по-разному, поэтому лучше придерживаться единой стратегии формирования имён для всех случаев и добиться тем самым предсказуемости именования. Возьмём, к примеру, NetworkABCKey. Заметьте, что C от ABC и K от Key воспринимаются больше как буквенное сочетание. В принципе, некоторые не возражают против аббревиатур целиком из заглавных, другие же их просто ненавидят; так что в разных проектах люди придерживаются разных стратегий.

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

 function FluidOz() //а не FluidOZ function GetHtmlStatistic() //а не GetHTMLStatistic class NameOneTwo < function DoIt() <>; function HandleError() <>; > 

Имена аргументов в методах

• Первая буква — всегда строчная;
• Все остальные слова в имени начинаются с большой буквы, как при именовании классов.

Обоснование

Всегда можно легко определить, какие переменные поступили в метод в качестве аргумента.

 class NameOneTwo < function StartYourEngines(&$someEngine, &$anotherEngine) < $this->mSomeEngine = $someEngine; $this->mAnotherEngine = $anotherEngine; > var $mSomeEngine; var $mAnotherEngine; > 

Имена переменных

• Используйте только строчные буквы;
• В качестве разделителя слов используйте underscore (‘_’).

Обоснование

• При таком подходе область действия переменных более уловима;
• Все переменные кода выглядят по-разному и легко распознаются при чтении.

Принятие стандарта

 function HandleError($errorNumber) < $error = new OsError; $time_of_error = $error->GetTimeOfError(); $error_processor = $error->GetErrorProcessor(); > 

Имена элементов в массивах

• Именование элементов массивов происходит по правилам именования переменных;
• В качестве разделителя слов используйте underscore (‘_’);
• И не используйте в качестве разделителя дефис (‘-‘).

Обоснование

Если в качестве разделителя используется дефис, то при включении опции Magic Quotes вы получите сообщения об ошибках.

 $myarr['foo_bar'] = 'Hello'; print "$myarr[foo_bar] world"; // выведет: Hello world $myarr['foo-bar'] = 'Hello'; print "$myarr[foo-bar] world"; // получим warning 

Одиночные и двойные кавычки

Осуществляя доступ к элементам массива, можете использовать как одинарные, так и двойные кавычки. Не используйте кавычки при включённой опции Magic Quotes.

Обоснование

За исключением случаев использования Magic Quotes, некоторые конфигурации PHP выдают сообщение об ошибке, если при доступе к элементам массива кавычки опускаются.

 $myarr['foo_bar'] = 'Hello'; $element_name = 'foo_bar'; print "$myarr[foo_bar] world"; // выведет: Hello world print "$myarr[$element_name] world"; // выведет: Hello world print "$myarr['$element_name'] world"; // parse error print "$myarr["$element_name"] world"; // parse error 

Глобальные переменные

В именах глобальных переменных рекомендуется использовать префикс ‘g’.

Обоснование

Такой префикс необходим для определения области действия переменных

 global $gLog; global &$grLog; 

Имена функций

Для функций PHP используйте правила C GNU: имена из строчных букв с underscore-ами (‘_’) в качестве разделителей.

Обоснование

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

 function some_bloody_function()

Форматирование

Правила расстановки фигурных скобок

Из трёх существующих стилей расстановки фигурных скобок допустимы два, причём первому рекомендуется отдавать предпочтение:

открывающая скобка ставится под соответствующим оператором и на одном отступе с ним:

 if ($condition) while ($condition) < < . . >> 

 if ($condition)

Обоснование

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

Преимущество первого стиля заключается не только в психологии. Если вы используете текстовый редактор (например, vi), поддерживающий проверку на парность скобок, первый стиль будет более удобен. Почему? — спросите вы. Допустим, вы наткнулись на большой блок кода и желаете узнать, где же он заканчивается. Наводите курсор на открывающую скобку, жмёте нужную кнопку и редактор находит парную скобку.

 if ($very_long_condition && $second_very_long_condition) //два очень длинных условия < . >else if (. )

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

Правила расстановки скобок () рядом с операторами и функциями

• Не ставьте скобки сразу за операторами. Разделите оператор и скобки пробелом;
• Ставьте скобки непосредственно сразу за именем функции;
• Не используйте скобки в блоке return, если нет в этом необходимости.

Обоснование

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

 if (condition) < >while (condition) < >strcmp($s, $s1); return 1; 

Правила по отступам/табуляциям/пробелам

• Отступ для каждого нового уровня — 3-4 пробела;
• Используйте не табуляцию, а пробелы. Большинство редакторов в состоянии пробелы заменить табуляцией;
• Делайте столько отступов, сколько вам нужно, но не более того. Если вы делаете отступ более, чем четвёртого-пятого уровня, стоит подумать о вынесении кода в отдельный блок.

Обоснование

• Когда люди используют разные значения табуляции, код бывает невозможно прочитать или распечатать, поэтому пробелы предпочтительнее;
• Никто никогда не договорится об оптимальном количестве пробелов. Просто будьте последовательны. 3-4 пробела — наиболее распространённое явление;
• С того момента, когда люди вознамерились ограничить количество уровней отступа, кажется, что ни разу они так ничего и не добились. Мы надеемся, что программисты сами примут мудрое решение о достаточной глубине отступов.

 function func() < if (something bad) //не подходит < if (another thing bad) //тоже не подходит < while (more input) //ещё код < >> > > 

Форматирование блоков if then else

Внешний вид

На вкус программиста. Разный стиль расстановки фигурных скобок обусловит немного разный внешний вид условных блоков. Вот один из распространённых стилей:

 if (condition) // Комментарий < >else if (condition) // Комментарий < >else // Комментарий

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

Формат условия

При сравнении всегда ставьте константы слева. Например:

 if ( 6 == $errorNum ) . 

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

Формат switch

• При наличии соответствующего комментария допускаются блоки, передающие управление вниз;
• Рекомендуется всегда ставить блок default, который бы сообщал об ошибке в случаях, когда попадание на него должно быть исключено, но тем не менее имело место;
• Если вам нужно создать какие-либо переменные, то весь соответствующий код ставьте внутри блоков case.

 switch (. ) < case 1: . // УПРАВЛЕНИЕ ПЕРЕДАЁТСЯ ВНИЗ case 2: < $v = get_week_number(); . >break; default: > 

Использование continue, break и ?:

Continue и break

Continue и break — это тот же самый goto, только названы по-другому. Именно поэтому они рассмотрены в этой части документа.

Как и goto, continue и break творят всякие разные чудеса в коде, поэтому их использование рекомендуется свести до минимума. Одним мановением руки читатель кода переносится бог знает куда по какой-то незадокументрированной причине. При использовании continue возникают две проблемы:

• continue может обойти условный блок;
• continue может обойти наращивание/уменьшение.

Представим себе ситуацию, где имеют место обе проблемы:

 while (TRUE) < . // Много кода . if (/* какое-то условие */) < continue; >. // Много кода . if ( $i++ > STOP_VALUE) break; > 

Note: «много кода» нужно для того, чтобы программист не смог легко отследить проблему.

Из приведённого выше примера мы можем составить себе следующее правило: использование continue и break в одном блоке — прямая дорога к багам.

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

• Условие заключайте в скобки, тем самым отделяя его от остального кода;
• По возможности действия, производимые по условию, должны быть простыми функциями;
• Если весь блок ветвления плохо читается, будучи расположен на одной строке, то блоки else и then размещайте каждый на отдельной строке.

 (условие) ? funct1() : func2(); or (условие) ? длинный блок : ещё один длинный блок; 

Выравнивание блоков объявления переменных

Блок объявления переменных должен выравниваться

Обоснование

• Прозрачность стиля;
• Блоки инициализации переменных также рекомендуется выравнивать табуляцией;
• Знак & должен ставиться при типе переменной, а не при её имени.

 var $mDate var& $mrDate var& $mrName var $mName $mDate = 0; $mrDate = NULL; $mrName = 0; $mName = NULL 

Документация

Несколько комментариев по комментариям

Комментарии должны быть содержательными

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

Документируйте принятые решения

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

Используйте заголовки

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

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

Стиль комментариев

Каждая часть проекта имеет свой особый стиль комментариев.

Явно указывайте на gotchas [«ловушки» в коде]

Формат описания gotchas

Ключевое слово gotcha должно ставиться в самом начале комментария.

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

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

 // :TODO: tmh 960810: возможны проблемы со скоростью работы // Нам точно понадобится хэш-таблица, но пока // мы используем линейный поиск. // :KLUDGE: tmh 960810: потенциально небезопасное приведение типа // Приведение понадобилось для восстановления производного типа. Возможно // здесь понадобится виртуальный метод или шаблон 

Зарезервированные слова для описания gotchas

• :TODO: Означает, что здесь нужна доработка, простое напоминание.
• :BUG: [id] Означает, что здесь находится выявленная ошибка, дайте описание и (не обязательно) номер ошибки.
• :KLUDGE: Если то, что вы сделали, ужасно выглядит и работает, отметьте этот факт и объясните, как вы поступите в следующий раз, если у вас будет время.
• :TRICKY: Сообщение о том, что данный отрезок кода очень сложен в исполнении и потому не стоит ничего менять, не разобравшись предварительно во всех «коварствах» конструкции.
• :WARNING: Предупреждение о чём-либо.
• :PARSER: Иногда вам приходится что-то делать для успешного парсинга. Задокументируйте этот факт. Возможно, со временем проблема исчезнет.
• :ATTRIBUTE: Общий вид представления атрибута в комментарии. Вы можете создать свои атрибуты, и они тоже будут извлечены роботом.

Документация интерфейсов и реализаций

Существует два вида читателей для вашей документации:

• пользователи класса
• разработчики класса

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

Пользователи класса

Пользователям класса необходимы сведения об интерфейсе класса; такие сведения легко добываются из заголовков, если, конечно, они правильно структурированы. При заполнении заголовочного блока комментариев, давайте только сведения, необходимые для использования класса. Не вдавайтесь в подробности реализации алгоритма — не надрывайтесь. Исключение составляют случаи, когда знание алгоритма необходимо для корректного использования класса. Воспринимайте заголовочный блок комментариев как без пяти минут главу из технического руководства.

Разработчики класса

Разработчикам класса требуется глубокое знание реализации класса. Комментарии этого типа находятся в файлах с исходным кодом класса; забудьте на время про особенности интерфейса. Заголовочный блок комментариев в исходнике должен описать все особенности алгоритма и решения по проектированию класса. Блоки комментариев внутри методов реализации должны предоставить ещё более подробную информацию.

Документация по директориям

В каждой директории проекта должен находиться файл README с описанием следующих моментов:

• Зачем была создана данная директория и что она содержит;
• По строчке описания каждого файла этой директории. Как правило, описание берётся из значения атрибута NAME в заголовке файла;
• Инструкции по сборке и установке;
• Ссылки на связанные источники: директории исходников, online документация, документация на бумажных носителях, документация по разработке;
• И всё, что как-либо может помочь.

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

Разное

Повторное использование кода

Повторное использование кода за пределами одного проекта практически невозможно, если у вас нет разработанного проектного каркаса [framework]. Объекты строятся в соответствии с предоставляемыми сервисами. В разных проектах разные наборы сервисов, что и усложняет повторное использование объекта.

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

Не бойтесь маленьких библиотек

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

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

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

Держите свою базу библиотек [репозиторий]

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

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

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

Временное комментирование больших блоков

Иногда при тестировании возникает необходимость закомментировать большой блок кода. Самый простой способ — это заключение блока в конструкцию if(0):

 function example() < роскошный код if (0) < много кода >ещё больше кода > 

Комментарии /**/ вы использовать не можете, потому что комментарии не могут содержать комментарии, а большой блок вашего кода непременно будет содержать комментарии, ведь так?