Core 3.4.0 introduced the Slick-C function _eclipse_execute_command which allows you to execute Eclipse commands from the SlickEdit environment.  The documentation for this function shows you how you can search the Plug-in Registry to find Eclipse command names and ids, but there is a much better way documented in the following blog post:  http://evans-stuff.blogspot.com/2007/10/it-seems-that-im-not-only-one-still.html . 

Unfortunately I discovered this technique after we finished the documentation and shipped the plug-in, but hopefully me pointing it out here may help some users. 

Also, don’t forget the “Activate Editor” command in Eclipse (F12 by default).  If you are using _eclipse_execute_command to jump into different Eclipse Views and search around mouse-less, hitting F12 will jump you back into the last active editor.

<update> 

Check out this thread of the SlickEdit Forums for adding a generic Eclipse Pass-through Command: http://community.slickedit.com/index.php?topic=3549.0

From the post:
If you are evaluating 3.4.0 for your company, you can make this happen easily.  One of the best features in Core 3.4.0 is the introduction of _eclipse_execute_command, which is discussed in the user guide/readme, and also a little more in my post here: http://community.slickedit.com/index.php?topic=3816.0 .  This is the idea that Rob suggests in this thread.

I’ll take this opportunity to give a brief tutorial on how to integrate that “Activate Task” shortcut into the SlickEdit environment.

First you need to know the command id of what you are trying to execute.  I used the method described http://evans-stuff.blogspot.com/2007/10/it-seems-that-im-not-only-one-still.html , in which you create a Simple Cheat Sheet and use the Command Browse button (see first screenshot).

Then I just used the search field to find the command (see second screenshot).

Now that I had the command/parameter info, I opened up the Slick-C macro file where I write my custom commands (ryan.e), and added functions for Activate Task and Deactivate Task using _eclipse_execute_command (see third screenshot).  Remember to load your macro file with F12 after writing the functions.

Then I used the SlickEdit Keybindings dialog to bind eclipse_activate_task to Ctrl + F9 (see fourth screenshot), and voila.  Hitting Ctrl + F9 in a SlickEdit editor will launch the Mylyn Activate Task dialog.

It may seem like a lot of steps, but it’s really not.  This whole process took me less than 10 minutes including the time I took to capture/crop/annotate the screenshots.  You can use this method to execute almost any Eclipse command from any plug-in from the SlickEdit environment.

- Ryan

This article continues Part 1 of the series, where we began the code review process by demonstrating some ways to find the best candidate files to review. We then introduced some techniques to identify what code a specific developer had written, using some of the features in the Versioning Toolbox. The next task is to actually comment on the code. This is always best done in an electronic format, in a way that can be pulled together with other developers’ comments during the code review meeting.

Using Code Annotations to Write Review Comments
The Code Annotations feature in the Editing Toolbox is extremely useful for writing code review comments because it lets you attach comments to specific locations in the code without altering the code itself. You can bring up the Code Annotations tool window by clicking SlickEdit > Show Code Annotations.

[Click for full size image]

The first step when writing code review comments is to create an annotation file to store all of your code review comments. You can then send this file to the code review organizer when you’re done. You can use the Annotation File Manager to create a file called “Code Review – Bob” (or whatever your name may be).

Writing Comments About the Code
After applying the “Scott’s code” visualization scheme that we made in the first article, we can navigate through the sections of code that Scott has written. On line 497 of PackageBaseWhidbey.cs, we see that he’s doing a GUID comparison using a literal string. This goes against coding standards, so we’ll log a comment that the string literal needs to be defined as a constant. Put the cursor on that line and click the New Annotation button on the Code Annotations toolbar. This will bring up the New Annotation dialog.

We’ll create a review comment, which is one of the standard annotation types. We’ll also select the “Global : Code Review – Bob” scope, or category, which will put the annotation into the code review file we created earlier. After filling out the fields and clicking OK, a purple highlighted marker is placed on the line of the new comment.

[Click for full size image]

Once you create an annotation, it gets an entry in the annotation list. You can select that entry to see a summary of the annotation, or you can double click on it to jump directly to the code it is assigned to. This makes it easy to get to the code that you’ve commented on.

We also found a bug on line 431 of FileUtility.cs, so a bug annotation can be logged for that. This new annotation has a red highlight to indicate that it’s a bug type.

[Click for full size image]

It’s helpful to only show annotations that you have created for the code review, without the clutter of others in the list. You can filter out all non-code review annotations by using the Annotation Filter Configuration dialog, available on the code annotations toolbar. Select Filter by Scope and select the “Global : Code Review – Bob” item. Now, only your code review annotations will be visible in the list.

Wrapping Up Your Review
Once all of your code review comments have been completed, they will all be contained in the file “Code Review – Bob.sca“, which we created at the beginning of the article (code annotation files have an extension of .sca by default). That file can then be sent to the code review organizer.

All of the received code annotation files can then be imported by the organizer during the code review meeting, where they can be discussed. Reviewing code this way maintains a tight link between the code review comments and the actual source code, and is far better than trying to manage the process with pen and paper, or a set of text documents.

You can also create a report of the annotations to print before the meeting, or to send to other developers. To do this, click the View annotation Detail toolbar button. The Code Annotation Details dialog will be shown and each annotation in the list will be shown in the report. A small red document icon will appear by each annotation that may be clicked to navigate to that annotation in the source code. The report can be exported to HTML or printed.

[Click for full size image]

The next step will be the actual code review meeting, which will be the focus of part 3 of this series. Once the code annotation files are pulled together from all of the reviewers, those comments can be discussed and updated. After the code review meeting, they can be exported to a single code annotation file and emailed back to the group. The developer being reviewed then has a clear set of action items as a result of the meeting.

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.