Note: I understand that not everyone sees the entire spectrum of color. This blog post is focused on those who are able to clearly distinguish color differences. Perhaps my sentiments and suggestions apply to other visual triggers, which as I understand still exist for many of those diagnosed as color blind.
In 1986, my manager broke down and bought me my very first color monitor–a good deal more expensive than a monochrome monitor. I still remember him saying, “What a waste. What do you need those colors for?” I didn’t have much of an answer other than that it was “easier on the eyes.” Mind you, this is in the days where most software was geared for of 25×80 character-mode, green-on-black terminals. I hooked into an HP/3000 minicomputer, and the OS (MPE-III) wasn’t going to cough up anything particularly interesting with respect to colors.
Today, we take color for granted on our phones and other devices, and know how colors play a significant role in garnering attention and triggering reactions.
And yet. At a customer site where developers code using Eclipse, a first glance tells me that virtually all programmers accept the default color scheme provided; no questions asked. Sigh.
What do Eclipse default colors look like? Take a look:
Pretty uninteresting, eh? Black, purple, blue. Neither panache nor nuance. Nothing really stands out.
In fact, Eclipse emphasizes the wrong things. Keywords such as public
and void and throw are bold and purple, intended to stand out. Yet
keywords are often the least interesting thing about a chunk of code;
they are likely the thing I need to digest last. Even worthless comments
stand out with the Eclipse default color scheme! At least statics are
italicized; that seems OK. It’s also good that fields are colored–but
unfortunately they are dark blue, which contrasts little with the other
elements.
What should stand out in Java code? Fields, certainly. Where a class’s code interacts with fields is a key piece of information. As such, I configure my fields to be bright orange. For most people, the orange fields stand out like sore thumbs. Here’s the same code with my current orange-featuring color scheme:
Where parameters and local variables are used is also relevant. Being able to track on a specific color for each (gold and green, respectively) can make it easier to track state changes across the body of a method (although the Eclipse feature Mark Occurrences is more useful for tracking a specific variable).
The return keyword isn’t typically very interesting, unless it occurs
somewhere other than at the end of a method. No one uses underlining any
more, but I’ve found that doing so can help me more quickly spot an
early return.
The use of inherited fields–an odd practice, questionable at best (and one that this code doesn’t feature)–really stands out and annoys me, because I’ve made them bright red.
Emphasizing important elements is valuable, but so is de-emphasizing less relevant elements. Comments, too often not to be trusted, are now a light gray, barely visible. On days where I’m particularly affronted with the worthlessness of comments, I make them white.
While my color choices (which I change from time to time) suit me just fine, they might not suit you, however. You and I will disagree on precisely what the “right” things are to emphasize or de-emphasize. That’s ok. The key thing is to make a conscious, informed choice, and to pay attention over time to what the colors tell you about your code.
The world is full of color. Bring your IDE into that world.
You can find my current color preferences for Eclipse here. You can merge these entries into the file
./.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefsin your workspace.
Related posts
Pingback: The Compulsive Coder, Episode 1: The Stub Comment
Pingback: The Compulsive Coder, Episode 2: Syntax Coloring
Pingback: The Compulsive Coder, Episode 3: Typing Isn’t the Bottleneck
Pingback: The Compulsive Coder, Episode 4: You Create, It Assigns
Pingback: The Compulsive Coder, Episode 5: Extract Method Flow
Pingback: The Compulsive Coder, Episode 6: this Duplication is Killing Me
Pingback: The Compulsive Coder, Episode 7: Please AAA
Pingback: The Compulsive Coder, Episode 8: You Might Not Like This
