Why I love My IDE

I started my first code in Windows 3.0 using Notepad. When HotDog and Netscape’s editor came along, it seemed a pretty good idea to use something that did some of the work for me. When I started coding for Flash, Dreamweaver* was bundled with the Macromedia package and seemed okay until I viewed the source code of the pages. It would fill up up the source code with tons of empty elements you couldn’t see in the editor, increasing page size and made it difficult to validate pages. Also in the package was a little gem called HomeSite, complete with color-coded markup and multiple language support, I thought I had found the hand-coding promised land and used it as late as 2000.

But it wasn’t until I saw my code in a really good IDE that I reached the lowest point of humility. Code I thought was perfectly fine filled with tons of unused and undefined variables, stray tags and other stupid oversights, and poor logic constructs. My code was garbage (and a lot of it probably still is,) and I had a lot to learn.

The developers I worked with at the time chuckled at the IDE newbie and advised, "you should probably just turn all the warnings and error notices stuff off. I do." This completely boggled my mind. Why would you ignore something that is telling you how to be a better coder?

I’m not going to cover all the good IDE’s in this post, there are a lot of them. I have settled with Jetbrains PhpStorm (or the IntelliJ IDE for your language.) Netbeans is open source and free and has almost all the features of PhpStorm, but not quite.

It would be a major TL,DR to list all the reasons I use PhpStorm (and may be anyway.) I’ll only list the high points, ones that increase my productivity and make me a better coder on a daily basis. The short answer is that the creators of PhpStorm have put a lot into helping me write PSR compliant and well structured code, in PHP, Javascript, HTML, or Perl. I set aside my ego and listen to what it’s telling me.

• Supports most languages. Being "Php"Storm, although it’s primarily for PHP, the markup, code inspection, and format handling is appropriate for most common languages, and if it’s not supported, there’s usually a plugin. All of the front and back end languages I work in are supported out of the box except Perl, and the plugin for Perl works just awesome.
• Language version specific. Related to that, I can set up PhpStorm for the language version I’m in to control what warnings I see and do not see. One example is if I have the environment set up for PHP version 7 or greater, array() will show as a warning. it will also show deprecated functions and functions not supported by the version.
• Active debugging. With every character I type, PhpStorm runs the code and identifies errors. It’s very smart about it too, it always underlines the first instance of the encountered error. It also has autocomplete functions: as you type it searches your code base for the next likely entry. I don’t use these as I spend more time back-spacing to correct the IDE’s guess at what I meant.
• Bazillions of settings, all exportable. I can’t even list them all, or ones I’ve tweaked. You can set up whether you use spaces or tabs, and how many spaces to auto-indent, whether your opening brackets go on the same or next line, spaces before/after tokens in logic constructs, how to format (and auto-formatting settings,) about anything you can think of in coding there is a setting for it. You start by setting global IDE settings, then can add tweaks to specific language settings for code style and IDE markup color. There are multiple IDE themes, and many others you can download and install. The really great part about this is once your organization settles on a style, the settings can be exported and imported to every user’s copy of PhpStorm so everyone is coding to the same standard.
• Error Stripe/Status Indicator. This is an "unsung feature" in Jetbrains products for many developers but I find it extremely valuable as an "at a glance" summary of a file. Over the right scrollbar is an error strip indicator that marks warnings and errors through the code lines. This can be annoying at times because I often work with legacy code that has so many defects it’s hard to see the slider/grip/handle through them. It is one of my goals as I work a file to keep the error stripe clean.
• Internal navigation. In opposition to coding to PSR Standards, I was once asked to not change array() to [] even though we were using PHP 7.2. The reason given was "when searching the code base I know to look for array()." The built-in navigation features of PhpStorm (and other IDE’s) make text-match searching a thing of the past. A CTRL+click on a function name, variable, or other identifier will either take you to where that identifier is used in the code base or show all instances where it’s used. This has saved me tons of time navigating a system. You can still search for text matches, but it’s rare I need to. The exception is if the code is poorly structured or the doc blocks are incorrect.
• Version Control. If I had to choose the best feature of PhpStorm, it’s how it handles version control. You can manage multiple repo sources and there is full integration to push/deploy, but generally I use it mostly for file/version diff’s in code reviews and stick to command-line for my commits and pushes. The graphical interface makes code reviews a breeze: check out the feature branch, right-click on the project root and select "compare with master." It shows me every file that has changed. Individually, anywhere in a file you can right-click and diff it against any branch to see exactly what lines have changed. When merging, you get the same GUI and merging conflicts is visual, very obvious, and tons easier. It has improved both my version control cycle and efficiency in reviews and version maintenance.
• Proper doc blocks. Early in my career my impression of comments was that they were a tool to clarify what the code is doing or help visually separate one logic block from another to make it more "legible." Consider the trivial example at the left, and how PhpStorm sees it at the right.
  
  
  

  <?php
      class UselessClass
      {
          /**
           * @return string
           */
          public function uselessFunction()
          {
              return $this->uselessOutput();
          }
  
          /**
           * @return array
           */
          protected function uselessOutput()
          {
              return [
                  'foo' => 'bar',
                  'baz' => 'boz',
              ];
          }
      }
  
  

  As mentioned in Down the Rabbit Hole, if not maintained as the code evolves, comments are places to collect misinformation and explain what the code is doing because the code itself is not clearly expressed. There are two very good reasons for comment doc blocks: a PHP documenting software can read them for auto-generated documentation, and PhpStorm can do it’s best work if they are properly formed.
  The comment says the first method returns a string, and any code calling it will expect a string, but it’s returning an array. Incorrect doc block params and returns will break the internal navigation of PhpStorm in many cases, and if documentation is generated from this docblock, it will be wrong. PhpStorm allows you to create proper docblocks and points out where the lies need to be made truthful. It also allows you to modify templates for the internal code standard of your organization. The video below demonstrates you only need to type /** and press Enter, it will start a proper doc block with proper return types. Note how it identifies the default string and array types tells me I have unused variables, and the params are not adhering to PSR standards – all easily overlooked in a straight text editor.
• Floating pane/workspace support. I work with two monitors, main workspace in front of me, utilities/extras on the right. The float mode of project, structure, and find windows allows me to move them to the second monitor and expand the actual editor area full screen on my primary monitor. The pane positions can be saved as a default workspace and export with settings.
• Templating. One of the things I love about Laravel is artisan in which you can create a table and stub out all CRUD classes for it in a single command, and they will all be in the correct places in the system. You can almost do that in PhpStorm as well!** You can stub out any object you use regularly in PhpStorm template settings: a class, a function, a doc block comment, or grow your own.
• Does using an IDE create IDE dependence? This was my greatest hurdle in accepting a good IDE, using the doc block, templating, and error stripe features as examples. My argument (and the argument of many developers) was that now I’m coding to quiet the code creation program, and it has nothing to do with how well I code. Finally one day it came to me, there are things the developers of PhpStorm know that I don’t know (and likely still are.) Once I got past my ego, I began to code to the style it was asking me to and began to code more accurately and efficiently. For other things, like an organization style that doesn’t follow PSR standards, I just . . . created a settings group for their style. So in a way I guess the answer to this question is yes, it does create a dependence, as much as having a wing man watch your back when you go into a shady establishment. It won’t write the code for me, but it helps guide me to write better code, and I listen.

These are just a few of the top reasons I love my IDE and how it continues to make me a better coder daily. There are still tons of features I haven’t touched and hope to eventually. From time to time I chuckle a bit at how awesome I thought it was I could make a web page or a Perl script with Notepad. Everyone knows it all at some point, right?

* Some organizations still use Dreamweaver to create pages. Whatever works, I guess, no offense intended.

** Actually you probably can, I just haven’t had the need or discovered it yet!