Мир php моими глазами

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

С чего начать? С больших или с маленьких задач?

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

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

Например, пришел проект написанный фиг знает на чем, фиг знает кем и когда. Что внутри - непонятно. Делаем мелкий таск - изменение надписи. Дело пятиминутное - тупо прогнать поиск по коду (и базе если по коду не найдется) по этому слову - и поменять его. Задачу сделали - и уже кое-чему научились, например, как устроена система локализации, есть ли она вообще. Какие шаблоны есть в коде. Т.е. решение мелкой задачи помогло попутно разобраться с проектом и узнать что-то о нем, без того чтобы специально колупать его и смотреть что там и где. И так далее - от мелкого к крупному.

Такой подход позволяет убить сразу 2-х зайцев:

1. Тратится минимум времени на изучение архитектуры проекта;
2. Всегда можно показать заказчику, что работа над проектом идет. Ему не придется месяц трястись и трахать мозг менеджеру, ожидая выполнения самой большой задачи.

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

Есть у меня товарищ, который кодит на c++. И как-то в его коде в цикле я заметил, что он пишет не i++; а ++i; - оказалось что так производительнее (ну они сишники вообще помешаны на этом всем). Почему лушче писать так, я как-то поленился разобраться, но пример я естесственно запомнил - и старался по мере сил писать такое же и в php, хуже ведь не будет все равно. Оказалось недавно, что и у нас это тоже оправдано.

Оказывается:

При использовании инструкции $count++ увеличение переменной $count выполняется после того, как будет рассчитано выражение с использованием данной переменной. Например, $i =$count++; — переменной $i будет присвоено значение переменной $count до того, как последнее будет увеличено на единицу. Это означает, что машина должна сохранить значение $count, чтобы использовать его в любом выражении с переменной $count. В инструкции же ++$count значение переменной увеличивается на единицу до вычислений, поэтому нет необходимости хранить временное значение (а это менее накладно). Если инструкция $count++ применяется в выражении, где значение переменной не используется (это называется пустым контекстом), то ее можно безопасно преобразовать в преинкрементную инструкцию.

Конечно, фигня там получается, а не оптимизация, но зато в таком коде сразу видна рука мастера

$res = mysql_query("select articles.title, articles.text, articles.id, articles.user_id, users.name from articles left join users on articles.user_id=users.id where $condition order by id desc limit 5, 10");

Такой жестяк часто встретишь, когда пишут код студенты или просто люди торопятся да так что ппц. Нифига не понятно. Запрос написан в стиле write-only. В противовес индусам - нормальные программисты используют определенные правила форматирования кода в запросах. И хоть каждый использует свои, как правило они очень похожи.

(далее…)

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

<a href="#" onclick="return someScript(this);" >Ссылка</a>

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

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

<div id="aaa">дивка</div>

и есть ссылка:

<a href="#aaa">ссылка</a>

то по клику на ссылку - произойдет прокрутка к блоку div.

Если же указано просто href="#", то почему-то, браузеры считают что нужно сделать прокрутку в самое начало страницы.

Помнится, я долго бился с этой проблемой - и таки нашел альтернативу:

<a href="javascript: ;">ссылка</a>

По клику - никуда он не переходит и никуда ничего не прокручивает :)

В php есть замечательные предопределенные константы - DIRECTORY_SEPARATOR и PATH_SEPARATOR. Нужны они для того, чтобы скрыть различия в путях между линуксом и виндой. И хоть эти вещи для многих очевидны - всегда найдется парень, который про это не в курсе и натворит бед. Так вот, чтобы отделять директории, нужно юзать DIRECTORY_SEPARATOR - ну, например 'images' . DIRECTORY_SEPARATOR . 'upload' . Да-да, я знаю, все и так используют символ '/' для разделения путей, потому что это работает и в винде, где он не родной, и в линухе. Можно сказать, что константа DIRECTORY_SEPARATOR в принципе нафиг не нужна, если юзать '/' вместо '\' , но это правильно и создает уверенность что все будет зашибись, где бы это не запустилось.

А вот про вторую константу PATH_SEPARATOR мало кто знает :) а все потому что include_path (в частности set_include_path() ) очень редко где используется. Я бы и сам никогда не узнал про это и не наступил бы на некоторые грабли, если бы не Zend Framework, который установить нестандартно без переопределения include_path очень тяжело.

Итак, include_path - настройка, которую можно переопределять в скриптах. Работает это так - когда делается require 'somefile.php';  - интерпретатор вначале ищет файл в той же папке, что и запускаемый скрипт, если не находит, он начинает искать этот же файл в других папках, указанных в include_path. Штука полезная, однако есть подводный камень - include_path - это строка, папки разделены разделителем - причем в винде это ';' а в линухе':'. Тут-то нам и нужна эта константа, которая позволит скриптам запускаться и там и там без лишних конфигов или изменений кода.

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

(далее…)

Для опытных прогеров это уже еще тот баян, но очень хочется верить, что этот пост (или аналогичный где-нить в другом месте) прочитает человек, чей код мне придется когда-нибудь сопровождать :)) Это как "Ложки нет" в матрице - мегаоткровение жизни:

Закрывающий тег ?> в php-файлах не обязательный

(далее…)