Полезные мелочи программирования на PHP

[Flack]

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

[akral]

Спасибо.
Мой первый хабратопик. А кто-то уже успел его поминусовать. :(

[Flack]

ну, мало кто любит похапе )

[akral]

Ну спасибо, обрадовал. =7

^_^

[sanitar]

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

[akral]

Во первых, в начале я перестраховался, сказав что это для «начинающим и немного продвинутым».

Но вот дело в том, что многие опытные программисты не знают таких простых вещей, как ненужность ?>

[sanitar]

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

[korchasa]

У вас нет пустых строк в файлах? Вы бы проверили, а то частенько всплывают. Причем у всех. Никого же не коробит писать, и что некультурного в незакрывании?

[sanitar]

Да, у меня нет пустых строк в файлах после закрывающих ?>. И ни разу за 7 лет программирования причинами ошибок не становились пробелы после закрывающего ?>.

Вопрос "что некультурного в незакрывании?" считаю провокационным и заданным непрофессионалом.

[korchasa]

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

И если не писать "лапшу", то удобнее опускать ?> , т.к. пустые строки не ломают вывод. В случае же перемешивания разметки и кода тэг действительно необходим. Просто "лапшой" пишет меньшинство(я надеюсь), поэтому не стоит тыкать в технологию не дающую для большинства никаких плюсов, но порождающую минусы. А уж тем более возводить ее в ранг культуры.

[sanitar]

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

[akral]

Честно говоря, я склонен считать, что в этом месте вы немного переступили черту вежливости.
Посмею обвинить вас в снобизме.


Не по теме: странное общество, где такие комментарии получают плюсы. =7

[Raesvelg]

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

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

[akral]

ага ^_^

[Raesvelg]

Я ознакомлен с этими правилами и объяснил, почему не принимаю их, а вот Вам бы еще поучиться уважению к собеседникам.

[akral]

Простите, если это вам показалось обидным.

Я хотел подчеркнуть, что это вряд ли хак, если такое серьёзное общество приняло такое правило. Скорее это просто стиль, так принято у них, так не принято у вас.

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

[Raesvelg]

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

Хаком я назвал это вполне осознанно, так как при наличии более совместимого решения проблемы с заголовками, не имеет смысла ограничивать программистов в стиле.

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

[akral]

Вот тут полностью согласен. Когда можно будет писать
require('foo');
calculate();
<?notphp
<xml></xml>
?>
shutdown();
:(

[sattu]

а что мешает написать так?

[sattu]

хм, хабр съел теги... еще разок:


<?
require('foo');
calculate();
?>
<xml></xml>
<?
shutdown();
?>


[akral]

Так речь то о том и идёт, чтобы "по дефолту" был включен PHP, а не output.

[akral]

Плохой ты. Ломака.

Правда, это скорее претензия к девелоперам хабра, коль они такое позволяют...

[chx]

ненужность ?> под большим сомнением, а вот разница между echo и print интересна. Или между require и include.

[rumkin]

А что там с http-заголовками и ?>, как это влияет на результат?

[akral]

Если мы require() файл, в котором после закрывающего тега пустые символы, то они выводятся браузеру. После этого попробовав послать header() натыкаемся на то, что header должен быть послан до любого outputа.

[vladon]

ну ты зря так. про ненужность закрывающего ?> я даже не знал.

[chx]

в основном не любят те, кто не знает, что это такое.

[logan]

я добавил плюс. Статья отличная, спасибо. Оценил как начинающий прграммер. )

[Oleksandr]

Присоединяюсь как такой же! :)

[rimmer333]

Эх, была б сила - поплюсовал бы, понравилось.

[beshenov]

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

[akral]

Могу согласиться. Наверное кнопки back на панели хватает.

[beshenov]

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

[Zacariya]

Мне тоже понравился топик, жаль плюснуть не могу

[korchasa]

Как вы объясните следующее:

$handle = fopen('/tmp/bar.php','w+');

fwrite($handle, "';
require_once('../../tmp/bar.php');

echo microtime(1) - $t2;

Apache/2.2.3 (Ubuntu) PHP/5.2.1 Server. Вывод:
0.753756999969
0.00010085105896

[xa4a]

Имхо, странный кусок кода. Строка с fwrite подозрительная ( ")" , "'" ) .Что есть $t2? почему выведено 2 строки, хотя одна инструкция echo. Вы что-то скрываете.

[korchasa]

Пример поломался из-за максимальной длины. Полностью тут. PHP делает realpath.

Тот кто верит непроверенным предупреждениям, вооружен не тем, чем надо :)

[xa4a]

Запустил у себя пример, получил следующее:
Fatal error: Allowed memory size of 83886080 bytes exhausted (tried to allocate 79691776 bytes) in /tmp/bar.php on line 65538
PHP 5.2.2-pl1-gentoo

[korchasa]

Пропиши меньшее количество итераций в цикле добавления строк.

[xa4a]

Ок, тоогда, простите, ваш результат отнюдь не показателен. Запустив у себя ваш скрипт с кол-вом итераций 50к - получил результат:
0.463347911835
0.000643014907837
После этого в скрипте поменял строки
require_once('/tmp/bar.php');
и
require_once('../../tmp/bar.php');
местами. Следуя вашим рассуждениям, получаемы числа должны были поменяться местами. Но мы запускаем скрипт и получаем:
0.655269861221
0.000645160675049
Так что, как выше сказал, результат не показателен

[korchasa]

Поменяться? С чего бы? То, что вторая величина очень мала говорить о том, что код береться из opcode.

[xa4a]

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

[akral]

Пост указывал, что require_once понимает, что файл один и тот-же, хоть он «/tmp/bar.php» хоть «/tmp/../tmp/bar.php».

Поскольку второй require_once нисколько не занимает времени, значит он не инклюдит всё же.

[xa4a]

Ок, спасибо. Благодарю за разъяснение.
Прошу прощения за разведение сего треда.

[akral]

Ой, простите, в output buffer. Это ненужное осложнение. :)

[akral]

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

Хотя я ценю культуру программирования, но я всегда подхожу к этому разумно.
Например, переход с
function foo() {
}
на
functio nfoo()
{
}
мне дался очень сложно, потому что я никак не могу уловить смысла новой строки тут.

Так и здесь. Не могли бы вы аргументировать смысл закрывыющего тэга?

[Arhivator]

я наоборот перешел с первого на второй вариант... и теперь не могу понять как я года 2 назад писал используя второй...

[rumkin]

;) А у меня третий

function foo() {
   echo "Превед, кросавчег!"
   ...
   }
function foo() {
   echo "Превед, медвед!"
   ...
   }


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

[Arhivator]

если уже речь о отступах тогда
function foo() {
...
}
..пробелы обрезаются

[Arhivator]

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

[akral]

1) А как отсутствие тага ?> мешает валидности XML? Валидность XML проверяется после конца работа PHP.

2) Речь идёт о ?> в конце файла.

[akral]

1) Не просвещён в этой сфере. Но если так, то скажите, как вы будете XMLом парсить файл "<?php echo '?><foo><?php'; ?>
Не будет ли он говорить, что тэг <foo> не закрыт?

2) Если есть последний блок инструкций, лежащий в конце файла, то может быть и ?>, лежащий в конце файла.


Кстати, ни <? ни <?= (в вашем примере чуть выше) употребляться в PHP не должны.

[akral]

1) Если я правильно понимаю, то этот код вначале парсит PHP, а результат (такой:

<?xml version='1.0' encoding='windows-1251'?>
<xml>
<foo>TEST</foo>
</xml>

) отдаётся XML парсеру. XML парсер вообще не получает PHP тагов.

2) Вот. Вот это серьёзный аргумент, первый из всех комментариев тут. Тогда да, те кто практикуют подобное должны иметь это ввиду.

3) Ну да, простите. Те таги могут использоваться на своих development серверах. Но смысла немного. :(

[akral]

1) А как тогда XSLT парсит такой код:

<?xml version='1.0' encoding='windows-1251'?>

<xml>

	<foo>

		<?php

		echo '?><foo><?php'

		?>

	</foo>

</xml>

Он что, умеет PHP таги выделять и парсить PHP код?

[akral]

А. Ну да.

/me confused.

Мне надо бы углубиться в познание XSLT и тогда пытаться оценить. Серьёзно. :(

[DEL]

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

[akral]

?> применять нужно. Хотябы из-за того, что это стандартный формат.

Не могли бы вы поподробнее? Я не придираюсь, просто интересуюсь.

[DEL]

Хотябы так объясню: "способ, <?php. . .?>, наиболее предпочтительный, так как он позволяет использовать PHP в коде, соответствующем правилам XML, таком как XHTML.".
А вот и ссылка

[akral]

Во первых, это говорится при сравнении с методами «<script language="php">/<%». Чуть ниже сказано «закрывающий тег PHP-блока в конце файла не является обязательным.»

Во вторых, смысл сравнения с XML мне здесь никак не понятен. Почему я не могу использовать «<script language="php">/<%» по правилам XML? Кстати, английская версия этим непонятным сравнением не страдает.

[DEL]

Если вы хотите проанализировать файл xml-парсером, то нужна валидность.

[akral]

PHP файл?
А зачем вы его будете парсить xml-парсером?
А что вы будете делать с таким файлом:
<?php

echo '?>';

?>

[DEL]

Вы не знали что куски PHP можно вставлять в XML-код?

[akral]

И?
...
Речь идёт о ?> в конце файла.

[DEL]

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

[vitaminych]

"For files that contain only PHP code, the closing tag ("?>") is never permitted"

[akral]

Супер, спасибо!

[DEL]

Да-да понял. Но культуру программирования и красоту кода никто не отменял, а они портятся.

[DEL]

Так что минусы зря) Конечно красиво писать не навяжешь, но стремится к этому нужно.

[akral]

Ну, красота кода — вещь очень субъективная. :)

[DEL]

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

[akral]

Когда речь идёт о XML, то да.
И вообще я страдал таким «закрывательством» раньше. Даже в HTML, пока не понимал, что это такое.

[DEL]

Если я всегда закрываю теги, значит я не понимаю что это такое. Объясните мне что я не понимаю.

[akral]

Закрывать тег «br», например, в HTML (не XHTML!) таким вот образом — <br /> — это неправильно. Парсится это браузером, как таг BR с аттрибутом «/», которого браузер не знает.
Так же парсится этот таг и в «XHTML», переданном как text/html.

Если же <br /> использован в XHTML, переданном как application/xhtml+xml или application/xml, то всё в порядке. Правда IE такой тип не понимает. :)

[MikeOzornin]

На практике же «/» браузеры хавают. Однако согласно стандарту HTML — вы безусловно правы.

[xa4a]

По-моему, то, как броузер воспринимает
, напрямую зависит от DTD записанного в заголовке?
и вопрос: "Закрывать тег «br», например, в HTML (не XHTML!) таким вот образом —
— это неправильно." - а как "правильно"?

[akral]

Закрывать тег «br» в HMTL просто не надо.

DTD это так... На самом деле далеко не самое важное. Валидатор у w3 приучен к ним, чтобы люди их ставили, однако браузер не принимает XHTML как XHTML, если его тип — text/html. Суровая правда жизни.

Вообще, XHTML переданный как text/html парсится как HTML, к которому кто-то с бодуна приписал кучу «/».

[xa4a]

А вот представьте, в один прекрасные день IE решит парсить документ в соответствии с DTD, который указан в вашем XHTML документе. Думаю, он не будет приветствовать невалидный xml в документе. Конечно, я иронизирую, но все-же ведь некоторые броузеры не игнорируют DTD, так почему бы не писать валидный xml, если уже решили называть ваши документы - xhtml?

[akral]

Да потому что IE будет лохом в очередной раз.

w3 сказал, что всё, что передано с типом text/html — HTML, а XHTML не должен быть передан типом text/html (с одним корявым исключением).

Так что надо просто определиться — пишу ли я HTML или XHTML. В первом случае передавать с text/html и не закрывать BR, во втором — application/xhtml+xml и закрывать.

[Xeor]

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

[FaStY]

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

[DEL]

Как раз это самое спорное в статье.

[leemuar]

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

[diamant]

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

[DEL]

Про кавычки потому, что \n - символ переноса строки, можно вводить только в кавычках "", одинарные не понимают управляющие символы и переменные.

Про "?>" крайне спорно, не советую.

[Bright]

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

[akral]

Оппа! Поймал! Спасибо!
Как начинающему мне очень важна ваша поддержка.

[Siddthartha]

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

[xstb]

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

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

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

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

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

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

[bolk]

Вы ошибаетесь, запятая, конечно же, используется. А вот define перевода строки, на мой взгляд, сомнительная хрень. Тем более, что в PHP есть константа PHP_EOL.

[cloud]

За PHP_EOL спасибо

[akral]

PHP_EOL для меня новость. Спасибо.

[DEL]

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

Про использование ">?". Для меня человека, программирующего на Java-е и любящий этот язык это дикость. Есть открытие тега - будте добры вставить закрытие, это практика программирования.

define('N',"\n"); echo 'foo' . N;
Конечно не ахти, но ничего страшного нету.

[DEL]

Смысл тега HTML или XML или открывающей { или ( или

[DEL]

?>

[akral]

Да. Необходимость использования <php в каждом файле и впрям указывает на ущербность языка. =7

[smart]

Про кавычки я ниже написал - в откомпилированном байт-коде нет разницы между "foo" и 'foo', а если уж экономить на работе парсера - так глобально, чтобы убрать ее совсем.

[smart]

Ух ты блин, как тут комменты расколбасило. Я ж не к этому комменту ответ оставлял, а к тому что выше.

[bolk]

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

[akral]

Закрывающий таг HEREDOCа должен стоят в начале линии. А это портит индентацию (выравнивание табами).

Не могли бы вы поподробнее о flock? Я тут слаб, а функция с php.net.

[bolk]

А что именно интересует в flock? Или решительно ничего не понятно?

[smart]

В распространенных ОС (freebsd, linux) блокировки файлов лишь рекомендательные - то есть наспех дописанный скрипт, в котором забыли проверить блокировку, сможет параллельно писать в этот файл.

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

[bolk]

Рекомендательные или нет, но стоит забыть блокировку — здравствуйте, проблемы! Кстати, под Windows rename не умеет перезаписывать файлы.

[smart]

Если Вы внимательно прочтете мой коммент, то поймете, что я про это и написал. И предложил альтернативный способ работы с файлами, который позволяет некоторых проблем избежать.

А rename под windows нормально перезаписывает файлы - только что специально проверил.

[bolk]

Да, действительно, написали вы именно это, прошу прощения.

В коментариях к функции rename можно встретить упоминания того, о чём я говорил: http://www.php.net/rename

возможно, сейчас этот недостаток устранили.

[smart]

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

[bolk]

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

[TDionis]

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

[bolk]

Я использую print исключительно в конструкциях вида

return $echo_content ? print $content : false;

что-то типа такого, т.е. там где удобно вернуть true и напечатать что-то.

[korchasa]

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

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

[akral]

Спасибо, разумеется warning.

[mocksoul]

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

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

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

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

[mastikhin]

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

[kostin]

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

[1mdm]

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

«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…

[akral]

Спасибо, добавлю.

[Sashko]

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

[akral]

Спасибо!
Обещаю, будет продолжение.

[smart]

5000 глобально видимых функций - это уж кто как пишет. Насколько я понимаю, на php вполне можно строить архитектуру кода в соответствие с ООП - методы классов же не глобальны. Или я ошибаюсь?

[smart]

Елки, вот это ужас! :-o Да, об этом я как-то не задумывался...

[long]

может глубокоуважаемый объяснит мне почму это у меня не работает одна из "5000 глобально видимых функций" - например memcache_add? ай-яй, может потому что у меня НЕ УСТАНОВЛЕН модуль и мне НЕ ДОСТУПНЫ все функции данного модуля???

[smart]

Да это понятно, но все равно неприятно, что все в одно пространство имен валится :(

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

[long]

один простой вопрос - сколько денег принесет компании разделение "пространства имен"? :)

[smart]

Это смотря чем компания занимается ;)

[long]

а это действительно важно? если важно - выбирайте на свой вкус.

[akral]

Ну пожалуйста, только без холиваров.

Модулями называют подключаемые PHP файлы, имеющие некоторую функциональность. Грубо говоря, модули album, admin, guestbook.

[akral]

Кстати, спасибо за плюсики. ^_^

[smart]

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

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

[akral]

Очень хорошее замечание. :)

[smart]

Ага, по вопросам highload - обращайтесь ;)

[Patrick]

БРЕД!!!!

[akral]

Критика — это хорошо, но можно поконструктивнее?

[Patrick]

Подобную инфу можно прочитать влюбой книге по php + есть же ман, там всё написанно!

[xa4a]

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

[akral]

Видите ли, это называется «tips and tricks». Вещи, о которых не знаешь, что должен их искать. Вы ведь не читаете ман как худ. литературу, а только то, что необходимо в данный момент, правда?

[Isigosor]

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

[akral]

Большое спасибо! Буду писать ещё.

[akral]

И каково же опровержение?
require_once «slow» в смешных пределах. Он же не будет использоваться в циклах.
А экономия на этом, по сравнению с подгрузкой всех библиотек на всякий случай, я думаю, очевидна.

[korchasa]

Набросал тест, разницы не заметил.
В предложенном вами запросе тоже нет конкретных цифр, кроме багов в начале 5-ой ветки.

[jiexaspb]

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

[akral]

Так ведь ни редактировать ни стирать комменты не получается. :(
А как отрепортить админам?

[jiexaspb]

Незнаю - сам новенький :)

[Nail]

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

[dime]

Ой, это кто вам такое сказал? Нет, конечно. Если поставите, то будет, если не поставите, то не будет.

[Nail]

Я сам проверял, побайтово. Повторить можно так: создайте два php-файла, один с \n в конце, другой - без \n. Размер второго будет на 1 байт короче. Скачайте их wget'ом с веб-сервера. Размер результатов будет одинаковым.
\n в конце файла переводится в пустое месте.
\n\n переводится в \n

[null]

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

[MpaK]

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

[alexrush]

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

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

[Partizan]

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

[akral]

Результаты теста:

Sample Results
0.0231628418 *heredoc_no_vars
0.0031390190 *accum_sq_no_vars
0.0030751228 *accum_dq_no_vars
0.0028319359 *concat_sq_no_vars
0.0027120113 *concat_dq_no_vars

Можем попробовать свои тесты.

[Partizan]

Возможно, не тестировал присвоение значений, только вывод. Будет желание, попробую.
Давно для себя сделал выводы:

1. одиночные кавычки для большинства строк
2. контеканация быстрее внедрения в строку
3. для вывода использовать echo c запятыми, разбивать длинные конструкции на несколько операторов echo
4. использовать ВСЕ остальные способы там, где это удобно и уместно

Честно говоря, рассматривать использование различных кавычек, способов получения и вывода строк с точки зрения производительности смешно. Это имеет смысл только в контексте стандарта кодирования. В чем я солидарен с Zend`ом

[Melnaron]

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

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

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

[ZorroGFS]

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

[klyavin]

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

[mcaiZer]

• Выносим переменные из текстовых строк — ускорение 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…

[romy4]

ещё одно большое отличие 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");

[akral]

Ого!
Интересно. Правда, мне не очень нравится такое применение, но как способ это интересно.

[romy4]

ошибочка, вторая строчка кода должна быть
$variable = include("path/to/file.php");

[etc]

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

[AGvin]

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

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

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

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

[wakh]

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

[akral]

Этому топику свыше четырёх лет. :)

[wakh]

Что не мешает ему отлично гуглится ;)
Мне 32, но я с неделю назад взялся за ПХП, прочёл с удовольствием, а прилипший заголовок сначала ввёл в замешательство.

[wakh]

Оффтоп, есть книги которым века, но люди их читают, может и ваш труд будет полезен столько же или пока ПХП не умрёт? ))