Know Your IDE

From WikiContent

Revision as of 09:23, 10 August 2009 by Kabutz (Talk | contribs)
Jump to: navigation, search

In the 80s, our programming environments were typically nothing better than glorified text editors, if we were lucky. Syntax highlighting, which we take for granted nowadays, was a luxury that certainly was not available to everyone. Pretty printers to format our code nicely were usually external tools that had to be run to correct our spacing. Debuggers were also separate programs run to step through our code, but with a lot of cryptic keystrokes.

During the 90s, companies began to recognize the potential income that they could derive from equipping programmers with better and more useful tools. The Integrated Development Environment (IDE) combined the previous editing features with a compiler, debugger and pretty printer. During that time, the mouse and menus also became popular, which meant that developers no longer needed to learn cryptic key combinations to use their editors, but could simply select their command from the menu.

In the 21st century, IDEs became so common place that they were given away for free by companies wishing to gain market share in other areas. The modern IDEs are equipped with an amazing array of features. My favourite are the refactoring tools, where I can select a chunk of code and convert that into a method. The refactoring tool will pick up all the parameters that need to be passed into the method, which makes it extremely easy to modify code. My IDE will even detect other chunks of code that could also be replaced by this method and ask me whether I would like to replace them too.

Another amazing feature of modern IDEs is the ability to enforce style rules within a company. For example, in Java, some programmers have started making all parameters final, which in my opinion is a waste of time. However, since they have such a style rule, all I would need to do is set it up in my IDE and every time that a parameter is non-final, I would get a warning. The style rules can also be used to find probable bugs, such as when we compare autoboxed objects with "==".

Unfortunately modern IDEs do not require us to put in a lot of effort in order to learn how to use it. When I first programmed C on unix, I had to spend quite a bit of time learning how the VI editor worked, due to its steep learning curve. This time spent up-front paid off hansomly over the years. I am even typing this article with VI. Modern IDEs have a very gradual learning curve, which can have the effect that we never progress beyond the most basic usage of the tool.

My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I'm typing my code, it will save me precious seconds to press Ctrl+Shift+I to inline a variable, rather than having to navigate a menu with my mouse. These seconds add up over time, making me much more productive than when I try to do everything the lazy way. The same rule also applies to keyboard skills - learn to touch type - you won't regret the time invested up-front.

Lastly, as programmers we have time proven unix streaming tools that can help us manipulate our code. For example, if during a code review, I noticed that the programmers had named lots of classes the same, I could find these very easily using the tools find, sed, sort, uniq and grep, like this: find . -name "*.java" | sed 's/.*\///' | sort | uniq -c | grep -v "^ *1 " | sort -r

We expect a plumber coming to our house to be able to use his blow torch. Let's spend a bit of time to study how to become more effective with our IDE.

by Heinz Kabutz

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools