Here’s a few tips that I think are useful to IDL programmers who have basic knowledge of IDL, but want to start doing more sophisticated tasks.
- Use objects. I suppose I should write a more lengthy defense of object-oriented programming at some point, but for now, I think it it clear you have to resort to a lot of hacks and work-arounds if you never use objects.
- Document the interface of your code (for example with IDLdoc). It’s handy to have a searchable, browsable collection of (at least) your routine headers. Better yet if you put in documentation to explain what routines do, what the arguments are, etc.
- Test your code (for example with mgunit). You’re going to run your routine at least once to make sure it works anyway, right? Why not put that code in a file that can be run as needed to make sure your code still works after IDL updates, changes to your code, changes to underlying libraries, etc.
- Put an example main-level program at the end of your code. Placing a main-level program after all the routines in a file is an easy way to put a working example in the code. Run it from the IDL prompt with:
- Don’t crowd a widget program’s “state” structure with widget IDs and object graphics references. Use
find_by_uname(for widgets) and
getByName(for object graphics) to find them.
- At least be familiar with some of the tricks involving
HISTOGRAM. Know enough to realize when you need to start looking at through the histogram tutorial.
- Use conditional breakpoints.
I don’t believe they are available from the Workbench interface anymore, but the
BREAKPOINT routine still allows them.
I previously made a similar list of tips for beginners.