Selfelected

Wanted: Tool to move your code elsewhere

I wish for a tool built into VSNet that easily moves your code elsewhere.

Like this:
You write a constant declaration right in you code, where you are, to quick and easy code andor debug. This constant should be elswhere, like in the class top or a common file. So just mark the constant and tell the IDE to move it to [choose here].
That would allow you to keep on coding without having to wind back and forth in the source. Doing this quickly would help you to avoid accidentaly forgetting to move the constant out of the method.

Panels that don’t autohide in vsnet

You have set a panel to autohide in VSNet but suddenly it decides to not.
So irritating.

The solution without having to grab the mouse (I am normally writing code with both hands) is to select the panel through ctrl-tab and arrows. Then press Esc and the ctrl-tab again.

Startup page in VSNet2005

In VSNet2005 there is a handy option to show a start page with earlier projects/solutions, developer news from MS and some other stuff.

Then when one chooses a project/solution this page does not close.
Of course it should close – I am probably not interested in news _after_ I opened the project. If I was, I would have opened the news item to start with.

Keyboard shortcut missing

Could someone please create a keyboard shortcut to grab the handle to resize the query/result window in SQLServer Management Studio? There used to be one (ctrl-B) but it disappeared with the 2005 version. Now one have to use the mouse to se more of the query or result.

The MS people writing the tools for SQL Server have always had a wierd view of what is user friendly. Even though SQLServer is a typical server installation one is forced to use a mouse to navigate.

An article about roughly the same: http://hci-matters.com/blog/?p=8

Even n-n relation tables should have a simple PK

Continuing with the above/earlier I say that even the table to create a many-to-many relationship should have a simple primary key.
E.g.:
Table User_Role
– field UserRoleID PK
– field UserID FK
– field RoleID FK

As long as harddisk space is cheap and a simple PK does not create a performance impact there should be no reason to not have a simple primary key.

Top down or bottom up

The discussion whether to design software bottom up och top down died with intellisense/typeahead/whateveryoucallit; it was so much easier building bottom up. Then refactoring tools entered and suddenly made it easy to program top down again.
Personally I believe the two methods should be mixed. Not like “these methods or modules we design top down and these bottom up” but more like “these methods we design no matter the way”.

Like this:
Here is a method I’d like to have. Here is the call. There is the method signature automagically created. Then some implementing code. And further calls to yet non-existing methods. Which are automagically created. Until we get all the way to the bottom. Where we adjust a couple of parameters. And refactor this up again. And adjust. And refactor. Until we are back where we started with code that is readable both if you track it from the top or the bottom.
Or the other way around if you prefer.

As long as the code gets readable. And updatable.

The simplest solution is often the best

I have a rule (not a rule really, simpler than that) that if I can’t explain a thing or defend a standpoint in a minute or two I am probably not correct.
I am necessarily not wrong but I am not correct either.

Some issues take more than 2 minutes to clearify but then the problem lies elsewhere, in a bigger scope.

What to choose for primary key in a relational database

Anything simple.
Anything simple but not something the user knows about.

A 32 bit integer, a GUID, a string. But not the CustomerNumber or PostalCode or EmailAddress. No matter what the user/customer/client says – those things are not unique. I have been harrassing customers whether the CustomerNumber is unique or not. It has been unique for two weeks until someone remembered about foreign offices with their own numbering system or that they sometimes are changed.

Alas – do not use anything you find in the business logic as primary key.

A more technical comment on why we use int is found here.

Comments are code

Not totally correct;
Since comments don’t compile.

But…
too often when I look through code I step on comments that say one thing and code that says another.
This has even made me waste time hunting bugs along the wrong track.

No information is better than wrong information

Comparing the map and reality in most circumstances reality wins.

If the sentence above feels ridiculous I can say I have worked with a project leader who thought otherwise.

( a friend of mine said “comparing the map and reality, reality wins. because that is where you are” )