asp:review
SlickEdit Tools for Visual Studio
Leverage Editing and Versioning Tools to Your Advantage
By David Mack
When I was approached to do the review on SlickEdit Tools
for Visual Studio, I was a bit skeptical of the value of an editing package
integrated in the Visual Studio IDE. I was wrong. I am currently working as a
project manager. As such, I m always looking to improve our company s
development process. This is a tool I think we can leverage to improve our
process. The suite of tools I reviewed encompassed editing, as well as version
control.
The installation was pretty uneventful and follows a
standard wizard format. It was pretty quick, but I would caution you about one
thing: The tool will overwrite your existing environment settings, so make sure
you back them up. It would be especially annoying if you ve customized your
environment and lost it accidently. After the installation is done you can
import your settings again. Something else to keep in mind: You must have the
full version of Visual Studio 2005 or 2008; the Express editions aren t
supported in the tool suite.
I opened a simple project after the installation and a
screen appeared indicating that SlickEdit wasn t sure which source control, if
any, was being used on the project (see Figure 1). At that time I could
designate the source control mechanism I was using, or none at all. SlickEdit
supports basic source control features for CVS, Subversion, and Team Foundation
Server. I configured it to point to my Subversion 1.46 package and SlickEdit
was happy. You can designate a default source control provider for SlickEdit,
but you also can designate it per project. This is especially helpful if you
are migrating between source control applications. The status of files could be
determined when using the Solutions Explorer and my versioning commands were
all available to me in the context menus.
Figure 1: SlickEdit asking how to
handle a new project.
SlickEdit versioning worked well with Subversion 1.46, but
it seemed to have problems integrating with Subversion 1.5. I kept getting an
error when it tried to connect to that version. I checked with the Web site
support and it appears they are working on this issue. It will probably be
resolved by the time you read this. I also liked other version control features,
such as version graphs, searching for versions, line version history, and
backup history.
The version graphs let you see in line graphs how many
times that file was checked in over time, who contributed to the checking in of
that file, the frequency at which that file was checked in, and the check-in
distribution. I found the first three helpful, but not really the distribution.
Maybe it s just my train of thought; regardless, it does allow you to see your
peak periods of check-in. I think the graphs could be helpful during a Lessons
Learned type meeting.
SlickEdit also allows you to search for versions of files
based on wildcards and check-in comments. With line version history I can right-click
and see when the last time a check was executed that affected this particular
line of code. The last feature I ll discuss is the backup history. This is the
ability to see a history of all the saved versions of a file, regardless of
whether the file was checked in to source control or not.
From a code editing standpoint, I enjoyed the acronyms and
aliases feature in SlickEdit. I can type an acronym and then press a control
sequence on the keyboard and my acronym will expand out to a designated string.
For example, I can type sdw , hit Ctrl + ` , and it will expand to Standard.DigitalSignal.Worker ,
which could be a namespace or any long annoying string you don t want to type. This
is especially helpful if you have a long string or function call that you use
significantly. Essentially, aliases are like acronyms, except the string you
type in expands to a directory name. It s a shortcut; although it s useful, I
didn t find it nearly as useful as the acronyms. If you have long filepaths, it
might be more useful to you.
It s a subtle thing, but I definitely liked the comment
wrapping feature and I like even more that it was configurable. One thing
that s annoying as a developer is to be typing a comment and have to break your
thought process to start a new comment line or risk sacrificing readability
with a long run-on comment. I thought the comment wrapping configuration should
have been on the main SlickEdit menu; I didn t see it and was only able to get
through using the SlickEdit Tools Assistant. I m not sure if it s there and I
just couldn t find it, but I did spend some time verifying it wasn t on the
main SlickEdit menu.
You can create XML documentation for your projects using
SlickEdit. It s the same concept as JavaDoc. It s very easy to create the
documentation using a simple <summary> tag. You can decide how and when
your documentation is created. The options include: on solution load, on build,
and every x minutes. If you re in an
environment where this documentation is critical and needs to be updated often,
the second and third option are probably reasonable. No matter what, I
recommend checking the Hyperlink data types box. This is a slower option, but
a more thorough option that allows for easier browsing.
My favorite feature is the code annotation that doesn t
modify the actual code itself (see Figure 2). This is an ideal tool for peer
reviews and code reviews. You basically can right-click on a line of code and
put in a comment. I like that you can classify it as a bug or just a comment. Based
on how you classified it determines the color in which it is displayed (the
default for a bug annotation is red). For a code review, you can announce the
files that will be reviewed and everyone can create their own annotations
before the code review. At that point they can send the comments to the
developer or code review coordinator ahead of the face to face code review so
they can see the comments. This feature also benefits ad hoc code reviews where
your development team sees something and wants to make a note of it but not put
actual comments in the code. You can browse all the comments for a particular
file by simply clicking on them. The comment will appear in the right-hand box.
It s a truly nice feature that can pay for the cost of this suite if it s used correctly.
The annotation works well in conjunction with the visualizer that lets you
highlight the code written by a certain developer. This allows you to see all
the lines of code in a file related to them.
Figure 2: Adding new annotations to
the file without actually modifying the code itself.
I found the documentation to be pretty good. The SlickEdit
Tools Assistant basically acts like a mini help directory that you can browse
and, once you find what you want to do, click a button to launch that feature. Some
of the features had short videos to show you how to use the feature. This was
pretty helpful a couple of times when I wasn t sure how to use a feature. If
you use the Tools Assistant and you see a little video camera, you know there s
a video associated with that feature.
There are many other features, such as the profiler, diff
tool, and code navigation, that you may find useful. Overall, I was pleasantly
surprised with the features. SlickEdit has been around a long time and I had
some preconceived notions about this suite not having a lot of functionality
that I d find useful. That simply wasn t true. For the price and the
functionality, it s worth buying either package (the editing and versioning
tools are sold separately or together).
Rating:
Web Site: http://www.slickedit.com
Price: US$49
for each suite of tools
David Mack is a
technical lead for the National Intelligence Division of Titan Systems and an
independent consultant. He has more than 10 years of experience in
object-oriented programming. Reach him at mailto:david.mack@titan.com.