Contents tagged with English
-
GhostDoc Progress
After a pretty long break from working on GhostDoc I'm now back on track. My goal is to have a release ready for entering Roy's add-in contest and now that the deadline has been moved to June 30, I'm pretty sure I can make that happen.
-
Sometimes it's Better to Check Even Really Obvious Dialog Defaults
If you only have a C# project file named e.g. "foobar.csproj" in a directory, opening it in the Visual Studio IDE (VS.Net 2003) will create a solution file for you. Either when saving or exiting you'll be asked for the file name, with the default name being e.g. "foobar.sln".
After being asked for solution file names over and over again, I never looked at the default name again - I simply hit Ok as soon as the dialog popped up.
Tip: You shouldn't do this if your project filename contains a dot. Because for a project named e.g. "foo.bar.csproj", the default name of the automatically generated solution file is "foo.sln", not "foo.bar.sln" as one would expect. For "X.Y.Z.csproj" the default name is "X.Y.sln", for "A.B.C.D.csproj" the default name is "A.B.C.sln", and so on.
In contrast, if you create a new project from scratch, the solution name is the same as the project name, even if the project name contains a dot.
-
Don't Underestimate the Benefits of "Trivial" Unit Tests
Take a look at the following example of a trivial unit test for a property. Imagine a class
MyClasswith a propertyDescription:public class MyClass
{
...
private string m_strDescription;
public string Description
{
get { return m_strDescription; }
set { m_strDescription=value; }
}
...
}And here's the accompanying unit test:
...
[ Test ]
public void DescriptionTest()
{
MyClass obj=new MyClass();
obj.Description="Hello World";
Assert.AreEqual("Hello World", obj.Description);
}
...Question: What's the benefit of such a trivial test? Is it actually worth the time spent for writing it?
As I have learned over and over again in the past months, the answer is YES. First of all, knowing that the property is working correctly is better than being "really, really sure". There may not be a huge difference in the moment you write the code, but think again a couple weeks and dozens or hundreds of classes later. Maybe you change the way the property value is stored, e.g. something like this:
public string Description
{
get { return m_objDataStorage.Items["Description"]; }
set { m_objDataStorage.Items["Description"]=value; }
}Without the unit test, you would test the new implementation once, then forget about it. Now another couple of weeks later some minor change in the storage code breaks this implementation (causing the getter to return a wrong value). If the class and its property is buried under layers and layers of code, you can spend a lot of time searching for this bug. With a unit test, the test simply fails, giving you a pretty good idea of what's wrong.
Of course, this is just the success story... don't forget about the many, many properties that stay exactly the way they were written. The tests for these may give the warm, fuzzy feeling of doing the "right thing", but from a sceptic's point of view, they are a waste of time. One could try to save time by not writing a test until a property's code is more complicated than a simple access to a private member variable, but ask yourself how likely it is that this test will be written if either a) you are under pressure, or b) somebody else changes the code (did I just hear someone say "yeah, right"? ;-). My advice is to stop worrying about wasted time and to simply think in terms of statistics. One really nasty bug found easily can save enough time to write a lot of "unnecessary" tests.
As already mentioned, my personal experience with "trivial" unit tests for properties has been pretty good. Besides the obvious benefits when refactoring, every couple of weeks a completely unexpected bug gets caught (typos and copy/paste- or search/replace mistakes that somehow get past the compiler).
-
XML Documentation Comment Tooltips (Wouldn't it be cool, part 5)
While I do write XML documentation comments for all my code (except throwaway stuff), I rarely actually read e.g. the CHM file generated by NDoc. But as we all know, a cool feature of VS.Net is that the content of XML documentation comments is used in various situations to display tooltips, which may look something like this:
Unfortunately, if users of my code (i.e. either other developers, or me after a couple of weeks) read only the tooltips, they may miss valuable information, e.g. descriptions of return values or remarks. The problem is that there's no way to tell whether additional information is available, so one usually assumes that it is not -- especially if you have looked a couple of times into a CHM documentation file for a specific topic only to be disappointed.
So I think it would be a cool feature if tooltips could display more information, maybe like this:
Of course the texts should be truncated to a reasonable maximum size (in order to avoid something like the sometimes screen-filling tooltips of the NUnit GUI ;-).
Other "Wouldn't it be cool" posts:
- Wouldn't it be cool...? (about editing XML documentation comments
- Intellisense (Wouldn't it be cool, part 2)
- Find (Wouldn't it be cool, part 3)
- XML Documentation Comments (Wouldn't it be cool, part 4) (doc comments e.g. for interface implementations).
-
Selecting String Literals in the VS.Net Editor
A colleague stumbled across this feature of the text editor by accident:
Move the mouse cursor on the opening quote character of a string literal:
Double-click and the whole string literal will be selected:
Pretty cool.
-
XML Documentation Comments (Wouldn't it be cool, part 4)
Each time I implement an interface or override methods in a derived class, I have to copy XML documentation comments for methods and properties manually. This is quite annoying - especially for interfaces, considering the fact that VS.Net 2003 has this cool feature of creating the outline of an interface implementation automatically. So why not create the documentation comments as well?
Note that I don't want the original documentation referenced using some sort of complicated mechanism. Just Copy and Paste - in many cases the documentation should be tweaked anyway (at least if you want to write readable documentation; who doesn't hate those generic sentences describing "actions" that are "performed" on "items")
Man, this is something I really would like to see in a future version of VS.Net.
-
Nice WinXP Style Icons for Customizing Folders
For quite some time I had planned to set up my home machine from scratch; last weekend I finally bit the bullet and did it. One week later I'm still in the "add and tweak" phase (the days after a re-installation when you notice some tools/hotkeys/settings are missing), but things are on their way back to normal.
While configuring my system I played around with customizing folder icons in Windows Explorer ("Customize" tab on a folder's property dialog). Nice feature -- if you have icons matching the look of your system. Searching the web for folder icons I noticed that people seem to be obsessed with changing the look of their GUI completely, often to a point where I can only wonder whether these systems are used for any actual work...
If you're looking for some "Standard Windows XP" folder icons for typical document types, you should visit Foood's Icons. The folder icons can be downloaded on this page under "XP Folders (1,2,3, 4 & 5)".
-
Nasty little Difference between "Find" and "Find in Files" in VS.Net 2003
I'm a keyboard shortcut junkie; at the same time there's a large variation of how fast I pick up a hotkey. While I used Ctrl-F / Ctrl-H (find / find and replace) and Ctrl-Shift-F / Ctrl-Shift-H (find / find and replace in files) for what seems like ages, I only recently started using Alt-F / Alt-A (find next / replace all) in the Find dialog -- don't ask me what took me so long...
Now sometimes you simply use the wrong shortcut, especially if it's pretty new for you and not completely burnt into your brain. Maybe you're tired or distracted or whatever.
So what happens if you hit Alt-A (replace all) in a Find dialog? Nothing, because there's no button "Replace All" in this dialog. Sounds reasonable.
But what happens if you hit Alt-A in a "Find in Files" dialog? Well... it replaces everything you wanted to find with some text you entered in the "Replace in Files" dialog five minutes ago!
Fortunately I had the "keep modified files open" option checked, so could use Undo...
-
GhostDoc Delay
As the public interest regarding GhostDoc was next to zero (which isn't necessarily a bad thing at this phase of the project), I've done a quiet release of version 0.9, available only to some of my colleagues at work. The overall reaction was very positive and a lot of "cool, I want more" ideas poured in which showed that they did "get" what GhostDoc is about. Unfortunately, when planning the future direction for GhostDoc, it became pretty obvious that the way the rules for method and properties are currently defined is a dead-end.
So I have decided that there will be no public release of version 0.9. I will completely rework GhostDoc towards a more extensible architecture, even if this means I have to throw away a lot of work done in January. No idea how long this will take, but I try to make several small steps to minize the risk of getting carried away. More details will follow later.
-
GhostDoc has reached Dogfood Status
A lot has happened since my last GhostDoc related posting. The addin version of GhostDoc is pretty close to a first public release. I'm already using it both at home and at work, but it's a bit complicated to keep the two configurations in sync. It's not really rewarding to define more specialized rules if you can't move them to a different machine. So I've decided to delay the release until some very basic import / export functions are implemented. They will be ugly, but straightforward to use and fully sufficient for a 0.9 version.
Here are two screenshots of configuration dialogs:
1. The main dialog
2. The dialog for editing a property rule:
