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.
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....
