Статьи

Хранение вашего PHP-кода хорошо документировано

Вступление

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

1. Напишите код, который объясняет сам

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

Наименование переменных, функций и классов
Поскольку вы можете называть свои фрагменты кода практически любым удобным для вас способом, вы можете использовать его как свое преимущество с точки зрения сохранения понятности кода. Просто не забудьте выбирать четкие имена, чтобы не придумывать какие-либо странные сокращения или использовать имена, которые могут быть неоднозначными. Если ваша переменная представляет собой экземпляр класса VeryImportantCustomer , просто назовите его $veryImportantCustomer , а не $customer , $vimpCust или $tempcustomer . Не бойтесь делать опечатки в длинных именах, так как ваша IDE, вероятно, предупредит вас о неиспользуемых переменных или других несоответствиях в вашем коде. Я уверен, что правильное именование поможет понять, что происходит в вашем коде. Это простое правило, но оно может быть легко забыто в вашей повседневной работе.

Тип подсказки
PHP позволяет помещать имена классов / интерфейсов или ключевые слова / array рядом с параметром функции. Он предотвращает неправильные вызовы функций, но также служит важной информацией для любого, кто читает ваш код. Вам не нужно изучать тело функции, чтобы узнать, как вызывать функцию. Вы также можете быстро проверить, как различные функции и классы могут передавать значения между собой. И помните, что ваша IDE, вероятно, будет интерпретировать подсказки типов и использовать их для описания функций во всплывающих окнах или подсказках, которые отображаются во время работы.

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

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

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

2. Сохраняйте равновесие

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

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

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

 <? php class   Deposit   { 

         /** * The deposit owner. * * @var string */ 
         private  $_owner ; 

          /** * The deposit amount. * * @var float */ 
         private  $_amount ; 

         /** * The date when the deposit was opened. * * @var DateTime */ 
         private  $_dateOpened ; 

         /** * Class constructor. * */ 
         public   function  __construct ()   { 
             //... 
         } 

         /** * Sets the deposit owner. * * @param string $owner The deposit owner name. */ 
         public   function  setOwner ( $owner )   { $this -> _owner =  $owner ; 
         } 
 ?> 

Помните, что человек, который читает ваш код, обычно является разработчиком (или, по крайней мере, я так полагаю), поэтому он / она сможет выяснить, что свойство _owner класса Deposit представляет владельца депозита. Вот почему я думаю, что добавление дополнительных комментариев к таким частям кода может даже сделать его менее читабельным, чем каким-либо образом помочь читателю.

Комментарии часто также не нужны в других простых частях вашего кода, не только в определениях свойств класса или типичных методах (таких как конструкторы, методы получения или установки). Просто посмотрите на пример ниже:

 <? php public   function  showUserDetails ()   { $userId =  $this -> Session -> read ( 'userId' ); $userData =  $this -> getUserData ( $userId ); 
     if (! $user -> isActive ())   { 
         throw   new   Exception ( "The user account hasn't been activated." ); 
     } 

     //... 
 } 
 ?> 

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

 <? php /** * Shows the details of the user that is currently * logged in. * */ 
 public   function  showUserDetails ()   { 
     //get the current user from session $userId =  $this -> Session -> read ( 'userId' );    

     //load the user data from database $userData =  $this -> getUserData ( $userId ); 

     //check if the user has an active account 
     if (! $user -> isActive ())   { 
         throw   new   Exception ( "The user account hasn't been activated." ); 
     } 

     //... 
 } 

 ?> 

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

3. Помните про блоки документов

Как видно из приведенных выше примеров кода, некоторые блоки комментариев содержат конкретные ключевые слова, начинающиеся с символа @ . Я использовал @var для описания типа свойства класса и @param для информирования о типе параметра метода. Вы также можете использовать тег @return который сообщает о типе значения, возвращаемого функцией. Другие теги могут использоваться для описания некоторой общей информации о приложении или его части (например, об авторе, пакете, типе лицензии). Вы можете прочитать больше о doc-блоках в статье Введение в PhpDoc, написанной Моше Тойчем.

Теги блоков документов содержат информацию, которая не может быть включена в сам код. Указание типа свойств класса или возвращаемых значений функции особенно полезно, поскольку оно может быть проанализировано большинством IDE и показано в подсказках. Конечно, вы также можете вставить пользовательский текст в блок документа, который будет служить функцией или документацией класса. Это может быть особенно важно, если ваш проект должен иметь свою документацию доступной вне кода. В таких случаях вы можете использовать приложения, которые анализируют блоки документов и генерируют документацию всего приложения на основе их содержимого. Прочитайте документацию Bruno Skvorc « Сгенерируйте с помощью ApiGen», чтобы узнать больше о таком подходе.

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

 <? php class   Deposit   { 

         /** * @var string */ 
         private  $_owner ; 

          /** * @var float */ 
         private  $_amount ; 

         /** * @var DateTime */ 
         private  $_dateOpened ; 

         //... 

         /** * @param string $owner */ 
         public   function  setOwner ( $owner )   { $this -> _owner =  $owner ; 
         } 
 ?> 

Резюме

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

Не стесняйтесь оставлять свои комментарии по поводу пунктов, представленных в статье, или свяжитесь со мной через Google+ . Если у вас другое мнение или вы используете другие правила в своей работе, сообщите нам об этом!