• Обнаружение дефектов кода типа «Expression Issues» (CWE-569)
    0
    О, то что надо. Я пошел узнавать, отпишусь как мне ответят)
  • Обнаружение дефектов кода типа «Expression Issues» (CWE-569)
    0
    — Отдельно для каждой ветки — не пробовал, спросил: нет, проверяется текущая ветка.
    — Это ограничения пробной версии, большие проекты тоже можно проверять. Проект приватный или опенсорсный (может ссылку дадите)?
  • Обнаружение дефектов кода типа «Expression Issues» (CWE-569)
    0
    SerafimArts, вот ещё пара проектов, которые стоит посмотреть:
    • https://www.exakat.io/ (рекомендую посмотреть — разные анализаторы ловят зачастую разные проблемы)
    • https://www.sonarqube.org/ (фокус на code quality)
  • Обнаружение дефектов кода типа «Expression Issues» (CWE-569)
    +5
    Scrutinizer что-то, конечно, находит, но для интереса попробуйте Php Inspections (EA Extended) (плагин для PhpStorm), посмотрите что нормальные анализаторы могут.

    Ну и PVS-Studio, конечно, вообще молодцы и дело говорят.
  • Введение в PHP 7: Что добавлено, что убрано
    0
    Ну вы либо пишете грамотную урезанную бету (архитектурно, компонентно и с читаемым кодом), либо одноразовый прототип который нужно выкинуть сразу.
    Но не запускать мидлов и отправлять на ревью архитектуры на базе сляпанного на коленке прототипа. Ей богу, это же ад для команды.
  • Хабр умирает?
    +1
    Не знаю если честно, просто консолидирую опыт. Вариантов даже больше:

    • 1-3 года — прототип не взлетел
    • 3-6 лет — прототив взлетел, но рынок поменялся
    • 10-15 лет — взлетел, обжился на рынке

    10-15 лет может быть обусловлено тем что менеджмент не меняется, и под конец просто хочет стабильного дохода (и плевать на инновации и качество, мне нужно просто выжать всё без дополнительных расходов).

    Учтите если будете устраиваться в продуктовую компанию =)
  • Хабр умирает?
    +2
    Да ничего нового, обычный жизненный цикл системы: взлетели, стагнировали, упали. У продуктов (коим хабр и является) он составляет 10-15 лет. Последние 5 обычно как раз попытки его оживить, но это редко получается.
  • Хабр умирает?
    0
    Сейчас вам плюсов накидаем)
  • Хабр умирает?
    +6
    Шикарный ответ) А статью про хлебушек помним.
  • Cобрать лучшее из двух миров — фреймворков и CMS (часть 3)
    +2
    Вот из-за такого хода дискуссий приходится уходить в англоязычный сектор опенсорса. Без обид.

    nazarpc инфраструктурно развивает сообщество (CMS, polymer, для Php Inspections (EA Extended) были баг-репорты) и критиковать решения не стоит.

    Не нравится решения автолоадинга, докера, архитектуры — делайте пулл реквесты, или создавайте тикеты.
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    Добавил.

    PVS-studio меня и вдохновили, но у них это бизнес и очень круто, что они готовы инвестировать ресурсы в статьи.
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    Часть коммента почему-то потерялась.

    Часть автозамены я законтрибутил в PHP CS Fixer: они идут в правильном (на мой взгляд) направлении и надежнее для проекта будет развивать утилиту для коммандной строки (хуки, CI и т.д.).
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    Это отличный отзыв, спасибо =)
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    15% проголосовавших указало Другое в опросе со сценариями. А какие это сценарии?

    Обучение, аудит, оценка брать проект или нет или ещё что-то?
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    Понял. Тут помогли бы реальные примеры из жизни команд — надо же что-то брать за основу для анализа.

    Простые случаи вроде запросов в цикле вместо булк-запроса довольно просто реализовать. Хочется случаев посложнее =)
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    Есть проекты где вычищать код без автозамены — это очень долго.

    Например нашей системе около восьми лет, сменились несколько команд и приводить в чувство это счастье приходится поэтапно.
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    Это как раз сценарий high-load.
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    Добавил параграф с пояснением:

    Напомню, что Php Inspections (EA Extended) — это отдельный плагин, расширяющий возможности штатного анализа в PhpStorm и Idea Ultimate. Ранние анонсы на хабре: раз, два, три.
  • Php Inspections (EA Extended): выбираем стратегию на 2016 год
    0
    Пожалуйста =) Для isset/empty можно даже поведение настраивать (часто жаловались).

    Фокус на создание сообщества (редкие релизы)

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

    фокус на коммерческую версию (возможность автоматической замены кода)

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

    Специализация на high-load проектах

    Работа с соответсвующими командами (если смогу набрать достаточно контактов) и новые проверки именно для high-load. Уровни репортинга анализатора тоже надо будет пере-определить.
  • SonarQube. Проверяем код на качество
    0
    В общем доработка плагина и работа из ИДЕ, то что мы сейчас и делаем.

    Сонар оказался никому не нужен, ну нашему ПМу разве что — т.к. он бюджет на него потратил =).
    Солюшн Архитекторы плюнули на эту поделку, в работе от него толку нет: так и так код-ревью делать надо.
  • PHP-Дайджест № 65 – интересные новости, материалы и инструменты (14 – 28 июня 2015)
    0
    В общем-то да.

    Я по вот этим пунктам сужу:
    • Elvis operator can be used
    • Ternary operator simplification
    • Not optimal if conditions


    Остальное (кроме Control flow) — совсем базовые проверки.
  • Статический анализ кода в PHP: регулярные выражения
    0
    На самом деле спасибо за комментарий, я как-то не за то зацепился =)

    Думаю, что надо добавить ремарку про этот нюанс в текст анализатора.
  • PHP-Дайджест № 65 – интересные новости, материалы и инструменты (14 – 28 июня 2015)
    +1
    ovr/phpsa: список правил слишком уж напоминает Php Inspections (EA Extended).
  • Статический анализ кода в PHP: регулярные выражения
    0
    Про большие строки (например блоки XML), там же говорится что preg_match будет быстрее, про эти случаи вы правы.
  • Статический анализ кода в PHP: регулярные выражения
    0
    Да, я прекрасно понимаю разницу и вам следует таки опираться на факты и публичные матералы, а не переходить на личности.

    Вот ещё один пруф, что strpos будет бытрее.
  • Статический анализ кода в PHP: регулярные выражения
    –1
    Официальная документация говорит в пользу моего варианта:
    Do not use preg_match() if you only want to check if one string is contained in another string. Use strpos() or strstr() instead as they will be faster.
  • Безумный PHP. Фьюри код
    0
    А то, как и использовать === вместо ==.
  • Статический анализ кода в PHP: регулярные выражения
    0
    На проверенных проектах надо вычищать либо в одну сторону, либо в другую: \d и [0-9] сосуществуют.

    Но [0-9] гораздо реже используется, поэтому, выбор — решение команды, зависящие от конкретного проекта.
  • Статический анализ кода в PHP: регулярные выражения
    0
    Пожалуйста. Настроить можно здесь: Settings -> Editor -> Inspections -> PHP -> Php Inspections (EA Extended)

    Посмотрите что из Code Style вам подходит, остальные группы можно не трогать — по ним нареканий ещё не было.
  • Статический анализ кода в PHP: регулярные выражения
    0
    В Probable Bugs что-нибудь интересное нашли?
  • Статический анализ кода в PHP: регулярные выражения
    0
    Второе — это настроить под себя Code Style инспекции, чтобы сфокусироваться на других сообщениях.


    Это как раз о таких вещах: запятые, двойные кавычки, вложенные условия.

    Как вариант, Settings -> Editor -> Inspections -> PHP -> Php Inspections (EA Extended): просмотрите всё, что Code Style и настройте под ваши реалии.
  • Статический анализ кода в PHP: регулярные выражения
    0
    Этот вариант меняет поведение, по спецификации возможны вложенные теги (во всяком случае мой пулл-реквест с этими правками завернули):

    <esi:include src="http://www.example.com/ad.html"/> 
    <esi:remove> 
      <a href="http://www.example.com">www.example.com</a>
    </esi:remove>
    
  • SonarQube. Проверяем код на качество
    0
    Это немного разные вещи, сонар больше вещей может (полезных):
    • работать с проектами на смеси языков — и считать метрики по ним всем
    • предоставлять метрики
    • рапортовать технический долг (ой как врёт, зараза)


    Php Inspections (EA Extended) для старта можно дополнить Php Metrics — когда этого мало, уже пробовать сонар.

    Классика жанра — ставим сонар, не знаем что делать с его отчётами, сносим.

    Php Metrics ставится как плагин, сносить будет не жалко.
  • Мы закрываем проект CppCat
    0
    Ну пожалуйста, расскажите уже подробнее…
  • Мы закрываем проект CppCat
    +9
    А можно кратко и сравнительно охарактеризовать различия?

    PS: большое спасибо за ваши статьи, благодаря им повился вот этот анализатор для PHP.

  • Мы закрываем проект CppCat
    +1
    Во-первых, я искренне рад, что есть люди, которые включают статический анализ в свои курсы — меня текущие тенденции в образовании, в основном, печалят, но тут прямо хорошие новости.

    Про проблему понял. Никак, к сожалению, приходится искать альтернативы.

    Не в тему, но мне кажется, что статический анализ может хорошо плказать себя в курсовых и дипломных работах — для студентов будет очень наглядно.
  • Мы закрываем проект CppCat
    +2
    А можно взять и опробовать на опенсорсе, для своего обучения, вместо простейших лабораторок.
  • Мы закрываем проект CppCat
    +13
    Можно и SaaS (SensioLabs Insight, например).

    Но корпоративный сегмент (который хорошо платит) не любит одавать код третьей стороне, поэтому вариант с SaaS для статического анализа просто не взлетит.
  • Симфония самоподдува
    +2
    Если не лезть в дебри кода, то обратная совместимость минорных релизов — на моей памяти только они это обещание сдержали.

    Часть абстракции именно для того, чтобы сложно было напортачить (высокий порог вхождения).
  • Баги. Баги никогда не меняются
    0
    Появятся, даже не сомневайтесь: сложность алгоритмов и лигики в софте постоянно растёт и, чтобы не стагнировать, индустрия делает средства разработки и анализа всё интелектуальнее.

    Например,

    FindBugs (Java) уже умеет находить проблемы с многопоточностью.
    Этот анализатор (PHP) умеет находить проблемы с шаблонами проектирования и памятью.
    Можно вспомнить ещё ReSharper Inspections.

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