I have accumulated the following tips over years of dealing with new IDL users. They are all fairly simple ways to get more out of IDL. Some of them can’t really be described in a paragraph, but it gives you a starting point of something you might want to check out later. If you have more suggestions, feel free to add them in the comments.

Put code in files. Your choices are to write main-level programs, batch files, and normal procedures/functions. The bulk of your code should probably be in procedures and functions, but there are certainly reasons to use both main-level programs and batch files. Main-level programs are handy for setting up a situation and allowing you to enter commands accessing the variables in the program after it has run. Batch files are good for including code that needs to be typed in multiple locations.

Place your main routine last in a file and name the file the same as this routine plus a .pro extension. Alternatively, you could put each routine in its own file with the same name as the routine plus a .pro extension. Following this advice will save a big headache someday. When you manually compile your code, this tip doesn’t matter. Do this if you want IDL to automatically find your code (and you will eventually, probably tomorrow).

Be aware of short integers. The default integer in IDL is a 16-bit (“short”) integer which has a range of -32,768 to 32,767. It is used in situations like:

n = 5

where no specific type of integer is specified. If you want to change the default integer, put

compile_opt defint32

at the beginning of every routine where you want to change the behavior. Or, always specify the type of integer you want, like

n = 5L

to create a long integer (32-bit).

Put compile_opt strictarr at the beginning of every routine you write. The explanation is a bit subtle, but doing this will save you a day’s work sometime. It comes down to the fact that both arr(5) and arr[5] can index into the array arr. But IDL can get confused trying to figure out if arr(5) is indexing into an array or a function call. The solution is to always use arr[5] for array indexing and to tell IDL that you will be doing this with

compile_opt strictarr

at the beginning of each routine. (This is not a global setting since there is plenty of legacy code, including IDL’s library, that would not work with it.)

Learn to use WHERE. Any time you want to find the elements of an array that match a given condition (naively, you would have an IF statement inside of a FOR loop), you should try to use WHERE instead. (Also, make sure to use the optional count parameter and check to make sure it’s greater than zero before you index an array with the returned indices.)

Use keywords in routines you write. Keywords are a useful feature that differentiate IDL from many other languages. Generally, keywords are optional inputs or outputs, though IDL does not enforce it. Also, learn how to use N_ELEMENTS, ARG_PRESENT, N_PARAMS correctly to check parameters.

Use array operations. This is called vectorization and is key to writing efficient IDL code. For example, if arr is an array, then

result = arr + 1.0

will add 1.0 to each element of arr. Almost all of IDL’s operators will handle array or scalar operands. It is much faster to use them with array operations than to loop over the elements and use the scalar version.

Use the online help. All the documentation is now online and nice looking on all platforms. It is accessible with ? from the IDL prompt. It is particularly good at documenting the library API, but it is the first source for everything IDL.

If you’re on UNIX, consider using IDLWAVE. The current IDL development environment is “somewhat lacking.” If you want more than just a commandline interface, try Emacs with IDLWAVE mode installed. Emacs traditionally has a steep learning curve, but if you’re not really tied to an editor right now, it’s probably worth learning.

Have a style. A style will give you guidance in many of the things that IDL doesn’t care about: names of variables/routines, capitalization, indentation, comments, etc. Unfortunately, RSI ITTVIS doesn’t provide a style since the library routines are written in a myriad of styles. There are some third party style guidelines.

Learn to use the debugger. The debugging environment is a main advantage of the interactive nature of IDL. It can be used from the command line or the DE (although, I must confess that I like to push buttons in the DE in this respect of programming). One key point here is that runtime errors drop the command line to the level of the offending statement. You can enter IDL statements at the command line as if they were in the original program. This is really handy in examining the situation to find the error.

Use single quotes for strings. Both single and double quotes are valid for literal strings, but double quotes have some extra odd uses, like specifying integer values in octal. So for instance, in the following

IDL> age = "22 years"
age = "22 years"
          ^
% Syntax error.

IDL thinks that "22 (octal 22 or decimal 18) is being assigned to age. To bypass this mess, just always use single quotes for strings.