Friday, March 13, 2009

I could just update my existing post from a couple of days ago but I have another point to make afterward.

Firstly, there is a minor release of ViEmu available as of yesterday. What I found most notable was near the end where Jon says he will be working on the ReSharper issue mentioned in my last post as well as an updated keyboard configuration dialogue. Both will be welcome additions and I’ll be grabbing that release hot off the presses.

Here’s where I think I missed the boat a little. I thought I’d blogged on ViEmu before so I didn’t dwell so much on my opinion of the software. Last June-ish, I decided to give the various vi/vim tools a try because they’d been getting some press. I gave a good college try to ViEmu for VS, SQL Server, and Word. I also had Vimperator for browsing. I tried all of them for at least a month and after that time, I still wasn’t as productive as I was without them.

Recently, as I mentioned, I’ve had a more vested interest in reducing my dependency on the crack we all call “mouse”. So Vimperator and ViEmu came back into the fold. I was pretty surprised at how much I had remembered from last time. This helped a lot because it meant the learning curve was that much lower. Whereas the last time, I had to get used to the navigation before I could learn the more involved intricacies of the products, this time, I had the navigation and search features buried in the back of my head somewhere.

Where I’m going with all this is I think ViEmu for Visual Studio is a good buy for developers, a point that didn’t come across in my last post. I don’t know that I do enough in Word and SQL Server to justify those but that’s me. Maybe you’re in SQL land more often. But I spend enough time in Visual Studio that it makes sense to investigate ways to improve the experience. I mean, how long does a carpenter hammer in nails before he gets a nail gun?

There’s a heck of a learning curve as with all things vi. (This kind of goes against my philosophy of “If something is hard to learn, it’s not worth learning” but I’ve made an exception in this case. See also: NHibernate). There are still minor hiccups, not least of which is my tendency to press j and k in Live Writer. And I was expecting this huge rush of superiority to descend upon me when I started to “get” it but I guess I’m still not quite at the “holier-than-thou” stage of the process. Looking forward to that because I do so respect those people that are so dismissive of others for not liking the same tools they do.

In any case, you’ll also find the author is very receptive to questions and suggestions on both the site and, more recently, on Twitter. And speaking of Twitter, you’ll find no group more helpful than ViEmu and ReSharper users. Give it a try by asking “What’s your favorite tip for <insert either one>?”. (Since you asked, it’s one I just discovered: Unbind Esc from Edit.SelectionCancel. Many thanks to Aaron Jensen and Joey Beninghove for that one.)

This public service announcement inspired by the author’s knowledge of how &*%$ HARD it is to build decent add-ins for Visual Studio.

Kyle the

Monday, March 09, 2009

Let it not be said the RSI is all fun and games. The hillbilly has just realized that he can legally date someone half his age and while that might open up a world of possibilities within his family tree alone, it also means he’s getting elderly.

One of the symptoms is a nice dull ache above my right elbow. I’m attributing it to one or more of three factors:

• Having to reach over both the cursor key cluster and the numeric keypad whenever I need to reach for my mouse
• My wrists twisting at odd angles on the keyboard
• My constant habit of wh---....actually let’s leave it at two reasons

My current keyboard is the standard Apple one (the wired one) which I picked up within a week of receiving my new desktop. The stock Dell one is not unlike a Speak N Spell when it comes to typing, the most egregious failure being the funky home key cluster. I’m not sure when they switched from the standard 2 x 3 to a 3 x 2 but I have to wonder what the thinking is behind such a switch. My own fault I guess for shelling out three large without putting any thought into my primary interface for the thing.

Its replacement is on its way based on the recommendation of someone whose opinion I respect highly and whose state of mental well-being is frighteningly similar to my own. Which is the only reason I shell out that much sight unseen, especially in a country not generally known for its excellent warranty service.

In the meantime, I giving another college try to various vim incarnations, particularly Vimperator and ViEmu. I tried both (and vim itself) for about a month some time ago and just couldn’t get into it. These days, I’m doing a lot more hard-core coding and have a more vested interested in getting off the mouse. Surprisingly, it wasn’t as hard as I thought to get back into the saddle, at least for the basic navigation commands.

Anyway, on to the real reason I called you all here today.

ViEmu and ReSharper are not quite best friends yet. They’re tolerant of each other and try to stay out of each others’ way but I hit some issues after installing ViEmu. There may be more incompatibilities but I ran into two before negotiating a detente ‘twixt the two:

• Shift-Alt-L no longer works (R# shortcut for opening Solution Explorer with the current file highlighted)
• In Fonts and Colors, the ReSharper options disappeared under the Text Editor settings.

The second caused some issues because in my fit of re-ergonomics, I’m also trying out a light-on-dark Visual Studio theme again after also discarding that some years ago. I’ve also got the Highlight Current Line option turned on in ReSharper and if you don’t have the ReSharper Current Line option listed in Fonts and Colors, the default is a very bright and very unintelligible white.

The issue seems to be the order in which things are installed. I had installed ReSharper first, then ViEmu. I also uninstalled both, then re-installed them in the same order. But before installing ViEmu, I verified that Highlight Current Line worked as expected. After installing ViEmu, I was back to a veritable blank line for my highlighted row.

Next, I uninstalled both and installed ViEmu first, followed by ReSharper and all appears right with the worl—...well, let’s not get carried away. I’ve got Visual Studio working the way I want is all.

Kyle the Mediator

Monday, October 27, 2008

I'm in the early stages of a new project with the dashing and debonair Brian Donahue. On the plus side, despite his misgivings, the codebase is in pretty phenomenal shape all things considered. SVN repository, automated build and tests, ActiveRecord, views reasonably separated into MVP. Even a half-finished CI process which is impressive for a one-man team. Like any codebase, it has its share of issues but all in all, I won't be using this as a sample app for a brownfield application.

On the minus side, he reads my blog so I'll have to be more subtle in the digs I make toward my workplace.

Anyway, one of the first things I like to do when I start looking through a steaming pile of excrement that someone calls "codebase" is check out the warnings that are lingering. The code had its share with the vast majority related to an upgrade to the latest version of Rhino Mocks but without changing CreateMock. This was an easy fix as a global search and replace from CreateMock to StrictMock got rid of over 80% of the errors.

The rest were a flurry of ReSharper refactorings until I got to the final four. Four assemblies reported the error: found conflicts between different versions of the same dependent assembly.

Double-clicking this error gives a helpful message offering to add a binding section to the assemblies app.config file. I say helpful seriously there because, while I had no intention of keeping that section in the app.config, at least it was able to tell me what the error message couldn't. Namely, which assembly was causing conflicts.

Or so I thought. The new app.config section seemed to indicate that there were NHibernate conflicts among various projects when I knew for a fact that we had exactly one copy of the NHibernate dll in the entire project.

Here's where Reflector comes in. More specifically, here's where it's extensibility comes in. Through the use of the Assembly Graph add-in, I was able to generate a picture of the dependencies. (Click on the image to the right for a bigger version.) As you can see, all referenes to NHibernate are going to the same assembly.

But as you can also see, there are three semi-related assemblies that aren't being referenced at all. Which means they can safely be removed from the various projects, yesno?

You probably think that's foreshadowing's cooler cousin, foreboding, but it's not. The answer is yes, I was able to remove them with no ill effects.

The reason I know there are no ill effects? Unit tests, baby! None o' this "let's take a stroll through the application and see if it still works" nonsense for me*. Remove the reference, run through the build process and watch the magic happen.

The reason this is important: I'm pretty sure this add-in doesn't account for dynamically loaded assemblies. And while I'm also pretty sure we would have no reason to dynamically load some peripheral NHibernate assemblies, it's nice to have a suite of unit tests backing up that assertion.

So to re-cap:

• Unit tests good
• Automated builds good
• Reflector good
• Assembly Graph add-in good
• Subversion good (I haven't provided explicit evidence of this here but it's worth mentioning.)

Kyle the Reflectively Assembled

*Brian, if you're reading, I'm lying. I did actually go through each section and make sure it's working. But back me up if anyone asks.

Monday, October 13, 2008

Have just started a new project and my first task is some Silverlight thingamajig that I'm sure I'll go on about ad nauseum in the coming weeks. But first, let's talk about some ReSharper settings.

My very first check-in in the code base was a ReSharper code style settings file. This is a way of allowing everyone on the team uses the same settings. The documentation for this feature is here though it's a little out of date. To the right is a screenshot from version 4.1.

This is somewhat important for me because I have some different ideas about whitespace than most people. And I don't want to impose my will on someone else. (At least not so crudely.) Nor do I want to alter my own personal projects just because everyone else likes to have all their code scrunched up together so that parentheses and curly braces essentially take the place of spaces and you need a &*%$ Little Orphan Annie Decoder Ring to parse out the actual meaning of these god-forsa--...

Ummm...let's just say I'm a little set in my ways and move on...

By default, your ReSharper settings are global across all projects. The two other settings are: a) Shared across the team, per solution, and b) Not shared, per solution, stored in a file.

Both are very useful in teams where developers work on more than one project, such is the case here. The other obvious example is open-source projects. Here's a quick run-down of each.

Shared across the team, per solution

Here, the code style settings are stored in a .resharper file in the same folder as the .sln file. This is ideal for a non-intrusive way to enforce coding standards on a project. Developers download the source and go. They may not even know it's using a shared code style.

MvcContrib uses this mechanism to enforce standards. I'm not on the new project because I've added .resharper files to my global SVN ignore list and I'm too lazy to change it. Plus, I'm not quite sure how it works between ReSharper 4.0 and ReSharper 4.1. I.e. is it able to manage users that use 4.0 and others that use 4.1? And what happens when one user changes the settings inadvertently? As an example, I just updated to the latest MvcContrib, opened it up, and now I have MvcContrib.4.1.resharper checked out for some reason.

So instead, we're using the next option.

Not shared, per solution, stored in a file

With this option, you explicitly tell ReSharper where the settings are stored. It requires a little more work to set up. Unlike the previous option, the developer needs to go into the ReSharper settings and physically select this option and navigate to the file. It takes an absolute path, not a relative one.

I'm guessing that this is because the settings to tell ReSharper which option to use are stored in the .resharper file, which as I've mentioned, we're not including in source control.

Both options give you the ability to set standards like naming conventions, spacing, and, theoretically, how to re-order methods, fields, and properties within your class. I say theoretically because this particular one (under Type Members Layout) seems a little eccentric. I had to import the settings from the code style file, then shut down and restart the solution for them to take. And when I make changes to this section, they aren't always reflected in the settings file.

None of this guarantees that your code will be consistent. After all, not everyone may have ReSharper. Also, I'm pretty sure the settings to auto-format are machine specific so someone could turn them off and then you have to rely on them to do an explicit auto-format before they check in. Furthermore, it appears that formatting profiles are also machine-specific, so even if you create one that runs through all your rules, re-orders things, and otherwise cleans up when you press Ctrl+Shift+Alt+F, that won't get propagated to anyone else's machine.

Kyle the Styled

Monday, January 07, 2008

ReSharper 3.1 is out, which you already knew. I put it off until this morning when I read Chris Patterson's account of the solution-wide analysis and thought about how funny that might be to run against my current project.

I didn't get too far but I was able to finally reformat (Ctrl+Shift+Alt+F) a class that had thus far been resistant to change, as it were. Oddly, the class went from 9,344 lines of code to 10,255 but damn, does it every look pretty.

Anyway, that's not what I wanted to talk about today.

While perusing over this shrine to monoliths, I noticed that it had apparently been ported over from .NET 1.1 because all the auto-generated code was still in it. Sensing an opportunity to do good, I decided to create the designer class old-school.

It wasn't all that difficult to muddle through. You create the class with the same name as the form but named appropriately. E.g. if the form is named Estimate, create a new class called Estimate.Designer.cs and either Visual Studio or ReSharper will wire it up for you. If it doesn't, you'll need to modify the project file manually by examining how another form does its nesting.

Once the class is created, mark it and the original form as partial. Then move the components variable, the Dispose method, and the InitializeComponents method into it along with all the form element variables.

But again, that's not really what I came here to talk about.

It was during this migration from form class to designer class, that I discovered what appears to be an undocumented feature of ReSharper. When I copied InitializeComponents over, I got the expected yellow strip of inadequacy along the right indicating that there were things that could be cleaned up.

Now this being auto-generated code as well as somewhat volatile, I had no intention of cleaning it up. But it occurred to me that I'd never seen this in other designer classes. So popping open another designer class for comparison, the only different was that InitializeComponents was wrapped in a region:

#region Windows Form Designer generated code

So I got to thinkin', what if I wrapped the entirety of my Estimate form class in a region of this name? And lo! All my inadequacy is gone! No more yellow hints and suggestions on how to make the code better. As far as ReSharper is concerned, my code could not get any better.

I kid, of course. I'm not advocating wrapping your code in cryptically named regions just to avoid seeing the ReSharper suggestions.

But here's the other thing: You can define your own region text that, when wrapped around a piece of code, will also render its inefficiencies hidden from ReSharper. Here is one way to do it, and I dearly hope there's an easier way:

1. Click ReSharper | Options
2. Select "Code Style Sharing" from Languages | Common
3. Export your current settings
4. Open the exported file in your favorite non-tab-based text editor and scroll to the bottom
5. Notice the element, SkipRegions. You should be able to take it from here. You define another child element with the text you want to use (e.g. Ignore this code, Resharper) and remember to increment the length variable (JetBrains doesn't the childNodes.length property, I guess).
6. Go back to "Code Style Sharing" and Import your new xml file

Now you can decorate code with #region Ignore this code, ReSharper and it won't display any suggestions for improvement. Note that errors will still be marked in red so it isn't technically ignored completely.

So there you have it. #regions aren't pure evil after all. Just ornery.

Kyle the Recanted

Monday, December 17, 2007

In a couple of recent posts, I've all but declared war on #regions. I'm not going to regurgitate my reasons but for those of you who go into "you won't like me when I'm angry" mode when they see a 800-line class condensed down to five, I submit to you not one, but TWO methods for getting rid of them.

Method 1: The VBA way

In this method, I used my newfound knowledge of using regular expressions in Visual Studio's Find and Replace and recorded a macro. Did some clean-up of the code and voila:

    Sub ClearRegions()
        DTE.Find.Action = vsFindAction.vsFindActionReplaceAll
        DTE.Find.FindWhat = "^:b*\#region.*\n"
        DTE.Find.ReplaceWith = ""
        DTE.Find.Target = vsFindTarget.vsFindTargetCurrentDocument
        DTE.Find.MatchCase = False
        DTE.Find.MatchWholeWord = False
        DTE.Find.MatchInHiddenText = True
        DTE.Find.PatternSyntax = vsFindPatternSyntax.vsFindPatternSyntaxRegExpr
        DTE.Find.ResultsLocation = vsFindResultsLocation.vsFindResultsNone
        DTE.Find.Action = vsFindAction.vsFindActionReplaceAll
        DTE.Find.Execute()

        DTE.Find.FindWhat = "^:b*\#endregion.*\n"
        DTE.Find.ReplaceWith = ""
        DTE.Find.Target = vsFindTarget.vsFindTargetCurrentDocument
        DTE.Find.MatchCase = False
        DTE.Find.MatchWholeWord = False
        DTE.Find.MatchInHiddenText = True
        DTE.Find.PatternSyntax = vsFindPatternSyntax.vsFindPatternSyntaxRegExpr
        DTE.Find.ResultsLocation = vsFindResultsLocation.vsFindResultsNone
        DTE.Find.Action = vsFindAction.vsFindActionReplaceAll
        DTE.Find.Execute()
    End Sub

So you throw that into a Macro Module, bind it to Ctrl+Shift+3, for example, and henceforth, you can use that shortcut to be free of #regions forever.

If I wanted to be *really* anal about it, I'd extract the duplicate code into a separate method. That way, I could re-use it for a macro to, say, remove triple-slash comments (regular expression: "^:b*///.*\n" ).

Method 2: The ReSharper Way

This method comes courtesy of Wade Grandoni, a non-blogger-who-should from whom I plan to steal blog post ideas until he takes the hint. When we're done here, removing regions becomes part of the ReSharper reformatting process. I.E. Ctrl+Alt+F (or Ctrl+Alt+Shift+F) and your regions are gone. If it isn't obvious yet, this method requires ReSharper

To achieve this little bit of magic:

• Go to ReSharper | Options
• Under Language Options, expand C#, then Formatting Style
• Select Type Members Layout
• Uncheck "Use Default Patterns" and DO NOT BE ALARMED AT ALL THE TEXT THAT APPEARS

What you see at this point is, I think, some default patterns that get applied to your classes when you reformat. And the default is to ignore regions for the most part. To change this find default pattern about halfway down. It's the one that looks like this:

    <!--Default pattern-->
    <Pattern>

and change it to this:

    <!--Default pattern-->
    <Pattern RemoveAllRegions="true">

Henceforth, whenever you reformat your code, regions will be removed. N.B.: This works only if you have selected the option to "Reorder type members" in the Reformat dialog:

If you select this option (as well as any others) the first time, it will be remembered every time you Ctrl+Alt+F or Ctrl+Alt+Shift+F from then on.

If you're a little confused as to what the rest of that XML is doing in the default patterns, you could delete the entire thing and replace it with the following:

<?xml version="1.0" encoding="utf-8" ?>
<Patterns xmlns="urn:shemas-jetbrains-com:member-reordering-patterns">
  <Pattern RemoveAllRegions="true">
     <Entry />
  </Pattern>
</Patterns>

This is the bare minimum you need to remove regions from your code when you reformat. What the rest of that XML does requires more reading than I'm willing to put in at 6:30 in the morning.

This method has the advantage of less friction while you're coding in that you don't need to perform any extra steps to remove regions (assuming you reformat before you check-in, which, of course, you do). On the other hand, Method 1 can be adapted to remove other patterns (like triple-slash comments) and, of course, can be used for the ReSharper-less in the crowd. And neither method will allow you to keep any regions that are, in fact, useful.

Kyle the Regional

Friday, October 12, 2007

Holiday in the Bahamas today but not in Canada. Which means I'm working while my daughter plays XBox behind me. So I'm going to vent my frustration on #regions.

Maybe it's my alternative upbringing but I'm not a huge fan of #regions in Visual Studio. And here is one example why:

As-is, this is pretty useless to me. My first order of action when I see this is Ctrl+M, then Ctrl+L to expand the entire thing which is another step I need to do to get my work done.

"But Coding Hillbilly," you say, "doesn't it help to organize your code?" NAY, I say, NAY! If you are looking through a piece of code and see a method or property belonging to the Raccoon class, how do you go about looking for it? Do you analyze whether it is a property or method, then search for the class in Solution Explorer, then epxand the corresponding region and scroll through it? Of course not, you press Ctrl+B to zero in on it with ReSharper (and I'm pretty sure Visual Studio has a semi-functional alternative).

The point is, you couldn't care less where the method is in the code. There are better ways to find methods. Ctrl+B, Ctrl+Alt+B, Alt+F7, Ctrl+Shift+F, Ctrl+F12, even skipping through the methods using Alt+Up and Alt+Down. In fact, I would argue that separating them into #regions like this actually makes it harder to scan through code because of the cases where some regions are expanded and others aren't.

Using ReSharper also exacerbates this problem. A common refactoring scenario is Extract to Method (Ctrl+Alt+M, if memory serves). And ReSharper isn't going to bother searching through #regions to figure out where the method should be placed (nor should it). Ditto for when I start using method names that don't exist, then Alt+Enter my way through some NotImplementedException goodness. The #regions just get in my way.

I've also been in places that are so dogmatic about them, there are actually empty #regions because the coding standard says you *have* to have one for private methods, even if you don't have any. And don't get me started on nested #regions.

Admittedly, they do have their place. Prior to .NET 2.0, it was nice having the designer code hidden from view. Ditto for when you implement trivial interfaces that you rarely want to look at again. IConvertible, for example.

So I suppose the real point is, don't overuse them. You aren't organizing anything by compartmentalizing properties and methods in this way. If you're one of those compulsive types, write some sort of add-in that alphabetizes the members or organizes them by how long they are or something. Just don't dump them into #regions.

Kyle the Regional

Wednesday, September 19, 2007

After a year and a half as the sole developer on a content management project, where my programming was limited to writing utilities to assist with data loads and *shudder* writing OScript, it is freakin' fanTAStic being on a real development team again. And an agile(ish) one at that. It's great being able to discuss nice meaty problems like how to layer your application or how best to deal psychologically with the frustration that is the VSTS merge tool.

Now this being my first real agile experience (or at least the first one that's been officially called that), I'm not totally familiar with the conventions. But it seems to me that agile shops could benefit from a role that I'll call The Littlest Hobo, for lack of a better term. That is, someone who goes from project to project, lending a hand where pain points exist.

Many projects may have something like this in some regard. I imagine the scrum master plays this role for higher level impediments but I'm thinking at a more detailed level. Someone whose sole job is to pair with a developer for a morning on a task, then review code on a different project in the afternoon. The next day, he or she would examine the build process of a third project and see if it could be improved (and it always can). Another time, perhaps he or she could mentor someone on ReSharper shortcuts while they code.

Essentially, I'm thinking of someone working outside of a single project who can provide an outsider's perspective during the development process. And it doesn't necessarily need to be one person's full-time job. It could be a role that is passed around among senior developers every week. It doesn't even need to be a role that is fulfilled every week either. If you have a small group, maybe one person takes it for a week, and then it stays unfilled for a couple of weeks.

The impetus for this idea was an upcoming code review. Few people will deny the benefits of a code review in theory but in practice, I've been on both sides of the review and very often, there is no "ideal" time for a code review. Often, one or both of the reviewer and the reviewee are none too pleased to be ripped away from their work even if we recognize that it is something that needs to be done. It's difficult to coordinate a review time that isn't "crunch" time on one project, let alone two (presuming the reviewer is on a separate project).

That's where The Littlest Hobo could help out. This person's schedule could be almost set in stone save for the specific projects and people involved. E.g. Tuesday morning: Pair with someone. Tuesday afternoon: Review code on some project. Wednesday morning: Increase code coverage for some project. Thursday afternoon: Code review. Monday morning would be reserved for filling in the blanks where it says "some project" or "someone".

Personally, I think it would be a helluva fun role. Not full-time, mind you, but once every couple of months it would be a nice break from the ol' day-to-day, doncha know.

And for you nostalgic Canucks who are already singing it in their heads, here's the theme song.

Kyle the Nomadic

Wednesday, August 01, 2007

Test time, kiddies!

Assume that in the image below, we are looking at a class in Visual Studio with the default font and color scheme (except using Consolas as the default font). Also assume that ReSharper 3.0 is installed.

Locate at least three things wrong with the formatting on this screen.

First correct answer wins the opportunity to tell me how the &*%$ to fix it. Hint 1: Re-installing ReSharper has no effect. Hint 2: Changing the font/color setting for Tracepoint - Mapped (Enabled) will, for whatever reason, affect the same change in the variable "mockery" in the image above.

Kyle the Bemused

** Update **

Stop with all the responses already. It's embarrassing. You'll inflate my already-ballooning ego.

The three bits of freaked out formatting are:

• The mockery variable is formatted as if it is a breakpoint. However, after testing various settings, it is, in fact, formatted as a Tracepoint. Yeah, I didn't know what a tracepoint was either.
• Line 14 is not highlighted as a breakpoint.
• Line 15 is missing the closing semi-colon and the IDE has not picked this up as an error

There are two possible solutions. The first is to uninstall Visual Studio Team Edition for Database Professionals (p.k.a. DataDude). The more correct one is to install the latest service pack for Visual Studio, of which I had none.

Friday, June 08, 2007

While I will profess my undying love of ReSharper, I do have a bit of an annoyance with its auto-closing delimiters (as explained here). I've talked before on my love of white space but it comes with a price. Whenever I type the opening parenthesis of a method, ReSharper helpfully adds the closing one. It's also smart enough to recognize when you type the closing one yourself and won't duplicate it if you do so. If you don't have a space there, that is.

Here's an example. Let's assume I type the characters: "this.gethashcode(" without the quotes. Here is how it looks right after I type the (:

this.GetHashCode( )

ReSharper has helpfully added the closing parenthesis and even respected my choice of using white space after opening parentheses and before closing ones. The problem is that the cursor is now situated right after the first parenthesis and I need to Right-Arrow or End my way to type the closing semi-colon. And neither key is situated in an area that lends itself to quick access on my laptop. If I type the closing parenthesis, ReSharper does not recognize that this is the same as the one it just helpfully added (the way it does when there is no whitespace). So I'm left with:

this.GetHashCode( ) )

(Note: I added the space after the first parenthesis manually. It's a habit I'm hoping I don't have to break.)

There is a way around this that I haven't quite got into the habit of using. That is to take advantage of ReSharper's advanced IntelliSense. Here's what appears when I start typing GetHashCode:

At this point, I can press <Tab> and get the following:

this.GetHashCode()

Plus the cursor is sitting helpfully at the end of the line. And no worries about my precious gestalt. I need only type the closing semi-colon and either ReSharper or Visual Studio will format it into the beacon to gestalt I am looking for:

this.GetHashCode( );

The problem with this method is that it kind of slows me down. I find it much faster just to type "gethashcode(" than to start typing "get", search through the list for the one I want, arrow down if necessary, and press Tab. My way has more keystrokes to be sure, but does not require that I pay attention to the UI.

The habit I'm trying to get into is: rather than typing "gethashcode(", instead type "gethashcode<tab>". Theoretically, this should be easier...

Kyle the Habitual

Sunday, May 07, 2006

Couple of short miscellaneous items to balance the tome I wrote last time:

1. The Start Page in Visual Studio can be customised to show your own news feed rather than the default one. Go to Tools | Options | Environment | Startup. I'm also told you can use something like http://www.feedjumbler.com to collate a bunch of your feeds together into one which you can then use as the main feed for Visual Studio. I'm feeling “sign-up“ averse today so I haven't checked out Feed Jumbler
2. You can also set the number of recent items that appear on the start page. Tools | Options | Environment | General and change “items shown in recently used lists“. Note that this also changes the number of items in File | Recent Files and File | Recent Projects.
3. There appears to be no way of getting rid of the Getting Started and Headlines sections.
4. Have been playing with the beta of ReSharper 2.0 and love it. Type “throw new“ and it displays only available exceptions. Reference a class with no corresponding “using“ statement at the top and it is added for you. Type “using“ at the top and it displays the full hierarchy of namespaces available, not just the current level. And I've only been using it for a day. But it is uninstalling as we speak. Granted, my laptop is two years old and showing its age, but there is a very noticeable drop in performance of Visual Studio 2005. Plus I got some unhandled exceptions when working in a SQL database in Server Explorer. Tried to submit the error to help the developer folks out but that required me to sign up for something. See point 1. Regardless, when I upgrade my hardware and when they're out of beta, I'll gladly hand over $150 for it (pending a review of Code Rush).