Introduction of the plugin and how to run it, what to look at + more hints.

1. Php Inspections (EA Extended)*:
The Cookbook
* Extended for Enterprise Applications

2. @kalessil
github.com/kalessil
www.patreon.com/kalessil

3. Key features
● Saves your time and nerve cells
● How:
○ Pitfalls and bugs detection
○ Null references detection
○ Exceptions handling workflow analysis
○ Performance (high-load) analysis
○ Regex and core APIs usage analysis
○ Quick-Fixes for most of inspections

4. Dealing with legacy (and enterprise muhahaha)

5. Stop! That’s new code!
● Enable deactivated inspections
● Keep files “green”
●

6. Safety prerequisites
● PhpUnit
○ Unit-Testing framework
○ Mandatory safety requisite
● phpspec
○ Behaviour-Testing framework
○ Great addition to safety
* false-positives + edge cases are popping up constantly

7. Clean up workspace
PHP Coding Standards Fixer
● Automatically applies CS
● CI friendly
● Flexible configuration
● Play with enabling risky fixers
○ Some are contributed by me;
○ Some are rules ported from us;

8. Sharing configuration
● Tweak Project Default settings
● Share your work:
○ VCS <- .idea/inspectionProfiles/*
■ IDE headless mode friendly
■ Github: kalessil/phpstorm-inspect
○ Settings Repository plugin
■ File -> Settings Repository
● Review config changes regularly
○ Track new inspections
○ Track inspections settings

9. Hints before the first run
● Give IDE enough memory
○ Where: Help -> Diagnostic -> Change memory settings
○ Why: https://dzone.com/articles/the-one-and-only-reason-to-customize-intellij-idea
● Architecture -> Multiple return statements usage
○ Worth enabling, the early returns is not as good solution as you might think
● Review settings
○ Code style -> Increment/decrement operation equivalent
○ Code style -> Self class referencing
○ Code style -> Static method invocation via ‘->’
○ Code style -> Yoda/regular conditions style usage
○ Control Flow -> Exceptions handling and annotating
○ Control Flow -> Not optimal if conditions
○ Language level migration -> ‘null === ’ can be used
○ Probable bugs -> Forgotten debug statements

10. First run
● Check project language level settings
○ Our inspections are respecting the language level =)
● Check ‘Code Style -> Unknown inspection suppression’ results:
○ Perhaps you are missing some plugins;
● Check ‘Security -> *’ results
○ And our GitHub documentation for them with some hints
● Check ‘Probable bugs -> *’ results
○ It’s difficult to predict what you are going to find there
● Check ‘Compatibility -> *’ results
○ You never know how old the legacy code can be

11. Where to start
● Some of rules might be irrelevant for the project
○ Deactivate and push config changes into a repository
● Group result by severity
○
● Start cleaning up messages
○ Ideally at the beginning of a new sprint
○ Ideally in the module which gets most of changes during the sprint
■ Higher probability to find unnoticed side-effects
○ Separate code CS changes and issues fixes

12. What’s next?
● Once you get through the first round:
○ Language level migration
○ Performance
■ reward yourself =)
○ Control flow
■ Enables more SCA checks
● Foreach
● Core APIs
● Conditional statements
○ Unused (drop the dead code)
■ this always feels good =)
● Repeat - SCA is a continuous process

13. Survival mode

14. @kalessil
github.com/kalessil
www.patreon.com/kalessil
Thank you