Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

PHP для начинающих


PHP предоставляет несколько методов для вставки комментариев. Проще всего пользоваться двойным слэшем в стиле языка С++ (//),после чего PHP машина игнорирует все, что расположено до конца строки. Также можно пользоваться многострочными комментариями в стиле С (/*…*/). Для однострочных комментариев можно еще пользоваться символом решетки (#) (комментарий скриптовых языков UNIX).
<php
echo("<p>Hello</p>"); // комментарий
echo("<p>Hello</p>"); # комментарий
/*
и это тоже комментарии
*/
?>
Следует помнить о том, что стили комментариев PHP действуют только внутри ограничителей PHP. Если PHP встретит эти символы комментариев вне ограничителей, то они, как и любой текст, будут помещены на html-страницу. Например:
<php
echo("<p>Hello</p>"); // нормальный комментарий
?>
// а вот этот комментарий отобразиться броузером.
<!-- Комментарий HTML.
Будет виден в исходном коде HTML, но не в браузере
-->
Заметим, что комментарии можно вставлять не только после конца оператора, а, например, и вот так:
<?
$a = "Hello, world";
echo strstr($a,"H");
// эту функцию мы рассмотрим позднее
?>

Собственно, это все. Если говорить о том, КАК писать комментарии. Другой вопрос -- ЗАЧЕМ их писать. Это вопрос философский. Нет проектов, которые пишутся одиночкой. По определению -- таких проектов уже нет. Разумеется, мы считаем проектом сайт с более полезной нагрузкой, чем личная страница :)

А если разработчиков больше одного -- они как минимум должны друг друга понимать. Очень правильно сейчас было бы сказать о том, что работа должна начинаться с проектной документации, но будем реалистами -- сначала создается "игрушечная модель", потом она доводится до реального проекта, плавно (это еще в лучшем случае!) эволюционируя к тому, что задумывалось. В полном соответствии с концепцией "экстремального программирования", где основополагающими  приняты принципы "проект всегда должен быть в рабочем состоянии" и "проект всегда должен быть отзывчив к быстро меняющейся ситуации".

Это, конечно, не означает, что документация не нужна в принципе, но приносит понимание, почему сопроводительная документация часто столь неадекватна тому, что она описывает. Просто проект меняется, а вести параллельным курсом документацию часто пустая трата времени. Имеет смысл "post factum" документировать уже пройденые этапы, чтобы не терять "нить" разработки, но и все.

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

Правила написания комментариев могут быть как "правила хорошего тона", так и разновидностью языка программирования. Дело в том, что есть целые программные продукты, предназначенные для того, чтобы "выдирать" комментарии из программного кода и на их основе строить стандартизированную документацию. В случае с PHP это, конечно phpDocumentor (http://www.phpdoc.org/). И дело не только в том, чтобы Вы сами ориентировались в собственном коде. Библиотеки, откомментированные должным образом, используются справочной системой среды разработки. И если Вы работаете в среде от Zend (http://www.zend.com), то сможете оценить это в полной мере. Равно как и другие разработчики будут Вам благодарны, используя Ваш код.

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


Ведущая рассылки Екатерина mailto:kate@webfile.ru
Сайт рассылки http://webfile.ru


В избранное