On a Steel Horse I Ride: NetBeans PHP

Years of experience have made me believe that exploring unpopular solutions is a waste of time; if a solution has not been able to attract a community, there is usually a reason. For that reason, even knowing that NetBeans had a PHP editor, I stuck to Zend Eclipse like a well beaten spouse. Who cares if it freezes up, loses synergy with Subversion, looks like a brick and has gazillion options that look like they should work (refactor) but don't? Zend supports it and Zend knows best. But guess what? NetBeans doesn't suck after all.

^{click to enlarge}

I didn't go down easily: I finally hit the wall. I can't view my projects in the Zend editor. I am locked in a subview I created by selecting "View selected in new window" and for some reason I can't get out of a targeted view of a single project  that is NOT the one I want to work on and oh by the way, the SVN bridge is broken (Where did my little SVN numbers go? Oh god not again) and I think I might go over to Zend and give them a piece of my mind (I know where you live! you people are not safe!).

So I pulled open my NetBeans IDE I was using on JavaFX and pulled in the PHP module. I am not paid to debug IDEs: I'm paid to write code and I am behind because instead of writing PHP files I spent an afternoon playing with Eclipse.

I open the plugins palette, click PHP and I'm done. No screwing with Subversion; of course I have to restart the IDE but I do so in half the time it takes to load Eclipse (probably far less than half.)

I select my project directory and in a minute or so, its ready to get worked on.

I open the persistent, dynamic subversion palette -- there is a list of all the files that have been worked on since my last submission. Wow -- where is this in Eclipse? I actually have to commit to get this view and its far from instant. This is good. And I have yet to hit a performance lag -- I save a lot of files, click the "submit" button on the subversion palette. By the way, everything looks like a Mac aplication, or better.

The diff view is quite nice as well. Just to try and intentionally make things difficult I autoformatted the entire document (a notorious diff-buster -- often swaps tabs for spaces or vice versa) before running a diff, but it still focued on the true differences (meaningful additions, subtractions, and revisions).

Code completion is there as well -- control-space gives you lists of all project defined classes and PHP functions that begin with the already typed characters (and you can continue typing for dynamic choice refinement). Mac users note -- this is the control key, not the command (clover) key. 

The syntax highlighter does show my errors -- however it doesn't show logic errors such as "use before def." Guess I better make sure I don't do stupid stuff. But honestly the logic error detector helps sometimes but in other contexts it throws a fair amount of chaff (false negatives) out there.

And I do miss my prefab templates for properties etc. -- or did until I found out you can literally drag a code block onto the palette and instantly create your own templates. It doesn't have variable slots like Eclipse, but I can deal with that. (the "constructor" template in the shot above is mine.)

I'm not calling NetBeans an Eclipse killer; I'm still dependant on the Zend toolkit for debugging (but I do understand that NetBeans' xDebug is a viable candidate -- I saw a demo of it at a PHP Meetup and it seemed pretty valid.

I'll keep this up to date as I use NetBeans over the coming week. But so far, I am noticing the good parts and the absence of Eclipse general fuckedness.

The xDebug Factor

The ability to step through your code and inspect variables using xDebug is invaluable; there are a lot of bugs that would take forever to find without this technique, and watching your code branch through various steps is just invaluable for finding errors, performance issues, or behaviors you just wouldn't predict.

The xDebug plugin allows you to step through your code and inspect variables at every moment in the execution cycle. You can also throw in breakpoints to rush to execution at a various task. (If you have breakpoints, consider disabling the preferences/php/stop at first line option; it is tedious to have to crank the first jump at each cycle.)

Variable List

As you step through your code a scrollable list of variables in the current scope (sorted alphabetically) appears with foldouts for structures like arrays and objects. (Objects incedentally are not annotated with the class name -- kind of annoying) Note that variables with NULL  values are NOT listed.

Call Stack

Most calls end up "nesting"  as functions call other functions, or call functions in classes that call other functions, etc. The call stack helps you trace the depth of your call heirarchy. Its analogous to the stack dumped by an exception.

Bugs that xDebug cannot handle

If you fail to satisfy an interface in a class definition, xDebug fails with deafaning silence. No errors thrown, no error log comment -- and no feedback through xDebug. Zend's debugger seems to be the only device that detects this condition. (and as of September 2, 2009, the Zend Debugger toobar doesn't work on Mac's latest Firefox build.)

Similarly, having duplicate declarations of the same method fails unhelpfully.

If you don't use interfaces (or don't screw them up), xDebug is a fine and viable debugger. If you don't use debuggers at all, you MUST start! it totally cuts hours out of the WTF factor of coding. This page should give you a good running start on getting xDebug up and running.

Why use any IDE?

A lot of coders still rely on text editors and console actions to interact with code. If you have never hit that wall, this might seem like the best way to develop and at a certain level it may very well be. here are "the walls" that drive me to IDEs.

• Autocompletion: remembering the syntax of a deep OOP system can be troublesome -- autocompletion (often) helps you recall syntax and names of object methods. 
• Error Hinting: Seeing your errors underlined in red solves many problems before they occur.
• Common SVN tasks such as updating, committing, and reviewing logs on a given file are much quicker using an IDE.
• Debugging with an IDE is much more effective.
• Templates for things like object parameters really saves time and eliminates idiot typo errors when punching out boilerplate code. the templates I created for Eclipse work verbatim in NetBeans.
• Syntax Hilighting, while availble now in most text editors, emphasizes structure to your advantage.

The biggest argument for an IDE is that there are simply no arguments against one. An IDE is at heart a supercharged text editor. You do not HAVE to use any of its advanced features -- both Eclipse and NetBeans wrap transparently over existing source, and while they do have a lot of features (way too many for some) they dont make you use them -- they are just there if you need them.

Performance Tuning NetBeans

Net Beans can dog a little after a while of use. I found two things which decrease the frequency of lag spikes:

1. Close unused projects. NetBeans scans ALL your projects EVERY time you start up for metadata (class locations, variables, functions, etc.) for use in autocompletion. Closing a project doesn't delete it -- you can always open it later to continue work -- but it does reduce the number of live projects that get scanned in this way.
2. Turn off Autocomplete. After your project gets to a certain size, the possible completion maps -- and the choices that must be filtered through every time you type "$" - gets unwieldy. Turning off all the options under "Preferences/Editor/Code Completion" will reduce the number of times this is triggered. (you can probably leave in "Close Brackets" if you like.) You can always manually complete your code by choosing source/autocomplete (or hittng the shortcut noted therein) if you need a hint.