I need a better "Go to definition" in VS2005 (similar to Eclipse)

I wish MS could implement a little smarter/better "Go to definition" feature. Today it almost works as it should. The "Go to definition" feature is used to go to the row where something is defined (a method, a variable, etc). Which is very handy if you are maintaining a project without any code documentation at all. But unfortunately the function will be confused if there are two methods that are named the same, but have different arguments. (It is called method overloading) Visual Studio 2005 is an "ok" IDE, but it is no way near Eclipse.

With VS2005, it will instead of moving the cursor to the method, it will move focus to a "Find symbol results" view where it displays those methods that have the same name. VS2005 could very easily look into the code and find out the type of method arguments and move focus to the method I wanted to see. But apparently it can not distinguish between an int and an ArrayList.

Try the below code in Eclipse and VS2005, and try to go the correct method that is used in "anotherMethod". (In Eclipse use "Open declaration"). Eclipse will move you directly to the correct method (method(int,ArrayList)), while VS2005 will just show a simple search result.

public void method(int i, int j)
{
}

public void method(int i, ArrayList list)
{
}

public void otherMethod()
{
int i = 2;
int j = 2;
method(i, j);
}

public void anotherMethod()
{
int i = 2;
ArrayList list = new ArrayList();
method(i, list);
}

To me it feels like Eclipse is developed by developers for developers. VS2005 is developed by someone for developers. If they had used the IDE on a daily basis they would understand that the current "Go to definition" is not properly implemented. They should be able to do a better implementation than this semi solution.
Another good example of that VS2005 is not developed by developers, is the lack of unit testing understanding in VS2005, which I already blogged about.

OO Parenting by MS

I really love object orientation (OO), because it is so easy to build software using it; and it is so easy to totally screw up using it. Today I was surprised when I was trying to find out some information about the Select method in System.Windows.Forms.Control. The documentation for the Select method states what the method does and doesn't do, but it also informs what inheriting classes that does not support it. Of course, every parent class should know everything about the inheriting classes; and have documentation on everything

Excerpt from the documentation:
The Windows Forms controls in the following list are not selectable. Controls derived from controls in the list will also not be selectable.
* Label
* Panel
* GroupBox
* PictureBox
* ProgressBar
* Splitter
* LinkLabel (when there is no link present in the control)

C'mon, why put the Select method in the Control class if they know that many inheriting classes will not implement it at all. This solution/idea reeks of bad design! If a Control does not support a certain functionality, then that class should not have a method pretending to support the functionality. But this is not the first time I found a similar problem with the "design" of Windows Forms, so I will stop whining here....

Frustration grows when unit testing with VS2005

I've always liked unit testing as it makes my job as a software developer much easier. But the unit testing features of Visual Studio 2005 makes me very frustrated and tired of writing unit tests.

There are two big key issues when using unit testing in VS2005.

• When I have executed a test and it fails; it will show up in a list with a red icon. When I double click on the failing row/test it will show a report stating what went wrong. Tell me something I don't know, and move the focus to the failed assertion.
  
• When I have fixed a bug in the project under test, I would like to re-run the test. In the "Test results" window I can choose "Rerun original test". When I click on it, it will re-run the test with the old code; and the test will fail again even if I fixed the bug. What happened, didn't I fix the code??
  
• What the h**l is "Assert.Fail failed."?

Visual Studio 2005:

Eclipse:

Issue 1
Since the test report window has already displayed that the test fail, I'm not interested in a report stating that the test failed, I know already that the test failed and (hopefully) the reason for it. What I am interested in is which assertion failed and where it is.

In VS2005 I have to do the following to get to the assertion:

1. Double click the failure in the "Test results" window.
2. Find the row number by reading the text in the stack trace section. Add row number to memory.
   
3. Open the unit testing code file.
4. Go to the row found in step 2
5. Fix the assertion

In Eclipse it is so much easier:

1. Click on the failure in the "Junit" window.
2. Double click on the "AssertionFailed" in the "Failure trace"
   
3. Fix the assertion

C'mon; 4 steps and many user interactions involving remembering trivial values to show the failed assertion. It is really frustrating to do it whenever something fails. If something is frustrating and takes time, the developer will stop doing it; thus stop unit testing the software. There is no context menu item to go to the failed assertion, only to go to the begining of the test method. With test cases that can be long, it is not so easy to find the failed assertion. Below is the test report that is shown when the user double clicks on the failure.

Issue 2
I have one project that contains the production code, and one test project next to it as I don't want to mix production code with test code. I've created a test project, added a reference to the production project, and verified that the test project depended on the main project. The test project can access the production classes, so far everything is fine.

But the problem comes when one of the tests fails because of a bug in a production class. When I update the code in the production project, and want to debug the last failed test I click on the "Debug original test". Sure the debugger starts, but the problem is that VS2005 forgot to build the whole solution including the production project. Instead of rebuilding the production project it will only rerun the test. The test will of course fail again, and I will be sitting there wondering if my fix didn't do anything. This has happen to many times, and I've wasted numerous minutes before realising that I must manually build the solution.

Perhaps I'm not using the features correctly, and MS has another view on old test results. Maybe test results should be saved every time a test is run. But for me test results has a very limited lifetime, as soon as I've fixed an error; I don't care about the results prior to the fix.

This does not happen in Eclipse, the minute that I've updated the code I can re-run the test by clicking on "Re-run Last Test - Failures first". No rebuild needed, no time spent wondering why a fix doesn't work.

Issue 3 (Minor)
I just saw this when writing this blog. How can an Assert.Fail() fail? The failure text states that the Assert.Fail() itself failed, to me that is not correct. The test failed itself, and should perhaps say "Failed due to an Assert.Fail() call". Unfortunately Eclipse is not much better as it states "AssertionFailedError" for a fail() call, but still that is better than VS2005.

Opinion
The VS2005 unit testing features are not user friendly, they don't help the user as good as they could. Sometimes a tool with a bad feature implementation is worse than a tool without the feature. Perhaps MS can improve the usability in VS2005, and make it easier for us developer that wants to utilise unit testing. It seems that the above design misstakes must be developed by people who doesn't practice unit testing.

Why no Equals() and GetHashCode() in System.Collection?

Today I had another brain freeze when I was trying to understand why two array lists would generate two different hash codes even if they contained the same data. But when I started my investigation in MSDN, I see that the ArrayList does not override the GetHashCode() nor the Equals() method. Ehhhhh?

So my question is how can I check if two lists are equal? NO, I don't want to go through all items. This should be handled by the framework classes and I don't want to do any unnecessary implementation.

If I look in Java, the ArrayList implements equals(), hashCode() as all good objects should. They have also a good explanation on how it is done here.

If I look through the other classes in System.Collection I see that no implements GetHashCode() or Equals(). If none of them do, then it must be a design choice. But what design choice would that be? If anyone have any explanation, please make a comment to this blog. I really want to know.

There is an interface in System.Collections.Generic that is named IEqualityComparer, which has two methods, Equals() and GetHashCode(). Why make an interface when every class implements those methods? And why doesn't the default list/collection classes implement this interface?

I did a little test application to test this out, because I can not believe it. Full listing here.
Pseudo code:

string a = "A";
string b = "B";
ArrayList list1 = new ArrayList();
list1.Add(a);
list1.Add(b);
ArrayList list2 = new ArrayList();
list2.Add(a);
list2.Add(b);

Console.WriteLine("list1.equals(list2) ? " + (list1.Equals(list2)));
Console.WriteLine("list1.equals(list1.clone) ? " + (list1.Equals(list1.Clone())));
Console.WriteLine("list1.hash == list2.hash ? " + (list1.GetHashCode() == list2.GetHashCode()));

This program would show:
list1.Equals(list2) ? False
list1.Equals(list1.Clone()) ? False
list1.hash == list2.hash ? False

If I create two array lists that contains the same items, the Equals() method will return FALSE. If I clone an array list and checks if they are equal the Equals() method returns FALSE. How can a CLONE not be an exact copy of the object, or how can two exact copies not be equal to each other?

The best part is that Hashtable doesn't implement GetHashCode() either. And that class require all other objects to implement that method in order to be used, but they refuse to do it themselves. "Do what I tell you, not what I do."

Is it because they know people will not implement those methods since developers are lazy? But why have they put them into the Object class if they can't be trusted? Or was it a copy-paste mistake from Java? To me this is so wrong.

Localisation with VS2005 will slow you down

In my previous blog about a localisation that went sour, I mentioned that the time for building a localised application takes longer and longer for every language that is added. I have now quantified my feeling and found out that adding a language adds 15-20 seconds for each language. Now that doesn't sound that bad right? Wrong, If you develop an application that takes one minute to build and adding languages almost triples that time, then it becomes tedious very quickly.

This is what I found out (table and graph):

• Default language took 69 seconds to build
• With two languages it took 85 seconds to build (16 extra seconds)
• With four languages it took 118 seconds to build (49 extra seconds)
• With six languages it took 144 seconds to build (75 extra seconds)

If a normal developer compiles 10 times an hour to test something, he/she will waste 12 minutes, just sitting to wait for VS2005 to build. I meanthat is an outrageous extra time, and I wonder if we can send a invoice to Microsoft for those hours that we just wait for the build complete? And I guess we have to make the work day longer as we get much less done.

For this project, the solution was to remove all language resource files from the project file. This means that the only language that is supported in mid-development is "default" and nothing else. So fixing those too narrow labels for localised texts has to wait for another day. The tool do add/remove all those languages to/from the project file is developed in house and can not be shared unfortunately. The tool is very simple to create, but in my view unnecessary.

Here we have a grave problem with the localisation in Visual Studio 2005. If it is done as MS wants, the build time to a project can (and probably will) go up for every language added. What is the outcome of that? Either the developer will stop adding localisations, constrain the development by only showing the default or sit and do nothing while the project builds. This is not a good solution. I would rather have a one-file seperate from the GUI, which reads on the fly when the application is started. That way the language files does not affect the build at all, and it will be a minor load time added for the user which probably will not be noticed.

Measurement notes:

• This is an observation of an application that has been under development for 3-4 years.
  
• They have tried to follow MS design guidelines.
• Clear case is used with dynamic views, which could have an impact on the result as it needs to access 200 new files for every added language.
• The application is not divided up into more than 2 GUI projects. Perhaps adding more sub projects could make the build quicker?
• I used a C# application to measure the time it took to execute a bat file containing "devenv app.sln /build debug"
• I measured each language addition at least 4 times