Какие линтеры использовал?

Мой опыт работы с линтерами для PHP Backend

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

PHPStan - основа статического анализа

PHPStan стал моим основным инструментом для статического анализа типов. Начинал с нулевого уровня, но в современных проектах использую уровень 8 (максимальная строгость):

// Пример конфигурации PHPStan
parameters:
    level: 8
    paths:
        - src
    checkMissingIterableValueType: false
    reportUnmatchedIgnoredErrors: false
    excludePaths:
        - tests/*/Fixture/*

Ключевые преимущества:

• Выявление ошибок типов до выполнения кода
• Обнаружение dead code и неиспользуемых переменных
• Анализ nullable-типов и strict сравнений
• Интеграция с PHPStorm для мгновенной обратной связи

PHP Code Sniffer (PHPCS) + PHP-CS-Fixer

Для поддержания единого стиля кода использую связку PHPCS (обнаружение проблем) и PHP-CS-Fixer (автоматическое исправление):

<!-- Пример правил .php-cs-fixer.php -->
<?php

return (new PhpCsFixer\Config())
    ->setRules([
        '@PSR12' => true,
        'strict_param' => true,
        'array_syntax' => ['syntax' => 'short'],
        'declare_strict_types' => true,
    ])
    ->setFinder(
        PhpCsFixer\Finder::create()
            ->in(__DIR__ . '/src')
            ->in(__DIR__ . '/tests')
    );

Мои стандартные правила включают:

• PSR-12 как базовый стандарт
• Обязательное объявление strict_types=1
• Единый стиль именования методов и переменных
• Контроль длины строк (120 символов максимум)
• Правила для массивов и многострочных конструкций

Psalm для углубленного анализа

В сложных проектах дополняю стек Psalm, который особенно полезен для:

• Аннотаций типов в phpDoc
• Выявления security-проблем
• Анализа шаблонов проектирования
• Taint-анализа (поток данных)

// Пример аннотаций Psalm
/**
 * @template T
 * @param array<T> $items
 * @param callable(T): bool $callback
 * @return array<T>
 */
function filterArray(array $items, callable $callback): array {
    return array_filter($items, $callback);
}

Интеграция в CI/CD pipeline

Все линтеры интегрирую в процесс разработки:

1. Pre-commit хуки через Husky или native git hooks:

#!/bin/bash
vendor/bin/php-cs-fixer fix --dry-run
vendor/bin/phpstan analyse --memory-limit=1G

1. GitHub Actions / GitLab CI для автоматической проверки:

# Пример GitHub Actions
- name: PHP Lint
  run: |
    composer validate --strict
    vendor/bin/parallel-lint src tests
    
- name: Static Analysis
  run: vendor/bin/phpstan analyse --memory-limit=1G
    
- name: Code Style
  run: vendor/bin/php-cs-fixer fix --dry-run --diff

1. Поэтапное внедрение в legacy-проектах:
   • Начинаю с низкого уровня строгости
   • Постепенно увеличиваю требования
   • Игнорирую старый код с помощью baseline-файлов

Дополнительные инструменты

• PHPMD (PHP Mess Detector) - для выявления "запахов кода"
• Deptrac - контроль зависимостей между слоями
• Composer Require Checker - проверка необъявленных зависимостей

Практические рекомендации

Из своего опыта могу порекомендовать:

1. Не игнорировать предупреждения - каждое предупреждение потенциально может стать ошибкой в будущем
2. Использовать strict режим везде, где это возможно
3. Настроить IDE-интеграцию для мгновенной обратной связи
4. Вести историю улучшений качества кода через метрики
5. Адаптировать правила под конкретный проект и команду

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