In writing software, there are a few words you see in your symbol names more than any others:

• First, Last
• Next, Previous
• Begin, End
• Push, Pop
• Draw, Erase
• Add, Remove
• High, Low
• Yes, No
• Stop, Go
• OK, Cancel
• And, Or
• Up, Down
• Left, Right
• True, False
• In, Out
• Plus, Minus
• Fixed, Floating
• Open, Close

Each pair is opposite in meaning and different in length. When I study these pairs of words, I can’t help but be absolutely convinced that the inventors of the English language gave absolutely no consideration to the fact that (thousands of years later) there will be millions of programmers writing code in mono-spaced fonts and really, really wanting it to line up nicely, but thwarted by this lack of similarity in length.

If you are smart, you’ll stop reading now, the rest is a bit predictable and boring. The point of this article is that it is annoying to write code that looks like this.

So much is it annoying, that the monosyllabic, four letter abbreviation “Prev” has nearly became a universally accepted substitute for “Previous”, within the confines of software, at least.

You are still reading? Ok, fine. Really, if you have been programming at all, you have already encountered this, and you know everything I’m going to say. You could have stopped at the title, in fact.

There are a few exceptions to this rule of opposites — Get, Set, North, South, East, West, Insert, Delete, Internal, External, Throw, Catch. Get and Set are so loved, I think for their matching size and rhyme, that we have invented new words for those types of functions (getters and setters). Of course, “setter” isn’t a new word, but prior to the explosive discovery that both get and set had three letters, a “setter” usually referred to a breed of canine. What is really impressive are the applications you might find map directions applied to. Not in SlickEdit, but elsewhere, I have seen North and South used for cursor movement where you would have logically used Up and Down. Likewise, East and West have been applied to where you might logically think Left and Right and even, Next and Previous. My theory is that to some, alignment is a worthy cause, so much so that you may chose a naming scheme which involves a level of indirection.

Certain shell languages have employed mirror spellings of keywords as a level of indirection between opposites and like-sized keywords. Thus you find do, od, if, fi, case, esac. The first time you see it, you will think, “What is an esac? If it’s anything like an email, I do not want to touch it.” But, it may grow on you, as the Bourne shell has grown on Unix.

Acronyms were all the rage in the old days when it really did matter that your code be small and fit on a punch card. Some continue to survive and are frequently used, such as Gt for greater, Lt for less than, Eq for Equal, Ne for inequality, Hi for high, Lo for low, T for true, F for false. Sometimes you see hybrid abbreviation pairings, such as Up, Dn, or Add, Del.

Some programming language designers have addressed this issue with more symbols. APL is well known for it’s elaborate character set, “⌊” for floor and “⌈” for ceiling, for example. C++ introduced operator overloading and programmers followed that path of slow, destructive insanity towards standardizing — and ++ as next and previous iterator methods, among others.

But, in the end, this problem of opposites being different is not a programming language issue, it is a natural language issue. It’s a problem with the English vocabulary. And there is little we can do about that. Until we find a natural language invented by linguists who really thought about writing code in monospace fonts, our code will never be aligned as well as it could be.

As a developer, I look for tools that help me get things done quicker, and make tasks easier. This series of articles shows you how to take a handful of the features in SlickEdit Tools for Microsoft® Visual Studio® and use them to effectively put together and perform a code review.

I can’t say that I’ve met too many developers that eagerly looked forward to reviewing code. Most developers understand the importance of code reviews, but many have experienced the pain of poorly run code reviews. Although SlickEdit Tools does not have a “code review” feature, it provides several features that can be used together to make a code review run smoothly. A well done code review process can be the difference between developer loathing and developer buy-in.

Because code reviews are such a big topic, this article will focus on some of the steps that lead up to a code review. Code reviews typically focus on the work of a single developer, so we’ll start there. We are going to be code reviewing the developer with ID SLICKEDIT\shackett (or Scott) in source control, and we’ll be reviewing his work since March 3, 2008, which is the date of our last (fictional) release.

Finding the Best Files to Review
Our first challenge involves finding the set of files that Scott has worked on since March 3, 2008. We’ll use the Find Version feature of the SlickEdit Tools Versioning Toolbox as our starting point.

Find Version allows you to query versions of the source code files in your solution. The code review organizer can use this feature to find an ideal set of files to review. Simply click SlickEdit > Find Version to bring up the Find Version tool window. For this example, we’ll find versions with the following criteria:

• Since date: Finds all versions checked in since a particular date, such as the last release.
• Developer name: Finds all versions checked in by one or more specific developers.

These two criteria are used to find all versions checked in by Scott during the latest development cycle (March 3, 2008 - present).

No development team has the resources to code review every file in that list, so it’s important to find the best candidate files to review. Therefore, the next task is to look through the results and find a sampling of files that represent the most important or complex code. You might also include some files that have a high number of check-ins by that developer, which indicates high rate of change, or churn. These are the ideal candidate files to be reviewed. Email the names of those files to all developers who will be participating in the code review.

[Click here for the full size image]

In this example, PackageBaseWhidbey.cs has had several changes and is a very important file, so we’ll include that in our code review process.

Loading the Files to Review
When a developer is ready to prepare their review comments, they should close all other files and open the files in the list sent by the code review organizer. This can be done quickly using the Load Files feature in the Editing Toolbox, which allows you to quickly filter the list of files in your solution and open the ones you’re looking for. Click SlickEdit > Load Files to use this feature.

By typing “basew” in the filter, we narrow down the files in the list to only those that include that text in their file name. We’ll select PackageBaseWhidbey.cs and open it.

Isolating a Developer’s Work
One of the most difficult things to do when reviewing the code of another developer is actually identifying the work that that developer did, especially if it was done as part of a team. Once you have PackageBaseWhidbey.cs open, we’ll use the Version Visualizer feature of the Versioning Toolbox to see which parts Scott has worked on. Click SlickEdit > Version Visualizer to show this tool window. Next, select “Default User Scheme” in the drop down at the top of that tool window.

The versions of the file will be processed and the tool window will list the names of all developers who have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify who wrote each line of the file.

[Click here for the full size image]

You can find Scott’s name (SLICKEDIT\shackett) in the tool window list and double click on it to go to the first line of code he contributed. You can then use the next and previous button on the tool window to navigate through the blocks of his work.

To make Scott’s work stand out more distinctly, select his name (SLICKEDIT\shackett) in the list and click the “Toggle Selection Visibility” toolbar button. When toggled on, Scott’s work will stand out, and all other developer’s work will be dimmed out. This allows you to quickly see what code is Scott’s and what code isn’t. You can click this button again to toggle it back off.

[Click here for the full size image]

Another option is to assign a unique color to Scott. To do this, click the Configure Visualization Schemes button on the Version Visualizer toolbar. This will bring up the Scheme Builder dialog. We’ll create a new scheme to highlight all areas of code worked on by Scott. Click the Add new scheme button and give the scheme a name of “Scott’s code”. We can now add a scheme item for Scott and give it a color of bright red.

[Click here for the full size image]

We can save this visualization scheme and then apply it by selecting it in the Version Visualizer drop down. This same scheme can be applied to any file to highlight areas of the code written by Scott.

[Click here for the full size image]

If you find a block of code written by the developer being reviewed that looks questionable, you may want more context about the developer’s intent, such as the check in comment made when that section of code was checked in. This information is very important for creating meaningful code review comments. The easiest way to do this is to see which version that code was checked in as, and look at the comment associated with that version. To do this, select “Default Relative Age Scheme” in the drop down at the top of the Version Visualizer tool window.

[Click here for the full size image]

Again, the versions of the file will be processed, but now the tool window will list the IDs of all versions that have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify which version last updated each line of the file. The colorizing of each segment corresponds to the age of the version it was checked in with (dark is oldest, light is most recent).

You can find the version associated with the questionable code and take a look at the comments associated with it. You can also use the next and previous button as before to see all of the code in the file that was updated as a result of that check in. For instance, we may have disagreed with the AddMenuCommandHandler function being public. We can see that change was part of version 762. By hovering over that version in the Version Visualizer tool window, we get a better understanding of why the function was made public. All of these features assist the team in making judgments about which code to review. They also provide some insight into the motivation the developer being reviewed might have had when checking a set of code in.

Next is the task of actually commenting on the code. This task is always best done in electronic format, in a way that can be pulled together as part of the code review meeting. The next article in the series will go through some of the features of SlickEdit Tools that facilitate writing comments about code and tying them directly to the source, without modifying the files.

I’m a bit of a pack rat… I have a hard time getting rid of anything I think I might possibly need in the future, and that’s especially true of computer books and magazines. Once upon a time, there was no internet… a sad fact that makes me feel older than my parents who can remember a time without TV. There was no Googling MSDN, no easy access to message boards, no coding sample web sites. Back then all you had was paper and ink, and you learned what you needed to learn by going to the bookstore and picking up the latest programming book on that subject. And we liked it!

A programmer’s bookshelf was more than a reference library though; it was your peer resume. Other programmers would look through your bookshelf the same way that animals size each other up in the wild. When you started a new job, your bookshelf contents were like the cologne and nice clothes you put on for a first date. It was a huge part of the first impression you made and helped define what you knew. Did anyone care if you’d really read those books? Of course not! Just seeing Design Patterns, Introduction to Algorithms and The C++ Programming Language was enough to grant you elite status your first day on the job (at least to those who mattered).

At my desk right now, I have approximately thirty books on the shelf. I’ve read them all from cover to cover, some of them several times. However, I haven’t read any of them in the past five years. At times, I’ll crack one open for a quick reference to something I can’t find quickly online, but seriously, they’re relics. I know that I should just do the smart thing and admit to them that the internet has caused their jobs to become redundant. I should tell them that the bookshelf is being downsized, and that they’re jobs have been outsourced to the web servers at Google. I just can’t bring myself to do that, though.

Every one of them has, in some strange way, come to mean more to me than just the information they contain. I can look at the cover of almost any book on my shelf and remember the reason I bought it, the project I was working on when I read it, and the difficult problems that it helped me work my way thorough. Many of the books have pictures of the authors on the cover, personifying them. All of the books make me reminisce to the period of time when they were read, the same way that so many songs from my first year of college do. I feel like I could take my programming books out for a beer and have a blast catching up on old times.

My programming bookshelf isn’t about learning anymore, and it’s certainly not about impressing anyone. I may at some point retire them, but not anytime soon. They sit on my shelf like old friends who I want to share my new programming experience with. They helped me out through tough times and I still want them to be there for all of my latest projects. I think my COM ATL books are grudgingly impressed with all the new-fangled .Net stuff, though I don’t think they trust it. My sockets books like to shake their walkers at web services. And of course, my first HTML book doesn’t think this fancy web 2.0 nonsense looks anywhere near as good as the first Geocities home page it helped me make.