Once you’ve got the PHP Coding Standards set up in Visual Studio Code, I think it’s also important to make sure that you have PHPUnit installed so that you get in the practice of writing testable code.
If you wait to start doing this until after you’ve started a project, you’re far less likely to start doing it. I’m saying this both from experience and from working with other developers.
So before I start covering how to handle front-end linting and things like that, I want to walk through the process of setting up PHPUnit. If you’ve not yet read how we’re managing packages or how we’re using Visual Studio Code, I recommend catching up by reading the following articles:
- A WordPress Development Environment (Using a Package Manager)
- An IDE for WordPress Development
- Working with User Settings in Visual Studio Code
Once you’re caught up, head back to this post.
So we’ve got the basics set up in Visual Studio Code set up, but we don’t have any practical tools installed to help us with more of the professional side of writing code.
Of course, “professional” can be defined based on the company, team, or environment in which you’re working. For this series, I’ve opted to go with WordPress as the foundation. But that still leaves things such as:
- coding standards,
- package management,
- And so on.
And throughout the series, I’m going to cover everything listed above. But to do so, I’m going to cover each component one-by-one.
Today’s post is going to focus on the PHP coding standards. I’ve written plenty of material regarding the WordPress Coding Standards, but in the last year or more, I’ve begun to work more with PSR, and so that’s what will be covered in this post.
As a side note, know that much of what is covered can be translated to the WordPress Coding Standards should you so choose, and it’s going to be clear as to where you’d make the changes.
With that said, let’s get started.
If you’ve not read last weeks post (and you’re a member of the site), then I urge you to do so now as this one picks up exactly where the previous one left off.
In short, we’re going to start talking about configuring Visual Studio Code for professional WordPress development. Of course, that raises a question: What is professional WordPress development?
If you ask ten different people, you’ll probably get 8-10 different answers; however, I’d define it as using professional software development practices within the context of WordPress.
Naturally, right? But what does this entail?
Off the top of my head, I think of:
- Using proper dependency management tools such as Composer, NPM or Yarn,
- Debugging using breakpoints (over var_dump and echo),
- Knowing how to format code using a given standard (PSR in the case that I’ll be using),
- File organizational structure,
But before getting into all of that, I think it’s important to get the IDE set up in such a way that looks good, plays well with the way that we want, and that we understand how it works so we can further tweak it as the need arises.
So in today’s post, we’re going to look at exactly that: Understanding how Visual Studio Code manages settings and a proposed list of configuration options that will help make your experience as solid as possible.
In the previous article, I walked through the process of setting up a local development environment using a package manager. Specifically, I talked about using Homebrew to install Valet and Composer.
The former offers the Nginx web server, a MySQL database server, while Homebrew allows you to install PHP. Composer gives you the ability to deal with PHP dependencies. If you’ve not read the post, I highly recommend it as this post is predicated on that entire environment.
Specifically, I’m going to be talking about IDEs. It’s a hot topic, I guess, but if you don’t have a preference then I’m going to walk you through the process of picking one that I think is best (at lest to start with), configuring it, and using it in the context of the environment established last week.
I’ve not been coy about my appreciation for Visual Studio or how it performs as an IDE for WordPress, but there are always things here and there I think are worth sharing either for the sake of making it a better experience or for improving our workflows.
Case in point:
How many of us work on codebases large enough that we’re writing comments, code, or other features that yield us dropping TODOs or FIXMEs throughout the code so we can focus on the task at hand?
I think our intentions are good. I mean, we do plan to come back to these, but if they aren’t documented in some way, it’s far too easy to come back and do then.
And sure, you can always do a “find all” at the end of a sprint or before the end of a project of whenever works best for you, but there are extensions that can do this for you.