Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
А насколько оно эффективнее чем испектор кода в phpStorm?
phpStorm вы с CI серверу не привяжите.
Пардон за серость, но CI — это что? Дизамбиг в вики длинноватый.
Continuous Integration
Ошибка, обнаруженная ХипХопом — это гарантированно ошибка или просто предупреждение о возможной ошибке? Если первое, то верится с большим трудом (привет eval и иже). Если второе, то теряется смысл, потому что при ложном срабатывании будет или сломанный билд (при суровом подходе), или результат, набитый предупреждениями, на которые всем пофиг (если не сразу пофиг, то рано или поздно будет).
Надо пробовать, автор же писал, что пока ещё мало кто тестировал.
Насколько я помню, к ограничением хипхопа относится запрет на использование евала.
По поводу обнаруженных ошибок — и то и другое. Отсутствующий инклюд — это явная ошибка. Лишний параметр при вызове функции — возможная.
Сломанного билда не будет, поскольку тестирование делается перед коммитом.
Варнингов на [плохом] коде будет много, да. Расмус так и сказал — «кто хочет затроллить багтрекер любого опенсорс проекта, может натравливать анализатор хипхопа и писать тикеты десятками. „
Собственно, чтобы не было много предупреждений — нужно писать чистый код. И начинать тестировать его сразу, а не после того, как написано 100500 строк.
Скажем, во время презентации Расмус нашёл место в Вордпрессе, где в случае ошибки при fopen()… делался fclose()! И это очевидный говнокод.
Собственно, многие забывают, что куча варнингов “на которые всем пофиг» — это не проблема анализатора, это проблема кода.
По поводу обнаруженных ошибок — и то и другое. Отсутствующий инклюд — это явная ошибка. Лишний параметр при вызове функции — возможная.
Сломанного билда не будет, поскольку тестирование делается перед коммитом.
Варнингов на [плохом] коде будет много, да. Расмус так и сказал — «кто хочет затроллить багтрекер любого опенсорс проекта, может натравливать анализатор хипхопа и писать тикеты десятками. „
Собственно, чтобы не было много предупреждений — нужно писать чистый код. И начинать тестировать его сразу, а не после того, как написано 100500 строк.
Скажем, во время презентации Расмус нашёл место в Вордпрессе, где в случае ошибки при fopen()… делался fclose()! И это очевидный говнокод.
Собственно, многие забывают, что куча варнингов “на которые всем пофиг» — это не проблема анализатора, это проблема кода.
Никогда не понимал подход игнорирования варнингов.
Да и вообще, сам факт написания такого кода.
У меня все нотисы/варнинги/ерроры всегда включены (отключаю только на финальной публикации) — и во-первых они вылазят крайне редко по ходу работы, во-вторых я их никогда не пропускаю.
Как же нужно наплевательски относиться к своему коду, что бы пропускать предупреджения?
Да и вообще, сам факт написания такого кода.
У меня все нотисы/варнинги/ерроры всегда включены (отключаю только на финальной публикации) — и во-первых они вылазят крайне редко по ходу работы, во-вторых я их никогда не пропускаю.
Как же нужно наплевательски относиться к своему коду, что бы пропускать предупреджения?
У меня при разработке аналогично:
error_reporting => E_ALL (до PHP 5.4 было Е_ALL | E_STRICT)
xdebug.scream = 1 (отключает подавление ошибок при помощи @)
Да только люди разные: кто-то любит свою работу, кто-то лепит как попало лишь бы работало и от него отстали.
Многое еще зависит от того как на работе поставлен весь процесс разработки.
error_reporting => E_ALL (до PHP 5.4 было Е_ALL | E_STRICT)
xdebug.scream = 1 (отключает подавление ошибок при помощи @)
Да только люди разные: кто-то любит свою работу, кто-то лепит как попало лишь бы работало и от него отстали.
Многое еще зависит от того как на работе поставлен весь процесс разработки.
ну собаку я пользую в некоторых случаях для проверки, сериализована ли строка ( if ($tmp=@unserialize($str)) $str=$tmp; )
к сожалению, другого способа нет, а иногда такие проверки нужны
к сожалению, другого способа нет, а иногда такие проверки нужны
На продакшене display_errors => Off (только в лог) и нет xdebug :)
Что касается вашего примера, есть как минимум один случай, когда он не сработает.
Что касается вашего примера, есть как минимум один случай, когда он не сработает.
Какой?
Если сериализованая строка будет такой «b:0;»
Согласен. Но в тех случаях, в которых я использую такую проверку, такого не бывает)
Есть способ проверки и без собаки, но он завернутый (несколько проверок и регэкспы).
Если будет интересно, напишите в личку, завтра вышлю.
Если будет интересно, напишите в личку, завтра вышлю.
у нас вот такое используют:
function is_serialized($data)
{
// if it isn't a string, it isn't serialized
if (!is_string($data)) return false;
$data = trim($data);
if ('N;' == $data) return true;
if (!preg_match('/^([adObis]):/', $data, $badions)) return false;
switch ($badions[1]) {
case 'a':
case 'O':
case 's':
if (preg_match("/^{$badions[1]}:[0-9]+:.*[;}]\$/s", $data)) return true;
break;
case 'b':
case 'i':
case 'd':
if (preg_match("/^{$badions[1]}:[0-9.E-]+;\$/", $data)) return true;
break;
}
return false;
}Вы допускаете очень распространённую ошибку, о которой я говорил на конференции:
Ставя собаку, РНР программист полагает, что ошибка бывает только одного типа.
Это неверно, и на этом заблуждении было потрачено впустую немало человеко-часов.
Для таких исключительных случаев лучше использовать исключения —
Ставить трай и отлавливать ошибку в кетче.
Ошибку ПРОВЕРЯТЬ, та ли это, которую мы ждём.
Если та — продолжаем выполнение программы.
Если нет — выбрасываем эту же ошибку снова, через trigger_error
Для этого надо переопределять error_handler, разумеется, но это и так везде сделано, мне кажется.
Разумеется, это не слишком красиво, и такой кривизны лучше избегать, меняя логику программы.
Скажем, сама проверка «сериализована ли строка» говорит о непродуманности логики программы. Хорошая программа всегда знает, какого рода данные ожидаются на вход.
Но в любом случае, ставя собаку всегда следует помнить, что ошибки бывают РАЗНЫЕ, а не только те, про которые мы знаем и которые ждём ;)
Ставя собаку, РНР программист полагает, что ошибка бывает только одного типа.
Это неверно, и на этом заблуждении было потрачено впустую немало человеко-часов.
Для таких исключительных случаев лучше использовать исключения —
Ставить трай и отлавливать ошибку в кетче.
Ошибку ПРОВЕРЯТЬ, та ли это, которую мы ждём.
Если та — продолжаем выполнение программы.
Если нет — выбрасываем эту же ошибку снова, через trigger_error
Для этого надо переопределять error_handler, разумеется, но это и так везде сделано, мне кажется.
Разумеется, это не слишком красиво, и такой кривизны лучше избегать, меняя логику программы.
Скажем, сама проверка «сериализована ли строка» говорит о непродуманности логики программы. Хорошая программа всегда знает, какого рода данные ожидаются на вход.
Но в любом случае, ставя собаку всегда следует помнить, что ошибки бывают РАЗНЫЕ, а не только те, про которые мы знаем и которые ждём ;)
Некоторые программы имеют динамическую структуру данных. Ну, бывает такое)
Т.е. данные могут добавляться, меняться, типы данных могут быть разные, методы хранения и т.п.
Да, в идеализированном случае нужно хранить «манифест» (или как там такое по-модному называется), в котором это все будет описано и проверять по нему, но это не всегда целесообразно, т.к. часто приводит к существенным накладным расходам и к приличному усложнению логики. В общем, бывают частные случаи, где такой подход оправдан упрощением программы.
Что касается try/catch — ну да, соглашусь, правильнее это делать через него. Надо себя заставлять))))
Т.е. данные могут добавляться, меняться, типы данных могут быть разные, методы хранения и т.п.
Да, в идеализированном случае нужно хранить «манифест» (или как там такое по-модному называется), в котором это все будет описано и проверять по нему, но это не всегда целесообразно, т.к. часто приводит к существенным накладным расходам и к приличному усложнению логики. В общем, бывают частные случаи, где такой подход оправдан упрощением программы.
Что касается try/catch — ну да, соглашусь, правильнее это делать через него. Надо себя заставлять))))
1. Вы пропустили контекст.
Речь не о предупреждениях РНР, а об «ошибках, обнаруженных ХипХопом».
Я в комментарии ниже приводил слова Расмуса о том, что статический анализатор выполняет в 10 раз больше работы, чем обычный интерпретатор, и ошибки, которые он выдаёт, не отлавливаются обычным PHP. Это получается что-то вроде super-strict mode.
К примеру, Хипхоп отлавливает код, который никогда не выполняется, или передачу функции большего количества параметров, чем было объявлено. PHP на это не обращает внимания, а хипхоп — ругается.
2. Отключая ошибки «на финальной публикации» вы допускаете большую ошибку. На боевом сервере они нужны не меньше, чем на тестовом. Отключен должен быть только вывод на экран, разумеется. А сами «нотисы/варнинги/ерроры» должны быть включены так же как на тестовом — по максимуму, и писаться в лог.
Речь не о предупреждениях РНР, а об «ошибках, обнаруженных ХипХопом».
Я в комментарии ниже приводил слова Расмуса о том, что статический анализатор выполняет в 10 раз больше работы, чем обычный интерпретатор, и ошибки, которые он выдаёт, не отлавливаются обычным PHP. Это получается что-то вроде super-strict mode.
К примеру, Хипхоп отлавливает код, который никогда не выполняется, или передачу функции большего количества параметров, чем было объявлено. PHP на это не обращает внимания, а хипхоп — ругается.
2. Отключая ошибки «на финальной публикации» вы допускаете большую ошибку. На боевом сервере они нужны не меньше, чем на тестовом. Отключен должен быть только вывод на экран, разумеется. А сами «нотисы/варнинги/ерроры» должны быть включены так же как на тестовом — по максимуму, и писаться в лог.
Вы представляете себе процесс непрерывной интеграции?
Похоже, что не представляет.
Подскажите как запустить идею без иксов?
Зачем на сервере иксы?
Стестняюсь спросить, а на production сервера тоже нужно иксы ставить?
Вы серьезно предлагаете вместо выполнения нескольких консольных команд поднимать на сервере иксы, писать плагин для идеи, как-то интегрировать это все с CI, и в итоге запускать для каждого билда «монстра» в виде идеи?
Если да, то вопрос один: ЗАЧЕМ?
Если да, то вопрос один: ЗАЧЕМ?
А зачем мне (да и вообще любому здравомыслящему админу) иксы на сервер CI?
Только ради phpStorma? o_O
Только ради phpStorma? o_O
Схема работы:
1. Коммиты в VCS.
2. На сервере стартовал билд.
3. Запустился Code Analyzer.
4. В случае найденных ошибок в коде билд упал, письма отправились, каждый девелопер при просмотре dashboard проекта видит информацию о ошибках.
Какая схема будет с использованием phpStorm?
1. Коммиты в VCS.
2. На сервере стартовал билд.
3. Запустился Code Analyzer.
4. В случае найденных ошибок в коде билд упал, письма отправились, каждый девелопер при просмотре dashboard проекта видит информацию о ошибках.
Какая схема будет с использованием phpStorm?
Анализ такого уровня любая IDE поддерживает. Без Хип Хопа.
А чем ещё оно может быть интересно?
А чем ещё оно может быть интересно?
Вам следовало сказать, что это имеет смысл только вы транслируете код с помощью HipHop в C++.
Иначе смотрите PHP Mess Detector, PHP_CodeSniffer, PHP Depend
Иначе смотрите PHP Mess Detector, PHP_CodeSniffer, PHP Depend
Вам следовало сказать, что это имеет смысл только вы транслируете код с помощью HipHop в C++.A как вы себе по другому представляете статический анализ?
PHP Mess Detector, PHP_CodeSniffer, PHP Depend — это инструменты из другой оперы.
К тому же PHP_CodeSniffer — проверка форматирования, а не анализ как таковой.
Совершенно верно!
CodeSniffer отличная штука и мы его активно используем на сервере разработки, но я не понимаю, почему он должен конкурировать с программой, которая действительно компилит код PHP, а не просто смотрит на правильность его «текста».
То же относится и к предыдущим комментариям. Все приведённые инструменты прекрасны, но они о другом. Они смотрят просто на код и проверяют его на соответствие набору правил. HipHop делает из него C++ программу и смотрит, работает ли она так, как мы привыкли это видеть при компиляции неинтерпретируемого софта.
CodeSniffer отличная штука и мы его активно используем на сервере разработки, но я не понимаю, почему он должен конкурировать с программой, которая действительно компилит код PHP, а не просто смотрит на правильность его «текста».
То же относится и к предыдущим комментариям. Все приведённые инструменты прекрасны, но они о другом. Они смотрят просто на код и проверяют его на соответствие набору правил. HipHop делает из него C++ программу и смотрит, работает ли она так, как мы привыкли это видеть при компиляции неинтерпретируемого софта.
Строго говоря, компиляции там не происходит.
Расмус это подчеркнул — «на компиляцию ушло бы минут 20 на моём ноутбуке» — сказал он — «но статический анализ происходит так быстро, что его можно вешать на коммит».
Но смыслу сказанного вами это не противоречит: опять же, со слов Расмуса, «статический анализатор должен сделать в 10 раз больше вещей, чем обычный парсер РНР». Задача анализатора — отследить все возможные косяки до компиляции.
С другой стороны, ничто не мешает ту же самую функциональность реализовать силами IDE — ведь, теоретически, ide может отследить потерянный инклюд, лишние аргументы функции и многое другое. Вопрос — насколько полно и точно они это делают.
Расмус это подчеркнул — «на компиляцию ушло бы минут 20 на моём ноутбуке» — сказал он — «но статический анализ происходит так быстро, что его можно вешать на коммит».
Но смыслу сказанного вами это не противоречит: опять же, со слов Расмуса, «статический анализатор должен сделать в 10 раз больше вещей, чем обычный парсер РНР». Задача анализатора — отследить все возможные косяки до компиляции.
С другой стороны, ничто не мешает ту же самую функциональность реализовать силами IDE — ведь, теоретически, ide может отследить потерянный инклюд, лишние аргументы функции и многое другое. Вопрос — насколько полно и точно они это делают.
мне из Hip-Hop — 2pac нравится
Тоже понравилась эта часть доклада Расмуса!
Спасибо за более развернутую информацию…
Спасибо за более развернутую информацию…
А теперь этот же момент для ностальгии по Devconf ;)
Пардон, из статьи не совсем понятно, в каком виде он выводит результаты. Файлы называются *.js и вы называете этот формат «json», однако в примере явно вывод, аналогичный var_dump().
> Он транслирует PHP в C++!
Значит, для C++ есть какой-то открытый/бесплатный статический анализатор. Какой именно тут используется?
Пару лет назад озаботился поиском такового, пригодного к использованию не нашел.
Значит, для C++ есть какой-то открытый/бесплатный статический анализатор. Какой именно тут используется?
Пару лет назад озаботился поиском такового, пригодного к использованию не нашел.
Интересный подход! А есть ли пример С++ кода который получается после выполенения хипхопа на каком-нибудь php файле? Очень любопытно глянуть что там получается…
У перла есть тоже что-то подобное в стандартной поставке, но оно дико глючит, для средних проектов генерит С файлы размером метров по 10, от которых gcc встает раком на полчаса и более.
У перла есть тоже что-то подобное в стандартной поставке, но оно дико глючит, для средних проектов генерит С файлы размером метров по 10, от которых gcc встает раком на полчаса и более.
Огромное спасибо за статью.
Анализатор запускается, создает файлы со статистикой и ошибками.
Тем не менее я столкнулся с проблемой того, что файл CodeError.js всегда содержит 0 ошибок, какой бы код я не анализировал (даже с нарочно внесенными ошибками).
Выглядит он всегда вот так:
CodeError.js:
Сталкивались ли вы с такой проблемой?
Возможно в статье вы не упомянули о каких-то дополнительных настройках, управляющих записью ошибок в файл CodeError.js?
Анализатор запускается, создает файлы со статистикой и ошибками.
Тем не менее я столкнулся с проблемой того, что файл CodeError.js всегда содержит 0 ошибок, какой бы код я не анализировал (даже с нарочно внесенными ошибками).
Выглядит он всегда вот так:
CodeError.js:
[0,{}
]
Сталкивались ли вы с такой проблемой?
Возможно в статье вы не упомянули о каких-то дополнительных настройках, управляющих записью ошибок в файл CodeError.js?
А что содержит Stats.js?
Может у вас не сканируется ни один файл?
Например если задана переменная окружения $SRC_DIR или пуст файл со списком для проверки
Может у вас не сканируется ни один файл?
Например если задана переменная окружения $SRC_DIR или пуст файл со списком для проверки
Файлы сканируются — это видно при включении лога.
Содержимое Stats.us выложил здесь, вместе с примером анализа: habrahabr.ru/qa/23410/
Содержимое Stats.us выложил здесь, вместе с примером анализа: habrahabr.ru/qa/23410/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статический анализ PHP-кода с помощью HipHop