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,
  • Using things like Sass, JavaScript linting, and so on to ease development

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.

[restrict paid=”true”]

User Settings in Visual Studio Code

Before getting started, I recommend downloading Fira Code and installing the font on your operating system of choice. Though there are plenty of other fonts (like Source Code Pro) that are also nice, I’ve found Fira Code to be one of my personal favorites especially with its ligatures (but more about that momentarily).

This is what you’re going to see in screenshots throughout the remainder of this series.

1. Understanding Settings

First, note that Visual Studio Code has a default file that it uses for settings across its projects. You’ll notice this if you go to the Code > Preferences menu (or whatever is similar to your operating system.

User Settings in Visual Studio Code: Settings

In short, everything is set in a JSON file. Here’s where it gets fun: You can customize this file by essentially overriding what it provides by using a User Settings file that it provides.

And the nice thing is that though it overrides what Visual Studio offers, the IDE will always fall back to the default settings that ships with it.

In this particular post, I’m going to look at simply defining editor settings. In future posts, though, we’re going to look at working with PHP, coding standards, and more.

2. Configuring Your Settings

For this post, I’m going to assume that you have a project open. This can be a new project or an existing project. Regardless of which, what I’m going to offer will still apply.

Secondly, I’m going to be making suggestions based on the type of work I most often do. Though I recommend these settings for others and though we may be making small tweaks (for example, some linters don’t want space through which to throughout this series on the IDE, these are the most general things used to help get started).

When you first open the file, it will be blank. Remember, it must be written in proper JSON otherwise, it’s not going to work (let alone now through an error).

Here’s an example of what I have my in my editor settings:

Each should be self-explanatory; however, note that I do have editor.fontLigatures set to true since I’m using Fira Code. This will change certain things like === into a ligature.

User Settings in Visual Studio Code: Ligatures

This makes for a much more pleasing experience when writing code.

3. Sharing Projects

Finally, one of the things that I find useful is having projects in a place that can be shared among multiple machines. This may be done via Google Drive, Dropbox, or iCloud Drive.

Whatever the case, I recommend doing the following:

  1. Keeping your projects, assume they aren’t sensitive, of course, in a file sharing service,
  2. Store each workspace file along with the project files in said service.

This way, if you opt to use multiple machines, you should have the source files that you need to work on each project. But I won’t belabor the point here. I’ve discussed this in a previous post, and the process still sounds.

I simply felt that pointing it out would be a good move just in case it’s not something you’ve considered.

Looking At Coding Standards

Obviously, this post isn’t extremely technical, but we’re going to start implementing coding standards in the next post, and that will require a bit of work with Composer as well as with working with user settings.

And to make sure we’re able to do that, it makes sense to lay the foundation to understand how settings work so we can continue to edit them in the future.

[/restrict]