Code is Mandatory

Moving between different screens of a small 12" iBook (1024×768), a 17" iMac (1440×900) and a 19" Windows 2000 (1280×1024) Desktop PC got me thinking about how I use screen real estate. My initial reaction was that the larger the screen size and the higher the resolution, the better I work.

I mean, with a large screen and high resolution, I can show more columns and rows in an Excel spreadsheet, fit more lines in a terminal window or see more of the code when editing a file. Or sometimes I have my program editor open on one half of the screen and the running version of the program on the other half.

However, I am starting to think that maybe bigger is not always better. I think I am using the 12" iBook reasonably effectively and for some tasks, I actually prefer using it instead of the 17" iMac. And that is what started me thinking.

Basically, there is a part of the screen that I am comfortable focusing on. Whatever I am currently doing, has to be done in this sweet spot. For me this is about 600×600 in the centre of the screen. Whatever application I am currently working on has to be positioned there. And whatever bit of text or thing I am working on has to be near to the centre of this sweet spot.

For example, Vim provides a way of showing multiple documents in separate windows within the main application window. However, I find that there is always one area of the window that I prefer working with. If there is something in the top right window, then I feel more comfortable moving that window into the sweet spot rather than looking at and typing into the window in the top right corner.

I prefer only focusing on one task at a time. If I am coding, then the entire screen should be devoted to coding. However, It doesn't mean that the whole screen should be one code editor. I am comfortable with supporting information panels surrounding a central working area. For example in Photoshop and Photoshop Elements, the information palette is very useful for showing, in real time, the size of objects when they are being resized and/or the RGB values of the pixel under the mouse pointer.

But I still like the area I am working on to be in the centre of the screen. And I don't like these additional information panels encroaching on the sweet spot.

I have been using editors in one form or another for about 23 years. And now I am using IntelliJ IDEA. Man, is it impressive or is it impressive. As Photoshop is to doing graphics, IntelliJ IDEA is to cutting Java code.

The most impressive thing is the overall usability. It has been designed and built with the developer in mind. Attention to detail is unreal. It is feature rich, but not bloated. I reckon that one could run an entire course on usability using this product as the case study.

As Alex Moffat comments about the product

I would imagine that IntelliJ is written using IntelliJ, and I think this must account for some of its success. Whatever is an annoyance to IntelliJ’s users will be an annoyance to its developers first, whatever makes developing the product hard or slow will make using the product hard or slow, and conversely whatever makes development easier and faster will make use easier and faster. If you can arrange it so that your software developers are also your first software users it can certainly help your product.

The keyboard customisation is fantastic. You can assign a keystroke to almost any action. The best bit is being able to assign keystrokes to a particular Ant task. So with one keystroke you can build your classes and deploy to the web container. What I thought was really useful is the way you assign an Ant task to a hotkey. Simply right click the Ant task and select the assign short key button, and Bob’s your uncle.

The refactoring, which I have only started to use, is impressive.

Paste in a snippet of code that refers to an package/class that you don’t have an import statement for yet, and it will prompt you to add the import statement and then do it.

Favourite features? The tight integration of Ant. The built in change control which tracks any changes you have made. The diff facility reminds me of the Apple Developer Tools difference utility. The ability to run on Win and Mac. The way it highlights variables that have been declared but not used. The ability to close all edit windows except for the one that you are currently working in.

A concept also implemented in Eclipse is the vertical bar (next to the scroll bar) that is a visual representation of the total file size. Any errors or warnings are highlighted on it showing the relative position of the error or warning in the file.

Surfed upon this nifty little tool that lets you key in some text, press a button and hey presto, you have some formatted HTML.

The link is now sitting on my Address Bar

Code completion comes in a number of flavours. One way is syntax expansion. Another way is recognizing code symbols (such as procedure and variable names). A third is to match strings in the current file.

<p>Syntax expansion is like providing a template and you fill in the blanks. For example, while coding Perl, if you type <code>if</code>, the editor will recognize <code>if</code> as a keyword and then expand it to <code>if (){ }</code> to suit your favourite brace style.</p>

<p>The second way is by understanding the program code. By recognizing the procedure names as you key them in, the editor can supply parameter information and prompt for parameter values. This is a real boon. But, the real kicker is when it starts recognizing procedure names from other project files or even standard code libraries.</p>

<p>The third category of code completion, works with arbitrary strings. Instead of retyping long strings, you type the first few characters and then get the editor to look for a matching string. Sort of like an incremental search. Except that you have the option of using the string that is found.</p>

<p>For example in <a href="http://www.slickedit.com">Visual Slickedit</a>, as you key in some text, you hit <code>ctrl-shift-<</code> and the editor will search backwards in the file to find the first matching text. If this is not the text you are looking for, hit <code>ctrl-shift-<</code> again to find the next match. Once you have found the right piece of text, you can either hit enter to use it or you can pick up more of the surrounding text by pressing <code>ctrl-spacebar</code>.</p>

<p>All three of these techniques are provided by <a href="http://www.slickedit.com">Visual Slickedit</a> and <a href="http://www.vim.org"><span class="caps">VIM</span></a>.</p>

Another feature that I can’t live without in an editor is “Go to Definition”. Basically, if you are examining a variable or procedure and you want to get to the definition, just press a hotkey and the editor will position you at the definition. If the definition is in another file, the editor will open and load the file and position you at the right place. You can get back to the place you came from by pressing another hotkey.

This feature is reasonably common and is found in Visual Slickedit, VIM, the Visual Basic Application editors (Excel, Word and Access) and even the Visual Studio .Net IDE (although this took some digging to find). Again, I haven’t found a way of doing this in BBEdit.

I am a simple guy. I can’t keep reams of detail in my head at one time. I like to see an overview of what is happening and when I need the detail, I want to get to the relevant bit quickly. When finished dealing with the detail, I want to return to the overview.

And I want to do this fast!

Any editor that supports this is a real saviour. Of the editors I currently use, Visual SlickEdit provides Selective Display and VIM provides Folding. Unfortunately I have not discovered this feature in the doyen of Mac editors BBEdit

I use it in a couple of ways. The first is to see the structure of the code i.e. what can be called and what calls it. The second is to place the cursor on word, hit a hotkey and have all occurrences of the word displayed. Hit another hotkey and the entire file is displayed again.

So what you say. A grep or find all occurrences does this already. But the difference is that selective display shows the results in the same window. From a coder’s perspective, it looks as though all lines that don’t contain the word have been hidden and the ones that do remain visible. You can now use normal cursor navigation to get to the line you want. Once there you can edit or even make changes.

To try out selective display in Visual Slickedit, look at the View Menu and bring up the selective display dialog. To learn about folding in VIM take a look at the VIM online documentation.

Wow! Does Launchbar let keyboard junkies rock or what!!. This utility is like a combination of the VSlick alias facility, the Windows run command and the Mac OS X dock all rolled into one.

The VSlick alias facility lets you get at files or directories quickly using your specified aliases. The run command lets you quickly start applications, open directories or files. The dock shows you what’s running and acts as a sort of a repository for favourite applications.

Launchbar lets you get at files, folders, urls and applications with the keyboard using easy to remember aliases or mnemonics. Now, using the keyboard I can quickly get to the application I want without having to watch how I get there.