Не пишу на php, но оформление статьи вызывает уважение.

Ссылки «наверх» не нужны.

Со всем согласен, видел не раз, кроме ?> применять нужно. Хотябы из-за того, что это стандартный формат. А на счет пробелов в конце - хороший редактор позаботится о них сам.

понравилась статейка, особенно про ?>

Ценно, спасибки.

define('N',"\n") - почему разные кавычки?
спасибо за ?>

Понравилось. Хоть я на PHP уже давно не пишу, а PHP5 и в глаза не видел. :)
За оформление статьи - отдельный респект.
Ловите заслуженный карма-плюс =)

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

Мой трехлетний опыт программирования на PHP позволяет говорить о следующем:

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

На практике запятую при выводе echo практически не используют. Зачастую больший смысл имеет использование конкатенации (оператора точка). Эффект от использования запятой в коде — экономия на спичках, не более.

define('N',"\n"); echo 'foo' . N;

- это очень (совсем!) вредный совет, забудьте об этом.

Про использование ?> — в некотором смысле солидарен с автором. Опускать данный маркер имеет смысл лишь в описании классов и в некоторых других (редких) случаях. В типовых ситуациях, например, в окончании шаблонов (и т.п.) опускать маркер конца PHP-кода не нужно, будьте ближе к семантике документа.

Я бы сильно поспорил с плохой читаемостью HEREDOC, а в "эмуляции" file_put_contents надо обязательно добавить flock.

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

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

Спасибо за статью, о запятой услышал первый раз, не смотря на 4хлетний опыт :)

Маленькая ошибочка - include выдает E_WARNING, а не E_NOTICE.

Моё имхо по поводу статьи:

Очень важный момент - ?> - действительно лучше не использовать в конце файла. Толку от неё - ноль.

echo 'asd' . 'dsa' против echo 'asd', 'dsa' толком никакой разницы не несут. Равно как и echo 'asd' против echo "asd". Выбирать что использовать лучше из общепринятых стандартов - двойные кавычки ТОЛЬКО когда в этом есть смысл (т.е. нужен парсинг переменных внутри и тп). И echo 'asd' . 'dsa' вместо конкантенации параметров запятой. Причём по скорости разницы можно сказать что вообще нет. Задумываться об этом глупо потому что в любой PHP-программе есть 99.99% мест заслуживающих большего внимания ;).

echo или print.. print используется теми кто к нему привык - т.е. пересаживается с Си, например. В php-мире превалирует-таки echo. Это факт.

Статья хорошая, автору - зачёт =)
Из комментов подчерпнул PHP_EOL, спасибо bolk'у.

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

Тем, кто ещё не уверен в закрывающем теге ?>, выдержка из официального мануала:

«The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include() or require(), so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.»

http://www.php.net/manual/en/language.ba…

а я отношусь к "начинающим и немного продвинутым".
Спасибо вам большое за статью. Вы молодец не взирая на всякие там плюсы и минусы.

Хорошая статья.

В нескольких местах Вы упоминаете о скорости парсинга кода. Если такой вопрос вообще встает (т.е. сайт становится посещаемым), то первое, что надо сделать - это отказаться от парсинга на каждый запрос. Файл скрипта должен парситься один раз при старте сервера, и дальше лежать в памяти в виде исполняемого байт-кода (для этого есть всякие код-кэши и оптимайзеры). И тогда между, например, 'foo' и "foo" не будет ровно никакой разницы.

Про это есть статья на любом ресурсе, который хоть как-то относится к php. Но написано бесспорно лучше своих аналогов :)

Можно не боясь добавлять require_once в каждый модуль, где нужна библиотека.

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

Блин, пофиксите не закрытый тег в каком-то комменте, невозможно читать остальные комментарии :(

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

Кто сломал хабр? =(
Статейка понравилась :)
Заплюсовал и повысил карму. Пиши еще =)

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

отличный материал. Продолжай.
вот только насчет
define('N',PHP_EOL); echo 'foo' . N; читабельнее чем echo "foo\n";

я не согласен. С детства к "\n" привык :))

То, что "HEREDOC в десять раз медленее своих коллег", это явное преувеличение. Max на 10-15% и то, если внедрять переменные. Сам когда-то тестировал.
А если нужно, например для тестирования, быстро в переменную положить всю html страницу, то альтернатива только чтение из файла.

Что то комменты совсем сжались в право, давайте ка обратно их сдвинем!

Что хотелось бы добавить:
Культура программирования вещь достаточно своеобразная.
Сколько программистов - столько и культур.
Каждый программист будет программировать так, как только ему наиболее удобно, нет конкретных правил в каком формате писать код, главное чтобы работало. НО! Тогда опускается тот факт, что возможно с кодом будет работать другой человек, и ему будет дико неудобно разбирать "стиль" автора. Тогда что же? Подстраиваться по до всех кодеров? Наверное всетаки нет.
Ктото пишет функции так:
foo {
    ...
}
а ктото так:
foo { ...; ...; ...; }
(и такое видел)
и если вдруг, по работе, заставят разбирать такой код, мы выругаемся как следует (!) и будем разбиратся в ТАКОМ коде, или же для начала приведем его в удобный для СЕБЯ вид.

Так что имхо, нужно писать так, чтобы было удобно, и без ошибок =)

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

в принципе, комментарии по делу, хоть расказывается о довольно известных вещах. Хотелось бы видеть продолжение материала )

• Выносим переменные из текстовых строк — ускорение 25-40%
  
• Короткие переменные не более 7 символов — ускорение 15%
  
• Тормозят ли массивы в PHP? Вернее, как именно — ускорение 40%
  
• Выносим многомерные массивы из текстовых строк —
  ускорение 25-30%
  
• Регулярные выражения: PHP(POSIX) vs. Perl — ускорение 60-200%
  
• Циклы: for, foreach, while, count/sizeof() — ускорение 15%-30%
  
• Для чтения файла file() быстрее, чем fopen+цикл — ускорение 40%

Автор статьи:  DEL
Дата публикации: 26 июня 2007
Ссылка на статью: http://www.habrahabr.ru/blog/webdev/1879…

ещё одно большое отличие require от include состоит в том, что include возвращает значение, как функция.
например:

$variable = require("path/to/file.php");
вернёт null, а
$variable = require("path/to/file.php");
может вернуть любое значение, если в файле file.php было сделано return $something;

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

file.php:
<?php
return array("key"=>"value");

Держи зачет! Отличная статья, даже узнал немного нового, например, про file_put_contents :) А я, неуч, постоянно свою функцию писал :)

Незнаю… может кому-то будет полезным функции print_r( ) и var_dump( ), использую ежедневно:

bool print_r (mixed expression [, bool return]);

void var_dump ( mixed expression [, mixed expression [, ...]])

Приятного всем использования. =)

Спасибо, некоторые моменты разжевали в лучшем виде!
Однако отбейте заголовки пробелом сверху.
Пример:
«php.net и Zend Framework тоже так <a href=»думают.
require, include, readfile"
слиплись.