Comments 181
Не пишу на php, но оформление статьи вызывает уважение.
+19
Спасибо.
Мой первый хабратопик. А кто-то уже успел его поминусовать. :(
Мой первый хабратопик. А кто-то уже успел его поминусовать. :(
+6
ну, мало кто любит похапе )
0
Ну спасибо, обрадовал. =7
^_^
^_^
+1
Не поэтому минусуют думаю, ценность статьи совсем сомнительная, точнее кто пишет на пхп, ничего хоть слегка нового не обнаружат. Оформление правда стоит увжения, плюсую за старания.
+1
Во первых, в начале я перестраховался, сказав что это для «начинающим и немного продвинутым».
Но вот дело в том, что многие опытные программисты не знают таких простых вещей, как ненужность ?>
Но вот дело в том, что многие опытные программисты не знают таких простых вещей, как ненужность ?>
+1
Осторожней насчет ненужности, пробелы появившиеся - это из области фантастики честно говоря) чтоб такое на практике могло вылезти - надо постараться. А вот некультурность программирования на лицо из-за этого.
+4
У вас нет пустых строк в файлах? Вы бы проверили, а то частенько всплывают. Причем у всех. Никого же не коробит писать, и что некультурного в незакрывании?
0
Да, у меня нет пустых строк в файлах после закрывающих ?>. И ни разу за 7 лет программирования причинами ошибок не становились пробелы после закрывающего ?>.
Вопрос "что некультурного в незакрывании?" считаю провокационным и заданным непрофессионалом.
Вопрос "что некультурного в незакрывании?" считаю провокационным и заданным непрофессионалом.
+2
Культура приходящее, а профессионал должен сомневаться всегда и во всем, на то он и профессионал. И выбирать методики, технологии и подходы тщательно взвесив все плюсы и минусы.
И если не писать "лапшу", то удобнее опускать ?> , т.к. пустые строки не ломают вывод. В случае же перемешивания разметки и кода тэг действительно необходим. Просто "лапшой" пишет меньшинство(я надеюсь), поэтому не стоит тыкать в технологию не дающую для большинства никаких плюсов, но порождающую минусы. А уж тем более возводить ее в ранг культуры.
И если не писать "лапшу", то удобнее опускать ?> , т.к. пустые строки не ломают вывод. В случае же перемешивания разметки и кода тэг действительно необходим. Просто "лапшой" пишет меньшинство(я надеюсь), поэтому не стоит тыкать в технологию не дающую для большинства никаких плюсов, но порождающую минусы. А уж тем более возводить ее в ранг культуры.
-3
Прошу меня простить, но никакого удовольствия и смысла в дальнейшей дискуссии с Вами я не вижу. Желаю удачи.
0
Культура - это закрытие блоков для повышения читаемости кода. Так как большинство программистов все-таки закрывают блоки интерпретации, отождествляя их с блоками кода, отсутствие в чужих скриптах "?>" вызывает некоторое замешательство.
Описанная же Вами ситуация имеет место, но такой способ ее решения - грязный хак, распространяющийся только на созданные Вами файлы. Правильное же решение, учитывающее возможность возникновения ошибки в скриптах сторонних разработчиков (Например, плагинов CMS) - управление выводом.
Описанная же Вами ситуация имеет место, но такой способ ее решения - грязный хак, распространяющийся только на созданные Вами файлы. Правильное же решение, учитывающее возможность возникновения ошибки в скриптах сторонних разработчиков (Например, плагинов CMS) - управление выводом.
+3
Я ознакомлен с этими правилами и объяснил, почему не принимаю их, а вот Вам бы еще поучиться уважению к собеседникам.
0
Простите, если это вам показалось обидным.
Я хотел подчеркнуть, что это вряд ли хак, если такое серьёзное общество приняло такое правило. Скорее это просто стиль, так принято у них, так не принято у вас.
И кстати, я не вижу, как повышается читаемость кода из-за доболнительной команды в конце файла.
Я хотел подчеркнуть, что это вряд ли хак, если такое серьёзное общество приняло такое правило. Скорее это просто стиль, так принято у них, так не принято у вас.
И кстати, я не вижу, как повышается читаемость кода из-за доболнительной команды в конце файла.
+1
Читаемость повышается когда код привычно оформлен - как я уже писал, отсутствие закрывающего тега непривычно для большинства программистов - лично я бы при встрече с "незакрытым" скриптом дважды перепроверил бы, а полностью ли я его скачал - может, он побился при загрузке? А будь блок закрыт - не было бы таких сомнений.
Хаком я назвал это вполне осознанно, так как при наличии более совместимого решения проблемы с заголовками, не имеет смысла ограничивать программистов в стиле.
Кроме того, это очень похоже на некий переходный этап, по прохождении которого сам смысл блоков поменяется на противоположный - следуя нужде разделения шаблонов и кода, "упаковка" неинтерпретируемых частей внутри интерпретируемого с самого начала скрипта становится вполне логичной.
Хаком я назвал это вполне осознанно, так как при наличии более совместимого решения проблемы с заголовками, не имеет смысла ограничивать программистов в стиле.
Кроме того, это очень похоже на некий переходный этап, по прохождении которого сам смысл блоков поменяется на противоположный - следуя нужде разделения шаблонов и кода, "упаковка" неинтерпретируемых частей внутри интерпретируемого с самого начала скрипта становится вполне логичной.
0
UFO just landed and posted this here
ненужность ?> под большим сомнением, а вот разница между echo и print интересна. Или между require и include.
0
А что там с http-заголовками и ?>, как это влияет на результат?
0
ну ты зря так. про ненужность закрывающего ?> я даже не знал.
0
в основном не любят те, кто не знает, что это такое.
0
я добавил плюс. Статья отличная, спасибо. Оценил как начинающий прграммер. )
0
Эх, была б сила - поплюсовал бы, понравилось.
0
Ссылки «наверх» не нужны.
0
Мне тоже понравился топик, жаль плюснуть не могу
-3
UFO just landed and posted this here
Как вы объясните следующее:
Apache/2.2.3 (Ubuntu) PHP/5.2.1 Server. Вывод:
0.753756999969
0.00010085105896
$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
0
Имхо, странный кусок кода. Строка с fwrite подозрительная ( ")" , "'" ) .Что есть $t2? почему выведено 2 строки, хотя одна инструкция echo. Вы что-то скрываете.
0
Запустил у себя пример, получил следующее:
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
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
0
Пропиши меньшее количество итераций в цикле добавления строк.
0
Ок, тоогда, простите, ваш результат отнюдь не показателен. Запустив у себя ваш скрипт с кол-вом итераций 50к - получил результат:
0.463347911835
0.000643014907837
После этого в скрипте поменял строки
require_once('/tmp/bar.php');
и
require_once('../../tmp/bar.php');
местами. Следуя вашим рассуждениям, получаемы числа должны были поменяться местами. Но мы запускаем скрипт и получаем:
0.655269861221
0.000645160675049
Так что, как выше сказал, результат не показателен
0.463347911835
0.000643014907837
После этого в скрипте поменял строки
require_once('/tmp/bar.php');
и
require_once('../../tmp/bar.php');
местами. Следуя вашим рассуждениям, получаемы числа должны были поменяться местами. Но мы запускаем скрипт и получаем:
0.655269861221
0.000645160675049
Так что, как выше сказал, результат не показателен
0
Поменяться? С чего бы? То, что вторая величина очень мала говорить о том, что код береться из opcode.
0
UFO just landed and posted this here
UFO just landed and posted this here
Ой, простите, в output buffer. Это ненужное осложнение. :)
0
UFO just landed and posted this here
В трёх местах обсуждения этого топика мне указано на то, что закрывающий таг нужен.
Хотя я ценю культуру программирования, но я всегда подхожу к этому разумно.
Например, переход с
на
мне дался очень сложно, потому что я никак не могу уловить смысла новой строки тут.
Так и здесь. Не могли бы вы аргументировать смысл закрывыющего тэга?
Хотя я ценю культуру программирования, но я всегда подхожу к этому разумно.
Например, переход с
function foo() {
}
на
functio nfoo()
{
}
мне дался очень сложно, потому что я никак не могу уловить смысла новой строки тут.
Так и здесь. Не могли бы вы аргументировать смысл закрывыющего тэга?
0
я наоборот перешел с первого на второй вариант... и теперь не могу понять как я года 2 назад писал используя второй...
+2
UFO just landed and posted this here
1) А как отсутствие тага ?> мешает валидности XML? Валидность XML проверяется после конца работа PHP.
2) Речь идёт о ?> в конце файла.
2) Речь идёт о ?> в конце файла.
0
UFO just landed and posted this here
1) Не просвещён в этой сфере. Но если так, то скажите, как вы будете XMLом парсить файл "<?php echo '?><foo><?php'; ?>
Не будет ли он говорить, что тэг <foo> не закрыт?
2) Если есть последний блок инструкций, лежащий в конце файла, то может быть и ?>, лежащий в конце файла.
Кстати, ни <? ни <?= (в вашем примере чуть выше) употребляться в PHP не должны.
Не будет ли он говорить, что тэг <foo> не закрыт?
2) Если есть последний блок инструкций, лежащий в конце файла, то может быть и ?>, лежащий в конце файла.
Кстати, ни <? ни <?= (в вашем примере чуть выше) употребляться в PHP не должны.
0
UFO just landed and posted this here
1) Если я правильно понимаю, то этот код вначале парсит PHP, а результат (такой:
) отдаётся XML парсеру. XML парсер вообще не получает PHP тагов.
2) Вот. Вот это серьёзный аргумент, первый из всех комментариев тут. Тогда да, те кто практикуют подобное должны иметь это ввиду.
3) Ну да, простите. Те таги могут использоваться на своих development серверах. Но смысла немного. :(
<?xml version='1.0' encoding='windows-1251'?>
<xml>
<foo>TEST</foo>
</xml>
) отдаётся XML парсеру. XML парсер вообще не получает PHP тагов.
2) Вот. Вот это серьёзный аргумент, первый из всех комментариев тут. Тогда да, те кто практикуют подобное должны иметь это ввиду.
3) Ну да, простите. Те таги могут использоваться на своих development серверах. Но смысла немного. :(
0
UFO just landed and posted this here
1) А как тогда XSLT парсит такой код:
Он что, умеет PHP таги выделять и парсить PHP код?
<?xml version='1.0' encoding='windows-1251'?>
<xml>
<foo>
<?php
echo '?><foo><?php'
?>
</foo>
</xml>
Он что, умеет PHP таги выделять и парсить PHP код?
0
Со всем согласен, видел не раз, кроме ?> применять нужно. Хотябы из-за того, что это стандартный формат. А на счет пробелов в конце - хороший редактор позаботится о них сам.
0
?> применять нужно. Хотябы из-за того, что это стандартный формат.
Не могли бы вы поподробнее? Я не придираюсь, просто интересуюсь.
0
Во первых, это говорится при сравнении с методами «<script language="php">/<%». Чуть ниже сказано «закрывающий тег PHP-блока в конце файла не является обязательным.»
Во вторых, смысл сравнения с XML мне здесь никак не понятен. Почему я не могу использовать «<script language="php">/<%» по правилам XML? Кстати, английская версия этим непонятным сравнением не страдает.
Во вторых, смысл сравнения с XML мне здесь никак не понятен. Почему я не могу использовать «<script language="php">/<%» по правилам XML? Кстати, английская версия этим непонятным сравнением не страдает.
0
Супер, спасибо!
0
Да-да понял. Но культуру программирования и красоту кода никто не отменял, а они портятся.
0
Так что минусы зря) Конечно красиво писать не навяжешь, но стремится к этому нужно.
+1
Ну, красота кода — вещь очень субъективная. :)
0
Я не имел ввиду красоту в буквальном понимание. Однако с опытом к вам придет привычка закрывать любой тег, если он открыт.
0
Когда речь идёт о XML, то да.
И вообще я страдал таким «закрывательством» раньше. Даже в HTML, пока не понимал, что это такое.
И вообще я страдал таким «закрывательством» раньше. Даже в HTML, пока не понимал, что это такое.
0
Если я всегда закрываю теги, значит я не понимаю что это такое. Объясните мне что я не понимаю.
0
Закрывать тег «br», например, в HTML (не XHTML!) таким вот образом — <br /> — это неправильно. Парсится это браузером, как таг BR с аттрибутом «/», которого браузер не знает.
Так же парсится этот таг и в «XHTML», переданном как text/html.
Если же <br /> использован в XHTML, переданном как application/xhtml+xml или application/xml, то всё в порядке. Правда IE такой тип не понимает. :)
Так же парсится этот таг и в «XHTML», переданном как text/html.
Если же <br /> использован в XHTML, переданном как application/xhtml+xml или application/xml, то всё в порядке. Правда IE такой тип не понимает. :)
0
На практике же «/» браузеры хавают. Однако согласно стандарту HTML — вы безусловно правы.
0
По-моему, то, как броузер воспринимает
, напрямую зависит от DTD записанного в заголовке?
и вопрос: "Закрывать тег «br», например, в HTML (не XHTML!) таким вот образом —
— это неправильно." - а как "правильно"?
, напрямую зависит от DTD записанного в заголовке?
и вопрос: "Закрывать тег «br», например, в HTML (не XHTML!) таким вот образом —
— это неправильно." - а как "правильно"?
0
Закрывать тег «br» в HMTL просто не надо.
DTD это так... На самом деле далеко не самое важное. Валидатор у w3 приучен к ним, чтобы люди их ставили, однако браузер не принимает XHTML как XHTML, если его тип — text/html. Суровая правда жизни.
Вообще, XHTML переданный как text/html парсится как HTML, к которому кто-то с бодуна приписал кучу «/».
DTD это так... На самом деле далеко не самое важное. Валидатор у w3 приучен к ним, чтобы люди их ставили, однако браузер не принимает XHTML как XHTML, если его тип — text/html. Суровая правда жизни.
Вообще, XHTML переданный как text/html парсится как HTML, к которому кто-то с бодуна приписал кучу «/».
0
А вот представьте, в один прекрасные день IE решит парсить документ в соответствии с DTD, который указан в вашем XHTML документе. Думаю, он не будет приветствовать невалидный xml в документе. Конечно, я иронизирую, но все-же ведь некоторые броузеры не игнорируют DTD, так почему бы не писать валидный xml, если уже решили называть ваши документы - xhtml?
0
Да потому что IE будет лохом в очередной раз.
w3 сказал, что всё, что передано с типом text/html — HTML, а XHTML не должен быть передан типом text/html (с одним корявым исключением).
Так что надо просто определиться — пишу ли я HTML или XHTML. В первом случае передавать с text/html и не закрывать BR, во втором — application/xhtml+xml и закрывать.
w3 сказал, что всё, что передано с типом text/html — HTML, а XHTML не должен быть передан типом text/html (с одним корявым исключением).
Так что надо просто определиться — пишу ли я HTML или XHTML. В первом случае передавать с text/html и не закрывать BR, во втором — application/xhtml+xml и закрывать.
0
Интересный способ борьбы со своими косяками от Zend... Видимо, им дать такую рекомендацию было проще чем добавить в PHP возьможность пропуска пробельных символов между ?> и концом файла.
0
понравилась статейка, особенно про ?>
0
UFO just landed and posted this here
Ценно, спасибки.
0
define('N',"\n") - почему разные кавычки?
спасибо за ?>
спасибо за ?>
0
Понравилось. Хоть я на PHP уже давно не пишу, а PHP5 и в глаза не видел. :)
За оформление статьи - отдельный респект.
Ловите заслуженный карма-плюс =)
За оформление статьи - отдельный респект.
Ловите заслуженный карма-плюс =)
0
отличный кстати топик вышел в сумме с камментами - сразу несколько ньюансов синтаксиса все пережевали для себя...
0
Мой трехлетний опыт программирования на PHP позволяет говорить о следующем:
"Выяснение отношений с кавычками" - сугубо личное представление автора, мало коррелирующее с действительной практикой программирования. Если делать так, как вы предлагаете, код будет менее читабелен. Также следует опасаться эффекта "зубочистки".
На практике запятую при выводе echo практически не используют. Зачастую больший смысл имеет использование конкатенации (оператора точка). Эффект от использования запятой в коде экономия на спичках, не более.
- это очень (совсем!) вредный совет, забудьте об этом.
Про использование ?> в некотором смысле солидарен с автором. Опускать данный маркер имеет смысл лишь в описании классов и в некоторых других (редких) случаях. В типовых ситуациях, например, в окончании шаблонов (и т.п.) опускать маркер конца PHP-кода не нужно, будьте ближе к семантике документа.
"Выяснение отношений с кавычками" - сугубо личное представление автора, мало коррелирующее с действительной практикой программирования. Если делать так, как вы предлагаете, код будет менее читабелен. Также следует опасаться эффекта "зубочистки".
На практике запятую при выводе echo практически не используют. Зачастую больший смысл имеет использование конкатенации (оператора точка). Эффект от использования запятой в коде экономия на спичках, не более.
define('N',"\n"); echo 'foo' . N;
- это очень (совсем!) вредный совет, забудьте об этом.
Про использование ?> в некотором смысле солидарен с автором. Опускать данный маркер имеет смысл лишь в описании классов и в некоторых других (редких) случаях. В типовых ситуациях, например, в окончании шаблонов (и т.п.) опускать маркер конца PHP-кода не нужно, будьте ближе к семантике документа.
0
Вы ошибаетесь, запятая, конечно же, используется. А вот define перевода строки, на мой взгляд, сомнительная хрень. Тем более, что в PHP есть константа PHP_EOL.
0
Мой более 7-ми летний опыт говорит (можно и померятся иногда:)), что, на счет кавычек автор прав. Видел тесты, сам проводил, да и вообще по смыслу предпочтение нужно отдавать одинарным кавычкам, двойные использовать лишь в том случае, когда выводите управляющие символы. Вставлять вывод переменных внутрь строки занятие глупое: намного дольше работает и сложночитаемо.
Про использование ">?". Для меня человека, программирующего на Java-е и любящий этот язык это дикость. Есть открытие тега - будте добры вставить закрытие, это практика программирования.
define('N',"\n"); echo 'foo' . N;
Конечно не ахти, но ничего страшного нету.
Про использование ">?". Для меня человека, программирующего на Java-е и любящий этот язык это дикость. Есть открытие тега - будте добры вставить закрытие, это практика программирования.
define('N',"\n"); echo 'foo' . N;
Конечно не ахти, но ничего страшного нету.
-1
UFO just landed and posted this here
Про кавычки я ниже написал - в откомпилированном байт-коде нет разницы между "foo" и 'foo', а если уж экономить на работе парсера - так глобально, чтобы убрать ее совсем.
0
Я бы сильно поспорил с плохой читаемостью HEREDOC, а в "эмуляции" file_put_contents надо обязательно добавить flock.
0
Закрывающий таг HEREDOCа должен стоят в начале линии. А это портит индентацию (выравнивание табами).
Не могли бы вы поподробнее о flock? Я тут слаб, а функция с php.net.
Не могли бы вы поподробнее о flock? Я тут слаб, а функция с php.net.
0
В распространенных ОС (freebsd, linux) блокировки файлов лишь рекомендательные - то есть наспех дописанный скрипт, в котором забыли проверить блокировку, сможет параллельно писать в этот файл.
Поэтому лучше сначала писать во временный файл со случайным именем (разумеется, открывать его надо с флагом O_EXCL) - а затем переименовывать в нужное имя. Переименование атомарно на подавляющем большинстве систем.
Поэтому лучше сначала писать во временный файл со случайным именем (разумеется, открывать его надо с флагом O_EXCL) - а затем переименовывать в нужное имя. Переименование атомарно на подавляющем большинстве систем.
+1
Рекомендательные или нет, но стоит забыть блокировку — здравствуйте, проблемы! Кстати, под Windows rename не умеет перезаписывать файлы.
0
Если Вы внимательно прочтете мой коммент, то поймете, что я про это и написал. И предложил альтернативный способ работы с файлами, который позволяет некоторых проблем избежать.
А rename под windows нормально перезаписывает файлы - только что специально проверил.
А rename под windows нормально перезаписывает файлы - только что специально проверил.
0
Да, действительно, написали вы именно это, прошу прощения.
В коментариях к функции rename можно встретить упоминания того, о чём я говорил: http://www.php.net/rename
возможно, сейчас этот недостаток устранили.
В коментариях к функции rename можно встретить упоминания того, о чём я говорил: http://www.php.net/rename
возможно, сейчас этот недостаток устранили.
0
+ чтобы пробелы не разрушали данные, нужно пользоваться ob_start, это производительней обычного вывода, так утверждают множество тестов.
0
Про echo и print конечно очень информативно, но мало кто будет переучиваться: кто первый раз писал print и уже тысячу раз использовал print в своих проектах... ради одного символа менять свои привычки не будет точно :)
0
Спасибо за статью, о запятой услышал первый раз, не смотря на 4хлетний опыт :)
Маленькая ошибочка - include выдает E_WARNING, а не E_NOTICE.
Маленькая ошибочка - include выдает E_WARNING, а не E_NOTICE.
0
Моё имхо по поводу статьи:
Очень важный момент - ?> - действительно лучше не использовать в конце файла. Толку от неё - ноль.
echo 'asd' . 'dsa' против echo 'asd', 'dsa' толком никакой разницы не несут. Равно как и echo 'asd' против echo "asd". Выбирать что использовать лучше из общепринятых стандартов - двойные кавычки ТОЛЬКО когда в этом есть смысл (т.е. нужен парсинг переменных внутри и тп). И echo 'asd' . 'dsa' вместо конкантенации параметров запятой. Причём по скорости разницы можно сказать что вообще нет. Задумываться об этом глупо потому что в любой PHP-программе есть 99.99% мест заслуживающих большего внимания ;).
echo или print.. print используется теми кто к нему привык - т.е. пересаживается с Си, например. В php-мире превалирует-таки echo. Это факт.
Очень важный момент - ?> - действительно лучше не использовать в конце файла. Толку от неё - ноль.
echo 'asd' . 'dsa' против echo 'asd', 'dsa' толком никакой разницы не несут. Равно как и echo 'asd' против echo "asd". Выбирать что использовать лучше из общепринятых стандартов - двойные кавычки ТОЛЬКО когда в этом есть смысл (т.е. нужен парсинг переменных внутри и тп). И echo 'asd' . 'dsa' вместо конкантенации параметров запятой. Причём по скорости разницы можно сказать что вообще нет. Задумываться об этом глупо потому что в любой PHP-программе есть 99.99% мест заслуживающих большего внимания ;).
echo или print.. print используется теми кто к нему привык - т.е. пересаживается с Си, например. В php-мире превалирует-таки echo. Это факт.
0
Статья хорошая, автору - зачёт =)
Из комментов подчерпнул PHP_EOL, спасибо bolk'у.
Из комментов подчерпнул PHP_EOL, спасибо bolk'у.
0
Статья полезная и комментарии полезные. Пишите, пожалуйста, еще, думаю, тонкостей в php для этого хватит.
0
Тем, кто ещё не уверен в закрывающем теге ?>, выдержка из официального мануала:
«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…
«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…
0
а я отношусь к "начинающим и немного продвинутым".
Спасибо вам большое за статью. Вы молодец не взирая на всякие там плюсы и минусы.
Спасибо вам большое за статью. Вы молодец не взирая на всякие там плюсы и минусы.
0
UFO just landed and posted this here
5000 глобально видимых функций - это уж кто как пишет. Насколько я понимаю, на php вполне можно строить архитектуру кода в соответствие с ООП - методы классов же не глобальны. Или я ошибаюсь?
0
UFO just landed and posted this here
Елки, вот это ужас! :-o Да, об этом я как-то не задумывался...
0
может глубокоуважаемый объяснит мне почму это у меня не работает одна из "5000 глобально видимых функций" - например memcache_add? ай-яй, может потому что у меня НЕ УСТАНОВЛЕН модуль и мне НЕ ДОСТУПНЫ все функции данного модуля???
0
Да это понятно, но все равно неприятно, что все в одно пространство имен валится :(
Вот в perl при подключении модуля можно импортировать в текущее пространство имен только те функции, которые нужны. Т.е. в аккуратно написанной системе программист сам контролирует, какие имена в каком пространстве имен присутствуют - и это удобно.
Вот в perl при подключении модуля можно импортировать в текущее пространство имен только те функции, которые нужны. Т.е. в аккуратно написанной системе программист сам контролирует, какие имена в каком пространстве имен присутствуют - и это удобно.
0
Ну пожалуйста, только без холиваров.
Модулями называют подключаемые PHP файлы, имеющие некоторую функциональность. Грубо говоря, модули album, admin, guestbook.
Модулями называют подключаемые PHP файлы, имеющие некоторую функциональность. Грубо говоря, модули album, admin, guestbook.
0
Кстати, спасибо за плюсики. ^_^
0
Хорошая статья.
В нескольких местах Вы упоминаете о скорости парсинга кода. Если такой вопрос вообще встает (т.е. сайт становится посещаемым), то первое, что надо сделать - это отказаться от парсинга на каждый запрос. Файл скрипта должен парситься один раз при старте сервера, и дальше лежать в памяти в виде исполняемого байт-кода (для этого есть всякие код-кэши и оптимайзеры). И тогда между, например, 'foo' и "foo" не будет ровно никакой разницы.
В нескольких местах Вы упоминаете о скорости парсинга кода. Если такой вопрос вообще встает (т.е. сайт становится посещаемым), то первое, что надо сделать - это отказаться от парсинга на каждый запрос. Файл скрипта должен парситься один раз при старте сервера, и дальше лежать в памяти в виде исполняемого байт-кода (для этого есть всякие код-кэши и оптимайзеры). И тогда между, например, 'foo' и "foo" не будет ровно никакой разницы.
0
БРЕД!!!!
-2
Критика — это хорошо, но можно поконструктивнее?
0
Подобную инфу можно прочитать влюбой книге по php + есть же ман, там всё написанно!
0
Вам очень повезло, если держите все мелочи из мана в памяти, но ведь есть и начинающие программисты, которые, читая ман, могут и не углубляться в некоторые детали. Такая статья, имхо, довольно полезна для воспитания полезного разработчика
0
Видите ли, это называется «tips and tricks». Вещи, о которых не знаешь, что должен их искать. Вы ведь не читаете ман как худ. литературу, а только то, что необходимо в данный момент, правда?
0
Про это есть статья на любом ресурсе, который хоть как-то относится к php. Но написано бесспорно лучше своих аналогов :)
0
Можно не боясь добавлять require_once
в каждый модуль, где нужна библиотека.
Вы поторопились, уважаемый. Было бы хорошо большими красными буквами дописать опровержение этого тезиса, пока не слишком поздно.
0
Блин, пофиксите не закрытый тег в каком-то комменте, невозможно читать остальные комментарии :(
0
Кстати любой юниксовый текстовый файл заканчивается пустой строкой, то есть содержит в конце символ перевода строки.
PHP обучен игнорировать пустую строку в конце файла после ?>
PHP обучен игнорировать пустую строку в конце файла после ?>
0
Ой, это кто вам такое сказал? Нет, конечно. Если поставите, то будет, если не поставите, то не будет.
0
Кто сломал хабр? =(
Статейка понравилась :)
Заплюсовал и повысил карму. Пиши еще =)
Статейка понравилась :)
Заплюсовал и повысил карму. Пиши еще =)
+1
ничего нового не узнал из статьи, а экономия на спичках это бред
+1
отличный материал. Продолжай.
вот только насчет
я не согласен. С детства к "\n" привык :))
вот только насчет
define('N',PHP_EOL); echo 'foo' . N; читабельнее чем echo "foo\n";
я не согласен. С детства к "\n" привык :))
0
То, что "HEREDOC в десять раз медленее своих коллег", это явное преувеличение. Max на 10-15% и то, если внедрять переменные. Сам когда-то тестировал.
А если нужно, например для тестирования, быстро в переменную положить всю html страницу, то альтернатива только чтение из файла.
А если нужно, например для тестирования, быстро в переменную положить всю html страницу, то альтернатива только чтение из файла.
0
Возможно, не тестировал присвоение значений, только вывод. Будет желание, попробую.
Давно для себя сделал выводы:
1. одиночные кавычки для большинства строк
2. контеканация быстрее внедрения в строку
3. для вывода использовать echo c запятыми, разбивать длинные конструкции на несколько операторов echo
4. использовать ВСЕ остальные способы там, где это удобно и уместно
Честно говоря, рассматривать использование различных кавычек, способов получения и вывода строк с точки зрения производительности смешно. Это имеет смысл только в контексте стандарта кодирования. В чем я солидарен с Zend`ом
Давно для себя сделал выводы:
1. одиночные кавычки для большинства строк
2. контеканация быстрее внедрения в строку
3. для вывода использовать echo c запятыми, разбивать длинные конструкции на несколько операторов echo
4. использовать ВСЕ остальные способы там, где это удобно и уместно
Честно говоря, рассматривать использование различных кавычек, способов получения и вывода строк с точки зрения производительности смешно. Это имеет смысл только в контексте стандарта кодирования. В чем я солидарен с Zend`ом
0
UFO just landed and posted this here
Что то комменты совсем сжались в право, давайте ка обратно их сдвинем!
Что хотелось бы добавить:
Культура программирования вещь достаточно своеобразная.
Сколько программистов - столько и культур.
Каждый программист будет программировать так, как только ему наиболее удобно, нет конкретных правил в каком формате писать код, главное чтобы работало. НО! Тогда опускается тот факт, что возможно с кодом будет работать другой человек, и ему будет дико неудобно разбирать "стиль" автора. Тогда что же? Подстраиваться по до всех кодеров? Наверное всетаки нет.
Ктото пишет функции так:
foo {
...
}
а ктото так:
foo { ...; ...; ...; }
(и такое видел)
и если вдруг, по работе, заставят разбирать такой код, мы выругаемся как следует (!) и будем разбиратся в ТАКОМ коде, или же для начала приведем его в удобный для СЕБЯ вид.
Так что имхо, нужно писать так, чтобы было удобно, и без ошибок =)
Что хотелось бы добавить:
Культура программирования вещь достаточно своеобразная.
Сколько программистов - столько и культур.
Каждый программист будет программировать так, как только ему наиболее удобно, нет конкретных правил в каком формате писать код, главное чтобы работало. НО! Тогда опускается тот факт, что возможно с кодом будет работать другой человек, и ему будет дико неудобно разбирать "стиль" автора. Тогда что же? Подстраиваться по до всех кодеров? Наверное всетаки нет.
Ктото пишет функции так:
foo {
...
}
а ктото так:
foo { ...; ...; ...; }
(и такое видел)
и если вдруг, по работе, заставят разбирать такой код, мы выругаемся как следует (!) и будем разбиратся в ТАКОМ коде, или же для начала приведем его в удобный для СЕБЯ вид.
Так что имхо, нужно писать так, чтобы было удобно, и без ошибок =)
0
в любом, маломальски динамичном проекте, где таки нужен пхп, одними эхами дело не обойдётся, а на фоне десятка другого обращений к бд хоть в цикле по буквам выводи, разницы не заметно будет.
0
в принципе, комментарии по делу, хоть расказывается о довольно известных вещах. Хотелось бы видеть продолжение материала )
0
- Выносим переменные из текстовых строк — ускорение 25-40%
- Короткие переменные не более 7 символов — ускорение 15%
- Тормозят ли массивы в PHP? Вернее, как именно — ускорение 40%
- Выносим многомерные массивы из текстовых строк —
ускорение 25-30%
- Регулярные выражения: PHP(POSIX) vs. Perl — ускорение 60-200%
- Циклы: for, foreach, while, count/sizeof() — ускорение 15%-30%
- Для чтения файла file() быстрее, чем fopen+цикл — ускорение 40%
Автор статьи:
![посмотреть профиль посмотреть профиль](https://habrastorage.org/getpro/habr/comment_images/62f/90e/993/62f90e993020da8f10b24d2e0270c78c.gif)
Дата публикации: 26 июня 2007
Ссылка на статью: http://www.habrahabr.ru/blog/webdev/1879…
0
ещё одно большое отличие require от include состоит в том, что include возвращает значение, как функция.
например:
вернёт null, а
может вернуть любое значение, если в файле file.php было сделано return $something;
например, это можно использовать, чтобы инклудить конфигурационные файлы и не зависить от названия переменных
file.php:
<?php
return array("key"=>"value");
например:
$variable = require("path/to/file.php");
вернёт null, а
$variable = require("path/to/file.php");
может вернуть любое значение, если в файле file.php было сделано return $something;
например, это можно использовать, чтобы инклудить конфигурационные файлы и не зависить от названия переменных
file.php:
<?php
return array("key"=>"value");
0
Держи зачет! Отличная статья, даже узнал немного нового, например, про file_put_contents :) А я, неуч, постоянно свою функцию писал :)
0
Незнаю… может кому-то будет полезным функции print_r( ) и var_dump( ), использую ежедневно:
bool print_r (mixed expression [, bool return]);
void var_dump ( mixed expression [, mixed expression [, ...]])
Приятного всем использования. =)
bool print_r (mixed expression [, bool return]);
void var_dump ( mixed expression [, mixed expression [, ...]])
Приятного всем использования. =)
0
Спасибо, некоторые моменты разжевали в лучшем виде!
Однако отбейте заголовки пробелом сверху.
Пример:
«php.net и Zend Framework тоже так <a href=»думают.
require, include, readfile"
слиплись.
Однако отбейте заголовки пробелом сверху.
Пример:
«php.net и Zend Framework тоже так <a href=»думают.
require, include, readfile"
слиплись.
0
Sign up to leave a comment.
Полезные мелочи программирования на PHP