Comments 62
UFO just landed and posted this here
Мы «придумали свой», но по факту он очень слабо отличается от PSR-*. В данный момент мы не предоставляем готового стиля для PSR-*, но мы работаем над этим.
+2
Жаль, что не PSR, с удовольствием использовал бы. А есть какой-то документ, где кракто описаны отличия?
+2
В данный момент такого документа нет, к сожалению. Из «значимых» отличий я могу вспомнить, к примеру, про то, что после type-cast операторов у нас убирается пробел:
<?php
$a = (int)$b; // phpcf "default" style
$a = (int) $b; // PSR
+3
UFO just landed and posted this here
Выложил: Стандарт форматирования Badoo (пока что только по-русски, в дальнейшем планируем также сделать перевод всего на английский)
+2
Почему у вас запрещен импорт классов?
0
Вы имеете в виду использование «use SomeClass as AnotherClass»?
0
Нет, я имею ввиду почему вас в принципе запрещен импорт классов?
К классу, находящемуся внутри неймспейса, следует обращаться как \Namescape\ClassName и никак иначе, за исключением случая, когда код находится внутри того же неймспейса, в этом случае можно опустить \Namespace.
+2
На самом деле, phpcf это не проверяет, это наше внутреннее соглашение. Такое соглашение принято для того, чтобы облегчить grep по коду.
0
Как мне кажется, вы сильно недооцениваете необходимость в использовании утилиты grep в проекте с парой миллионов строк ;).
0
Find usages в PhpStorm не пробовали? Говорят, лучше подходит для таких целей.
+1
Для этого нужно ещё все тесты переписать на использования MyClass::$class вместо 'MyClass' в моках, например.
+1
Абсолютно верно. Еще попадаются редкие места, помимо тестов, где классы тоже в виде строки. В основном это call_user_function.
Тем не менее почти всегда стараемся в новом коде избегать таких вещей.
Кстати важный момент насчет MyClass::$class — класс должен существовать, те в случае автолоада он сразу подгружается. Т.е. есть вдруг кому захочется прописать где-нибудь некий маппинг классов в массиве, то лучше уж использовать строки, чем подгружать их всех разом.
Тем не менее почти всегда стараемся в новом коде избегать таких вещей.
Кстати важный момент насчет MyClass::$class — класс должен существовать, те в случае автолоада он сразу подгружается. Т.е. есть вдруг кому захочется прописать где-нибудь некий маппинг классов в массиве, то лучше уж использовать строки, чем подгружать их всех разом.
0
Кстати важный момент насчет MyClass::$class — класс должен существовать, те в случае автолоада он сразу подгружается.
Это неверное утверждение.
0
Я тоже могу кинуть фразу, что вы не правы и сделать крутое лицо.
Возможно я где-то не прав. Приведите пример — это был бы более конструктивный комментарий.
$a = Classname::$class;
PHP Fatal error: Class 'Classname' not found in php shell code on line 1
Возможно я где-то не прав. Приведите пример — это был бы более конструктивный комментарий.
0
Перечитал первоисточник(документацию) и понял в чем я не прав.
Да вы правы, погорячился я. Хотя можно было с вашей стороны поправить нас с неправильным синтаксисом:
ClassName::class действительно работает без подгрузки класса.
Да вы правы, погорячился я. Хотя можно было с вашей стороны поправить нас с неправильным синтаксисом:
ClassName::class действительно работает без подгрузки класса.
0
Почему не настраиваемо? (тот же phpcs умеет принимать файлы с стандартами, что позволило его включить в PHPStorm в качестве штатного инспектора)
0
Точнее, в комментариях написано, что конфиг есть, но в гитхабе/в посте — мимо.
+2
Стандарты кода описываются здесь github.com/badoo/phpcf/tree/master/phpcf-src/styles
Например можно описать требуемые отличия от стандарта по умолчанию
github.com/eelf/phpcf/commit/76c8c7205f4c316cb9f557ea960c8ed15a3a1eba#diff-d41d8cd98f00b204e9800998ecf8427e
Работает так
$ ~/phpcf/phpcf --style=compact apply classes/Db.php
или так
$ ~/phpcf/phpcf --style=minified apply classes/Db.php
Например можно описать требуемые отличия от стандарта по умолчанию
github.com/eelf/phpcf/commit/76c8c7205f4c316cb9f557ea960c8ed15a3a1eba#diff-d41d8cd98f00b204e9800998ecf8427e
Работает так
$ ~/phpcf/phpcf --style=compact apply classes/Db.php
или так
$ ~/phpcf/phpcf --style=minified apply classes/Db.php
+1
Для публичного инструмента конфиг ужасен :)
0
Согласен, выглядит несколько пугающе, но при рассмотрении вариантов:
1.) То же самое, в XML (плюсов с ходу не вижу, из минусов — потребить больше памяти, написать парсер конфига)
2.) Инструкции, подобно тому, как PHP: lxr.php.net/xref/PHP_5_5/Zend/zend_language_parser.y (опять же, подсистему парсинга, но теперь уже — псевдокода конфига)
3.) Сделать OOP-интерфейс для правил переходов
и для правил форматирования
4.) Текущая реализация (минимальный memory footprint, возможность программирования конфига на языке приложения)
Последний вариант мне кажется наиболее оптимальным.
1.) То же самое, в XML (плюсов с ходу не вижу, из минусов — потребить больше памяти, написать парсер конфига)
2.) Инструкции, подобно тому, как PHP: lxr.php.net/xref/PHP_5_5/Zend/zend_language_parser.y (опять же, подсистему парсинга, но теперь уже — псевдокода конфига)
3.) Сделать OOP-интерфейс для правил переходов
$State
->when($ContextPredicate)
->then($Transition)
->done($ReverseTransition); // (а-ля Promises, не обещает быть меннее монстроузным)
и для правил форматирования
$ClassToken
->inContext($ClassDefinitionContext)->do($IndentIncreateAction)
->inContext($ClassReferenceContext)->do($IndentIncreateAction);
4.) Текущая реализация (минимальный memory footprint, возможность программирования конфига на языке приложения)
Последний вариант мне кажется наиболее оптимальным.
+3
добавление в packagist планируется?
+1
Когда вожусь в чужом коде иногда очень хочется простой инструмент, который
Из такого:
делает примерно такое
А то названия функций или классы+методы очень длинные
Из такого:
<?php
$result = a(b(c(d($data))));
?>
делает примерно такое
<?php
$result4 = d($data);
$result3 = c($result4);
$result2 = b($result3);
$result = a($result2);
?>
А то названия функций или классы+методы очень длинные
и это все в одну строку...
-7
На самом деле, phpcf намеренно сделан таким, какой он есть, то есть, трогающим только пробелы, чтобы его можно было достаточно легко конфигурировать (то есть, не меняя исходный код, а изменяя конфиг). Мы «just for fun» писали простенькие утилиты по, к примеру, конвертации «старого синтаксиса массивов» в «новый», но более сложный анализ кода требует большой аккуратности, и пока что таких утилит у нас нет :).
+1
Интересно, а существует ли плагин к PHPStorm (например), который анализирует выбранный проект на используемый стиль (думаю данных должно хватить по всем пунктам, если проект не мелкий), и сохраняет его как шаблон. А вот делаю Pull Request например куда-нибудь, так и хочется нажать хоткей форматирования, то все порушится)
0
Не уверен, существует ли, но на основе phpcf такой плагин сделать вполне реально :).
0
В Project Settings -> PHP -> Code Sniffer настройки PHPCS. Это самое близкое к требуемому.
0
И еще Mess Detector там же. Щелкаете по директории — Inspect Code… и PHPStorm проверит по всем инспекциям, что у него есть (настроенные phpcs, phpmd, jshint, инспекции из Inspections, плюс разное — нераспознанные идешкой переменные, например).
0
UFO just landed and posted this here
Не понял по тексту, а возможно ли этой утилите скормить в пайп просто кусок кода вместо имени файла и номеров строк начала/конца? А то, насколько я помню, в эклипсе можно получить выделенный кусок кода для внешней тулзы, а номера строк нельзя…
+2
А что мешает в шторме импортировать удобный лично Вашей компании конфиг форматера(который более чем подробный в конфигурации) и пожамкать им в два клика целый проект?
+2
«Несколько лет назад компания Badoo начала значительно расти по числу сотрудников, с 20 до 100 и более»
Заставить под угрозой увольнения все сто человек выбросить любимый vim/emacs/netbeans? Это какой-то фашизм :)
Заставить под угрозой увольнения все сто человек выбросить любимый vim/emacs/netbeans? Это какой-то фашизм :)
+1
Причин несколько, на самом деле. Помимо того, что не все используют PHPStorm, мы хотели поддерживать «отформатированность» кода с помощью git-хуков, настроенных на отклонение неотформатированных изменений, с возможностью легко исправить форматирование. Поэтому отдельная утилита представляется намного более удобным и гибким решением, чем использование форматирующей части одной из популярных IDE, тем более проприетарной :).
+1
Как уже выше сказали, авто-форматирование в PhpStorm хорошая фича для небольших проектов с малым количеством задействованных разработчиков. Для большого проекта она бесполезна. Это всё нужно делать централизованно.
+1
> пожамкать им в два клика целый проект?
именно этого нам и хотелось избежать. Изначально (примерно 6-8 лет назад), у нас не было никакого стандарта. Точнее он был, но скорее как рекомендации и во многих местах он не был соблюден. Компания росла и в какой-то момент вопросы стандарта кодирования стали возникать всё чаще.
Было 2 варианта — отформатировать разом весь репозиторий, или сделать так чтобы весь новый код был по стандарту, а старый код постепенно бы менялся/рефакторился и тем самым попал бы под новое форматирование.
Полный реформат репозитория не понравился тем что сильно загрязнится история в git-е — много строк кода будут ссылаться на комит в котором был сделан реформат. Это неудобно потому что нам довольно часто приходится читать старый код, искать кто и почему написал ту или иную строку кода. Поэтому был выбран второй вариант
именно этого нам и хотелось избежать. Изначально (примерно 6-8 лет назад), у нас не было никакого стандарта. Точнее он был, но скорее как рекомендации и во многих местах он не был соблюден. Компания росла и в какой-то момент вопросы стандарта кодирования стали возникать всё чаще.
Было 2 варианта — отформатировать разом весь репозиторий, или сделать так чтобы весь новый код был по стандарту, а старый код постепенно бы менялся/рефакторился и тем самым попал бы под новое форматирование.
Полный реформат репозитория не понравился тем что сильно загрязнится история в git-е — много строк кода будут ссылаться на комит в котором был сделан реформат. Это неудобно потому что нам довольно часто приходится читать старый код, искать кто и почему написал ту или иную строку кода. Поэтому был выбран второй вариант
+2
насколько я понимаю с вопросом хука запрещающего коммиты «не по-формату» прекрасно справляется phpcs
вопрос автоформата в истории коммитов — его можно делать отдельным коммитом.
Собственно что хотелось бы понять из всей этой предистории — почему решили писать что-то свое а не адаптировать существующее. Ну я просто не верю что шторм настолько проприетарен что нельзя на отдельном компьютере(например на машине с TeamCity или PhpCI) поднять его и делать автоформат по хукам, или даже написать свою java-оберточку с форматером и запускать именно ее.
Если используете именно php как extension то почему не пойти с азов начиная с форка tokenizer'а или даже собственного bison-парсера?
Сейчас не вдаваясь в подробности я вижу что-то вида «ну мы тут чтото удобное нам накодили на php и немножко на zend'е — оно правит пробелы и еще что-то полезное. Profit»
Давайте лучше системный подход применим? Пойдем с понимания целей(в первую очередь) и задач?
А извините, с форматированием Unix-style строк и sed прекрасно справляется!
вопрос автоформата в истории коммитов — его можно делать отдельным коммитом.
Собственно что хотелось бы понять из всей этой предистории — почему решили писать что-то свое а не адаптировать существующее. Ну я просто не верю что шторм настолько проприетарен что нельзя на отдельном компьютере(например на машине с TeamCity или PhpCI) поднять его и делать автоформат по хукам, или даже написать свою java-оберточку с форматером и запускать именно ее.
Если используете именно php как extension то почему не пойти с азов начиная с форка tokenizer'а или даже собственного bison-парсера?
Сейчас не вдаваясь в подробности я вижу что-то вида «ну мы тут чтото удобное нам накодили на php и немножко на zend'е — оно правит пробелы и еще что-то полезное. Profit»
Давайте лучше системный подход применим? Пойдем с понимания целей(в первую очередь) и задач?
А извините, с форматированием Unix-style строк и sed прекрасно справляется!
-3
1. В статье сказано почему нам не подошёл phpcs — он мог проверить формат, но не мог отформатировать код.
2. Про автоформат.
Вы настаиваете что автоформат всего репозитория в нашем случае было бы правильным решением? Почему?
Очевидно что если бы мы решили его делать, то это был бы отдельный комит, но всё равно это сделало бы работу с репозиторием менее удобной — менее удобно было бы получать историю по всем строкам, задетым в момент форматирования. Баду репозиторий существует наверное более 8 лет, вопрос с форматированием кода начали решать где-то 3-4 года назад (могу ошибаться, точно не помню). То есть большАя часть кода в репозитории за первые 4-5 лет в git blame указывала бы на коммит автоформата, вместо того чтобы указывать на реальные «боевые» коммиты. С таким репозиторием неудобно работать.
И не стоит думать что мы сразу кинулись писать php экстеншен, сначало конечно был простенький скриптик на чистом php.
На остальные вопросы затрудняюсь ответить — я лишь пользователь phpcf, а не его разработчик.
2. Про автоформат.
Вы настаиваете что автоформат всего репозитория в нашем случае было бы правильным решением? Почему?
Очевидно что если бы мы решили его делать, то это был бы отдельный комит, но всё равно это сделало бы работу с репозиторием менее удобной — менее удобно было бы получать историю по всем строкам, задетым в момент форматирования. Баду репозиторий существует наверное более 8 лет, вопрос с форматированием кода начали решать где-то 3-4 года назад (могу ошибаться, точно не помню). То есть большАя часть кода в репозитории за первые 4-5 лет в git blame указывала бы на коммит автоформата, вместо того чтобы указывать на реальные «боевые» коммиты. С таким репозиторием неудобно работать.
И не стоит думать что мы сразу кинулись писать php экстеншен, сначало конечно был простенький скриптик на чистом php.
На остальные вопросы затрудняюсь ответить — я лишь пользователь phpcf, а не его разработчик.
+3
Причина, по которой мы написали phpcf на PHP, а не стали «раздраконивать PHPStorm» очень простая — мы (100+ разработчиков) умеем писать и готовить PHP, и не умеем готовить Java :). Первую версию phpcf написал fisher за пару вечеров, а с любыми другими утилитами на Java так бы не получилось :), даже если там всё на самом деле просто — мы не Java-программисты
+3
Полный реформат репозитория не понравился тем что сильно загрязнится история в git-е — много строк кода будут ссылаться на комит в котором был сделан реформат.
Это ж гит, в нем если нельзя, но хочется — то можно. :) Сделать реформат с сохранением истории, скажем, можно с помощью filter-branch.
0
После filter-branch изменятся хеши всех коммитов, и придется _везде_ переклонировать репозитории :). А разработчиков у нас немало, плюс ещё деплой, teamcity, и прочие места, где есть репозиторий — это очень большой гемморой был бы для нас.
0
Попробовал интегрировать в PHP Storm но вот что выводит в консоле при попытке обработать файл:
Проверяю на ОС Win8
А вот ошибка при попытке обработать выделенную область:
Internal formatter error: final state must be CTX_PHP or CTX_DEFAULT, got 'CTX_PHP / CTX_DEFAULT'
Проверяю на ОС Win8
А вот ошибка при попытке обработать выделенную область:
Internal formatter error: final state must be CTX_PHP or CTX_DEFAULT, got 'CTX_PHP / CTX_PHP / CTX_PHP / CTX_PHP / CTX_GENERIC_BLOCK / CTX_PHP / CTX_PHP / CTX_GENERIC_BLOCK / CTX_GENERIC_BLOCK / CTX_PHP / CTX_DEFAULT'
+1
Проблема форматирования связана с комбинированным использованием PHP + HTML в файле.
По инциденту заведен Issue на github, спасибо за репорт.
По инциденту заведен Issue на github, спасибо за репорт.
+1
Та-же ошибка при работе из cli 5.5.15 ubuntu
+1
Если вы не используете смесь HTML + PHP (то есть, случай, по которому мы уже завели тикет на гитхабе), будьте добры пожалуйста привести полный текст ошибки и содержимое файла, на котором у вас происходит ошибка (можно сразу на github, или мне или alexkrash в личку)
+2
А разве не проще настроить подобные простые замены в редакторе кода? Лично у меня это есть в VIM, а всякие там PHPStorm должны это всё уметь по-умолчанию. Или я не прав?
-1
В PHPUnit есть известный bug с покрытием таких конструкций:
If в данном случае не отработает, однако Xdebug считает его покрытым. Как выход можно заключить операторы после if в фигурные скобки:
Тогда Xdebug будет нормально считать покрытие, но только для первой конструкции. Вторую он все так же будет считать покрытой.
Вопрос вот в чем, как в badoo справляетесь с этой проблемой, если ваш форматтер как раз убирает фигурные скобки?
$var = false;
if($var == true)
return false;
if($var == true) return false;
If в данном случае не отработает, однако Xdebug считает его покрытым. Как выход можно заключить операторы после if в фигурные скобки:
$var = false;
if($var == true) {
return false;
}
if($var == true) { return false; }
Тогда Xdebug будет нормально считать покрытие, но только для первой конструкции. Вторую он все так же будет считать покрытой.
Вопрос вот в чем, как в badoo справляетесь с этой проблемой, если ваш форматтер как раз убирает фигурные скобки?
0
Sign up to leave a comment.
Badoo PHP Code Formatter. Теперь в open source!