Collective Wisdom from the Experts 91
However, since they have such a style rule, all I would need to do to follow
it is set it up in my IDE: I would get a warning for any non-final parameter.
Style rules can also be used to find probable bugs, such as comparing auto-
boxed objects for reference equality, e.g., using == on primitive values that are
autoboxed into reference objects.
Unfortunately, modern IDEs do not require us to invest effort to learn how
to use them. 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 handsomely over the years. I am even typing the draft of
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, pressing Ctrl+Shift+I
to inline a variable prevents breaking the flow, whereas switching to navigate
a menu with my mouse interrupts it. These interruptions lead to unnecessary
context switches, making me much less productive if 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 -rWe expect a plumber coming to our house to be able to use his blowtorch. Let’s
spend a bit of time to study how to become more effective with our IDE.