The Compulsive Coder, Episode 2: Syntax Coloring

eclipseColorWheelNote: 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:

eclipseBlah

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:

eclipseColor

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.


Previous Compulsive Coder blog entry: The Stub Comment
Next Compulsive Coder blog entry: Typing Isn’t the Bottleneck

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.prefs in your workspace.

The Compulsive Coder, Episode 1: The Stub Comment

Some things keep coming back, such as facial hair, indigestion, and platform shoes. And for me, Java. I’m once again back in the Java world for a current engagement, and accordingly I’m again working with Eclipse.

The instant I began pairing with folks on Eclipse, my “Felix sense” kicked in, and I became unbearably indignant about the horrible defaults that too many developers simply accept. No one could tolerate more than one Ungar-ism at a time, so in this post I’ll focus on a real simple one:

public Holding findBy(String key) {
   // TODO Auto-generated method stub
   return null;
}
422769556_4094cecb03_m
Image courtesy Adam Engelhart; license

My immediate reaction was probably much like this.

A stub comment! Egads! Why in the world would people pollute their code with stub comments? Coders use their powerful IDE to auto-generate a new, empty method, but then have to waste time picking up and deleting these ugly, useless little stub comments. And horror of horrors, sometimes they don’t–I just saw a screencast where the programmer didn’t even flinch as he created and abandoned a stub comment!

The reason? Maybe it’s the 45-second effort Eclipse requires to turn off these wonderfully useless “auto-generated method stubs.” Or the painfully inadequate system for saving and restoring preferences like this (they’re all over the place), a consideration that crops up whenever you create a new workspace.

Well, I don’t want you to be able to say “I didn’t learn anything from Jeff’s blog.” Let’s start incrementing some Compulsive Coder Principles and Techniques.

Compulsive Code Principle #1
A laziness mentality is acceptable as long as you really do minimize as much work as possible. Creating stubs that need to be deleted isn’t maximally lazy.
Compulsive Coder Technique #1
Open the Eclipse Preferences dialog. Select Java->Code Style->Code Templates. (You can find it quickly by typing code templates and pressing Enter). In the right-hand side of the dialog, select Code->Method body. Click the Edit… button. Change the template’s pattern from:

// ${todo} Auto-generated method stub
${body_statement}

to:

${body_statement}

Click the OK button.

An alternative choice: Change the template to:

throw new UnsupportedOperationException("not yet implemented");

It’s an uglier version of a stub! … but, it’s so ugly it forces you to get rid of it. Where it can be helpful is in keeping you to the red-green-refactor cycle of TDD–the thrown exception will most certainly result in a failing test.

Whichever route you choose, similarly change the Code Template for Constructor body and Catch block body.

I bet you won’t ever miss the auto-generated method stubs!

Stay tuned for more Ungarisms.


Next Compulsive Coder blog entry: Syntax Coloring

New PragPub article: Half of a Third of a Century in TDD

pp-16-07PragPub celebrates their seventh anniversary issue this month with a large collection of feature articles–pieces by Ron Jeffries, Alistair Cockburn, Allen Holub, Michael Nygard, Jonathan Rassmusson, Venkat Subramaniam, and me (I am honored!)–reflecting on the past, present, and future of agile software development. (And there’s more! …the issue also includes articles by Johanna Rothman, Michael Swaine, Marcus Blankship, and Natasha Murashev.)

Visit The Prose Garden to grab a copy for less than a couple bucks, or to subscribe to PragPub at a measly $20 per year. You owe it to yourself to stay current with this stellar publication.

I chose to write about my feelings regarding TDD, a practice I’ve embraced for now half of my fairly long development career (Ron still has me way beat). In Half of a Third of a Century in TDD, I talk about the reasons I’ve personally found TDD to be an indispensable practice.

(I’ve linked just my article… thanks Swaine for the permission to do so!)

Atom