PhpStorm allows you to pre-define how you want to document your functions. Using templates, you layout the DocBlock format and structure for things like the revision number, parameters, return value, etc. Why? Why would you want to do this? It saves you time and promotes a standard approach for documentation. Let’s define the template together in this episode.
Wouldn’t it be nice if your editor would tell you that you are not being compliant to the coding standard? Imagine the editor highlighting a piece of code, as you are developing it, and giving you the reason why it broke a rule. Wouldn’t that save you time and frustration later? Sure it would. We can configure PhpStorm to use our project’s PHPCS XML file to do active code inspection. Here, let me show you. Here are the composer.json and phpcs.xml.dist files from Beans.
To take full advantage of what PhpStorm has to offer, we need to enable WordPress integration. Once we do, then we get features like: Jump to where a hook (event) is being fired. Autocompletes for hook names. Filtering lookup for hooks.
The refactoring tools in PhpStorm are awesome! I use them all the time to automate my workflow and get rid of some of the steps/tasks. Let me show you.
In one keystroke, you can quickly jump right to the source function (or class, trait, or interface). This feature is one of my favorites. Here, let me show you.
Many times, you need a different coding standard than the one specified by WordPress. Maybe your team and you use a modified version of the WPCS. Or maybe you are developing a project that uses PSR. PhpStorm lets you configure and save different coding standards, giving you the ability to set it up once and then select the one you need on each project.
PhpStorm allows you to configure a coding standard. Using that standard, you can reformat an entire file to compile the standard…with just one keystroke. It saves you so much time, allowing you to do your work, trigger the reformatter, and bam, you’re done. Let’s configure and test that together.