An Absolute Beginner's Guide: Working with IDEs

I recently presented at Drupal GovCon on this topic! If you missed it, here’s a quick write up and the video (thanks to Drupal4Gov for sharing on YouTube.

What is an IDE

Let’s start simple!

There are essentially three types of tools that you might use to write code:

1. Terminal

2. Text Editor

3. IDE

An IDE, if you aren’t familiar, is:
An integrated development environment (IDE) is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of at least a source code editor, build automation tools and a debugger. - https://en.wikipedia.org/wiki/Integrated_development_environment

IDEs are particularly well suited for object oriented programming because of their ability to index the various methods and classes that you will be using in your code and giving you tons of useful hints, autocompletion, deprecation warnings, documentation, and more!

Warning: not all IDEs are well suited for PHP development. Here are a few to check out…

• PHPStorm

• Visual Studio

• Netbeans

• Aptana

• Eclipse (w/ PHP)

Personally, I use PHPStorm.

Why Not Use a Text Editor (like Sublime Text)?

First of all, Sublime Text is awesome and you should totally use it! I’ve used it for a long time. BUT it’s not an IDE. It’s just a text editor.

Because it’s just a text editor, Sublime isn’t going to give you nearly as much useful information as you’re writing code. Worse, you can’t use it to debug and step through your code (which is critical in Drupal 8 and 9).

Here’s a hands on example of the same deprecated code written in Sublime vs. PHPStorm:

Sublime Text:

PHPStorm:

Notice how in the two screenshots the getStorage method is scratched out in PHPStorm (but not in Sublime Text)? This is because it’s a deprecated method. The IDE is going to tell you that immediately so as you write the code you can see it and go… “OH MAYBE I SHOULDN’T USE THIS METHOD.” Sublime is going to let you go blissfully along and not warn you that it’s a problem.

Using a Debugger

Another pretty significant part of using an IDE is the ability to tie in a Debugger (like XDebug).

The main use of a debugger is to run the target program under controlled conditions that permit the programmer to track its operations in progress and monitor changes in computer resources (most often memory areas used by the target program or the computer's operating system) that may indicate malfunctioning code. Typical debugging facilities include the ability to run or halt the target program at specific points, display the contents of memory, CPU registers or storage devices (such as disk drives), and modify memory or register contents in order to enter selected test data that might be a cause of faulty program execution. - https://en.wikipedia.org/wiki/Debugger

In a Drupal context, in the old days (D6/D7) a debugger wasn’t critical because basically all custom PHP as written in hooks (which essentially always execute, and have fairly simple data models). In D8/D9, NOT everything is a hook and aside from that, there’s a lot of ambiguous stuff going on outside the scope of the method you’re in (thanks to Symfony) that you may not know to try and print out with Devel. Enter Debugging.

Debugging lets you get a much more in depth look at everything that is going on at the moment of your breakpoint. Obviously your code has to execute to pause (which itself can be a challenge) but you aren’t limited to “just the thing you print.” It shows you all the things going on. It lets you step through the code. It lets you watch variables. It’s really powerful!

Demonstration

Have a look at my talk from GovCon. In it, I take time to walk through PHPStorm and show hands on how to Debug using PHPStorm, Lando, and XDebug.

Related Content