For me, the IDE goes back to the days of Borland’s Turbo Pascal and Turbo C. They didn’t have GUIs much less GUI form editors, HTML wasn’t yet invented and I don’t remember the text editor being anything special. What turned them into IDEs was the super efficient work flow… A typical “Hello World” program was mostly a matter of typing in some code and pressing the Run key. If you wanted to debug, you would set your breakpoints right in the editor, then press the Debug key to start your program under the integrated debugger. When your program expanded to more than one file, IDEs had simple project facilities that did a good job of bridging the gap between “Hello World” and tools for large projects like “make” and “nmake”. Later, when the GUI APIs got so big that nobody could keep them all their head, integrated documentation became critical to a smooth workflow. For better or worse, I’ve become addicted to code completion. It doesn’t work as well for dynamic languages like PHP, but some code completion is better than none.

So, when I think IDE, I think of an all purpose application that makes a programmer’s day-to-day workflow smooth and efficient… I find that anything I can do that cuts down my “cycle” time improves my productivity (and my mood).

Every since the days of Microsoft C 6, Microsoft has always had the best IDEs for C/C++ and Windows development. Their documentation is better and better integrated, their compilers are way, way faster and the general work flow is always the smoothest. Visual Studio continues this trend for C/C++ and now C# development – it sure is easy to crank up a new C# web application and start debugging.

As as web host, I end up working on a lot of different sites. These days, there is a lot of PHP code out there and I end up spending a fair amount of time working on PHP projects. For most my really big projects, I typically use C# and Asp.Net, so I have Visual Studio handy. With a few registry tweaks to syntax highly PHP code, Visual Studio works OK as a text editor for PHP, but I wouldn’t call it a true PHP IDE. For one thing, there is no integrated debugging support. You can kind of get project file support (PHP files can be listed), but the only integrated documentation is for HTML and JavaScript (and sadly, the Microsoft documentation on these frequently referenced topics is IE centric).

So, several times, I’ve set out on a mission to find a IDE for PHP programming. Last time around, I gave up and stuck it out using Visual Studio as a text editor. After this last round of reviews, I ended up buying NuSphere’s PhpED.

When you are in the world of “free” software, it is tempting to stick only to “free” tools. However, in the case of IDEs, I just couldn’t find a free one that worked well enough to be better than Visual Studio.

One area where PHP needs a lot of work is support for debugging. The basics are there, but having to fiddle with various debugging DLLs is a hassle – debugging information has been standard for binary programs for years – how hard could it be to figure out a standard debugging API for IDEs to use?  Having to use query strings to initiate a debugging session is a serious design mistake. With all the rewriting and other things going on, fiddling with URLs just doesn’t make sense. Visual Studio is able to attach a debugger to server code in just about any situation – PHP and its IDEs should make this as easy.

The ability to automatically reformatting HTML in both blocks and full pages is very handy… plenty of tools (like content management systems) make a real mess of HTML. And, for better or worse, you end up using some of these tools over and over so it’s not like you can fix the code just once and be done with it.

Below are some notes I made as I tried out various PHP IDEs:

Eclipse PHP

No cost and open source

Cross-platform (Java)

Attractive

Amazingly slow and memory hungry – based on Java and requires a Java Runtime to be installed.

Integrated PHP reference uses the php.net web site so, it requires Internet access and is slow.

No integrated CSS, HTML, JavaScript or DOM reference

No WYSIWYG HTML editor, no integrated page preview, either

HTML reformat is weak and not customizable

Go to definition doesn’t work reliably

Code completion doesn’t work reliably

Code completion doesn’t work in CSS files.

HTML code completion uses upper case for tags and attributes.

Subversion integration is slow and shows incorrect status

Crashes frequently

Debugger worked for a simple page, but did not work in a real project

Komodo IDE

Attractive 

Cross-platform – interesting choice of Firefox engine

Reasonable performance and memory usage

Subversion integration is quick and accurate

Once configured, PHP syntax checking is very handy

No WYSIWYG HTML editor, but the integrated page preview is well done

Go to definition doesn’t work reliably

Code completion doesn’t work reliable (does not seem to follow include paths).

No integrated PHP, CSS, HTML, JavaScript, DOM or MySQL reference

Copy and paste of files in Projects tree fails with no error message

Deluxe syntax PHP + HTML syntax highlighting.

View unsaved changes off File menus is a great idea! The integration of this feature with the recovery of unsaved changes after a crash is nice, too.

Extremely annoying rendering bugs in the text editor

Code completion for CSS and HTML

CSS code completion is not very good. For example, once you type “margin:”, you get a drop list of choices instead of a description of the arguments for the margin style.

HTML code completion is annoying because it defaults to upper-case tags (is anyone still NOT using xhtml for new code?)  and does a poor job of suggesting closing tag (typing “</” does not give a drop list of closing tags).

PHPEdit

Attractive

Reasonable performance and memory usage

Subversion integration does not work out of the box.

Integrated PHP and MySQL reference is nice, no integrated CSS, HTML, JavaScript or DOM reference.

The ultra-deluxe syntax highlighting changes the highlighting rules depending on where the caret is placed – very handy for files with integrated HTML, PHP, CSS and JavaScript!.

No code reformat for any language other than PHP.

No code completion for any language other than PHP (CSS and HTML would be nice).

Go to definition (“Jump to declaration”) doesn’t work across files.

Cannot right click to open a file via a simple require() declaration.

No heroics to resolve PHP include paths for code completion.

DB Explorer is an interesting idea, but I think the most important thing about a database to a programmer is the column definitions (names, types, lengths) and, other than seeing the column names in the DB Explorer tree, there is no way see the column definitions for a table. Manually inputing a “show columns from” query into the SQL tab didn’t work – you end up with an “Invalid SELECT statement” error message in a message box.

Non-standard Alt+Tab behavior is not very useful.

PhpED

The debugger actually works! But, it’s a lot more hassle than it should be.

CSS code completion is OK, but Visual Studio is still the best.

PHP code completion is reasonable and follows include paths in some cases.

Integrated documentation for CVS, CSS, HTML, JavaScript, MySQL, PHP, PostgreSQL  and Smarty – very nice!

The project system works OK for PHP projects, but it is cumbersome and has odd limitations (you can’t copy and paste files and folders, for example). 

Non-standard Alt+Tab behavior is not very useful.

No Subversion integration

No integrated code reformatting (help provides a good explanation of how to integrate 3rd party tools, but these don’t seem to work well, either).

One of the real selling

The ability to edit files via FTP or SSH file transfer is nice.

Integrated support for SSH terminals is nice (but why, oh why is copy and paste so difficult?)

Other Suggestions

A lot of people use Dreamweaver to edit PHP code. I guess if you come from the design world, this makes sense. Syntax highlighting for PHP is pretty poor, but I will say that Dreamweaver has the best support for code reformatting.

Notepad++ has a good syntax highlighting of many languages and there are add-ons to support FTP and integrated spell check.

Logging in Asp.Net

Logging in Asp.Net is confusing because Microsoft uses the word “trace” in two different contexts:

When a page is rendered and HTML generated, you can have the Asp.Net engine add a bunch of additional page state information to the generated HTML. In your application’s web.config file, this is the tracing that is controlled by
<trace></trace> under <web.config></web.config>. In practice, I don’t often find this kind of tracing helpful, but when I do,  I put the following tags in web.config to make it easy to turn on or off:

<system.web>
  <customErrors mode="Off"/>
  <trace enabled="false" requestLimit="10" pageOutput="true" traceMode="SortByTime" localOnly="true" />
  <!-- ... -->
</system.web>

With these tag in place, you can enable and disable page state tracing (more like a dump if you ask me) by changing enabled=”false” to enabled=”true”.

The other use of the word “trace” is related to the more traditional form of logging via .Net Debug.Write and Trace.Write. Essentially, under Asp.Net, you use Debug.Write and Trace.Write as usual. Contrary to the MSDN documentation, the default compiler options for Asp.Net web applications allow Debug.Write output in Debug builds and allow Trace.Write output in both Debug and Release builds. If you run your Asp.Net application under the Visual Studio debugger, you will see that Debug and Trace output is redirected to the debug output window without any additional configuration.  As with any use of .Net logging, you can setup tracing to various outputs either in code or via your application’s configuration file. To configure your Asp.Net web application to log trace output to a file (for use with other tools), place the following into your web.config:

<system.diagnostics>  
  <trace autoflush="true">    
  <listeners>    
  <add name="MyApplicationTracer" type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="MyApplicationTrace.log" />
  </listeners>
  </trace>
</system.diagnostics>

This will result in debug (in debug builds) and trace output going into a file named MyApplicaitonTrace.log in your web site’s root folder.

Logging in .Net Command Line Applications

Since .Net applications are easy to create and fairly expressive, I often write small command line utilities that, on other platforms, I might create as shell scripts.  Here are some handy code snips that I use to handle simple logging for these applications:

namespace Program1
{
 ///


 /// Prepends each output line with the time
 ///
 public class TextWriterTraceListenerWithTime : TextWriterTraceListener
 {
  public TextWriterTraceListenerWithTime()
  : base()
  {
  }public TextWriterTraceListenerWithTime(Stream stream)
  : base(stream)
  {
  }public TextWriterTraceListenerWithTime(string path)
  : base(path)
  {
  }public TextWriterTraceListenerWithTime(TextWriter writer)
  : base(writer)
  {
  }public TextWriterTraceListenerWithTime(Stream stream, string name)
  : base(stream, name)
  {
  }

• Simple Tracing and Logging for Asp.Net and .Net Command Line Applications

Wow, some programmers go crazy about logging.  Do a Google search for “.net logging” and you’ll see what I mean. Some of these libraries are huge.  While some applications may really need all the complexity these libraries offer, I have seen it severely abused on more than one occasion. Crank up a copy of Blackberry Enterprise Server (BES) and let it run for a week or two. You’ll find your Windows Event Viewer overflowing with all types of mysterious, confusing and generally useless messages.  In addition to the constant Event Viewer spew, if you let BES run unattended, you’ll eventually find that your BES hard drive is literally overflowing with many different log files all with obscure names and even more obscure contents.  Exchange Server has a similar problem where some logging is done in Event Viewer, other logging is done to text files. And none of the Exchange Server logging options ever seems to enable the simple email flow messages you need for common day to day administration tasks that I take for granted on our Linux email servers.

Is all this really necessary? After 20 years of programming, I’ve found that the following simple API is more than enough for all my needs:

LogMessage(componentName, severity, format[, formatArg1, formatArg2, ...])

Depending on your programming language and coding standards,  this simple function may need to be wrapped in a class. You might also wrap the function call in a macro to allow for conditional compilation and to keep from having to pass the same componentName over and over.

With this API in mind, you also need a fairly simple configuration system to automatically prefix the messages with time, date, and thread ID and direct messages to some combination of syslog, Windows Event Log, a text file (just 1, please!), console, system debugger, email (for Alerts – see below)  and user defined functions.

The componentName argument is best handled as a single string determined by the programmer. This keeps things simple, yet gives the programmer a lot of flexibility in both the presentation of messages and the ability to filter messages.

There is no sense in going overboard with adding lots of flexibility for the severity argument. It’s best to spell things out and keep them simple. You’re never going to get a group of programmers and system administrators to agree on the difference between “error”, “critical” and “alert”. I use an enumerated type with the following values:

• Debug – Low level messages of interest only to programmers. It should be easy to enable and disable output of debug messages. The only reason a user would enable debug messages is to create a log file to be sent to a programmer. Information messages may be sent to log files and/or UI elements, but they should never be sent to system facilities (such as syslog or the Windows Event Log).
• Information – Messages that let users know the program is doing what it supposed to do. Information messages are of most value for services where there is no interactive UI to demonstrate that the program is working properly. However, interactive programs can trap Information messages to display status messages during length operations. Information messages may be sent to log files and/or UI elements, but they should never be sent to system facilities.
• Warning – Messages to let the user know the program encountered a problem, but the problem is not completely unexpected. The program should be able to work around problems that result in warnings (possibly by retrying at a later time).  Warnings should be sent to all log files and system facilities.
• Error – Messages that need the user’s attention.  Errors should be sent to all log files and system facilities.
• Alert – Messages that need the user’s immediate attention.  The user should be woken from bed. Alerts should be sent to all log files and system facilities.

I’ve found that the most difficult choice is between Error and Alert. For example, at an ISP, email server problems are almost always Alert messages, while for home users or small businesses, email problem can wait until morning. If it’s not obvious, make everything an Error and assume the administrator will have some way to filter the messages to decide for himself which Errors are really Alerts.

The data type for the format argument depends on your programming language and I8N requirements and tools. For ease of programming, I much prefer to use String.Format style format strings (printf strings in C++ and PHP code).  

I could write an entire article about choosing the best method for formatting strings for output, but quickly:

For production applications, use formatting rather than composition:

• Do use: string output = string.Format(“A = ‘{0}’”, a)
• Do not use: string output = “A = ‘” +  a + “‘”;

As much as I love C++ and Bjarne Stroustrup (and understand the arguments for the ability to format user defined types in a safe and type safe manner), favoring formatting over composition leads to programs that are easier to write, easier to read and easier to translate.

If you need to translate your program into other languages, there are two schools of thought for handling literal strings that need to be translated:  

• In the Windows/Mac style system, each string is manually assigned a unique integer identifier and all strings are stored in a database of some kind (typically application resources). When the you need a string, you program a call to the database API, passing it the unique integer ID of the string to be retrieved as a lookup key. 
• In the gettext style system (UNIX like platforms),  translated versions of the strings are still stored in an external database (though typically in simple text files). However, the original strings created by the programmer (often English) remain in the code. The original strings are used as the lookup key to retrieve the translated string.

Kind of like the difference between using raw char* vs. a string class for low level string operations, the Windows style system is the most resource efficient. The gettext system is less tedious to program with and, for better or worse, more tolerant of errors. You can find tools to retrofit your old code for either style. Also, there are various kinds of tools for both systems that allow translators to translate application strings without access to program source code.

Since my API is a lowest common denominator, mapping my simple API to syslog and the Windows Event Log is fairly straightforward.