Selfelected

How to separate WinForm code

A “normal” form contains lots of event handlers. Everything from click handlers to drag’n’drop and OnPaint. After a while they grow numerous and entangled enough to be a bug source of their own; whenever something is corrected there is a risc a new bug pops up.

I have a way of writing code to avoid this. For some time at least. :-)

The rule is that no control should be aware of another. (except in some simple cases) So the myButtonOnClick does not update any other control but only try-catch and call a method.
This means there are 50 event handlers in the form and as many methods. Some buttons do the same thing and call the same method but more often two different methods call a third one.

I split the form into regions. One is called “Event handlers” and another “Presentation logic”. Then there are other regions too when needed.
This way the code and logic is split naturally into the graphics and the logic behind it. If it smells like the top of 3 tier then you are right. Just because we talk about n-tier in a solution doesn’t mean it is not applicable on smaller parts too.

It comes naturally to work in one of the regions then, mostly in the Presentation logic region, and to not worry about the controls and their rendering.
If the form is Big then use partial class of dotnet2 and split the class into several files.

I have not found a natural way to name the methods handling the presentation logic.

Rotate tasks

I have an idea of how to induce communication in a project.

I really wanted to do pair programming but didn’t dare to insert it into the project due to some reasons.
After a while I noticed that even with templates to code from, people did things in their own way (naturally) and that people had different knowledge about the customer’s plans.

I then thought about rotating the tasks, like one only works with a task for 2 days and then everyone switches. This forces people to communicate (i.e. ask others what they have done) and to sync their programming styles with each other.

I never forced this though.
But if anyone have – feel free to tell me the outcome.

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.

Do not write reusable code – write rewritable code

>Do not write reusable code. Write rewritable code.

With reusable code I think of code that without retesting can be used in new ways. “Without retesting” means it has been tested for this “new” way of use beforehand.

The problem is that the code obviously has been written and tested for a usage not applied by the time of writing. To me it seems like a waste of time.

One could write the code reusable but not test it for any other usage than the present. I would recommend this since the source will then contain untested code which even might be interwoven with the tested. Mixing tested and untested code and increasing the complexity of the code by handling possible future situations will make the code harder to understand.

Better then is to write the code so it absolutely fits the needs and instead put some time into making the code simple and clear. Comment it even!

These thought boils down to
Simple code – easy to update.
Complex code – hard to update.

So instead of writing an if statement testing for a flag or inheritance or whatever insert a comment “If you plan to do this or that – here is the place to write the code.”

Strong typing is considered Good

Strong typing gets rid of lots of runtime errors. Why do script languages always use weak typing? I really don’t see anything good coming out of it.

A friend of mine, mainly a Java and Python programmer, defended Python’s/scriping’s position by telling me how fast it is. He compared the turnaround for a Java web project and a Python ditto. So I see his point, it was quite cumbersome to update the Java solution (I don’t remember the environment), but I have yet to find such a complex situation in any solution I have built for dotnet or VB6.
I doubt all Java solutions are as complex as his example.

Which sort of gets me back to the first paragraph. There is no reason for a scripting language to be weakly typed and hence more error prone.