Selfelected

Software architecting lacks good notation

I found a blog entry at http://www.matshelander.com/wordpress/?p=74 which although lengthy and wordy hits the spot.  There is no good notation system for software architecting.

My words: Comparing software architecting to building houses is ridiculous.  Just because they share the same name (architecting) doesn’t mean they have a lot in common.  Compare a sea horse and a horse and you get the same useless result.

The romans would never be good at mathematics since they lacked a good notation.
What software architecting needs is a good notation.  UML is one way but it is not very good for evolving solutions and finding bugs.  Code is the best notation I know of but it is too close to the very program and not good at describing architecture.

Besides, after several thousand years of building houses we still miss the estimated cost.

Why is a primary key an int?

We are used to having PKs in databases as integers.
The reason for this is that computers are good at numbers and an integer is a very versatile and fast number representation.

But there are drawbacks in the business layer.  A customerID can be compared to a orderID like so:

if( customerID == orderID ){…

This is not a good thing.

CustomerIDs should only be comparable to other CustomerIDs.
They should also not be addable, subtractable, multiplyable and being greater than anything else.  A CustomerID is equal or not equal to another CustomerID.  All other comparisions are not of this world.

I have yet to figure out how to implement this.

A comment of what to use as a primary key is found here.

How to write xml comments in c#

My prefered way to write XML comments in C# is to write the first sentence on the first row like this:

/// <summary>This method does nothing.
/// <summary/>
public void Foo()
{
//NOP.
}

because when one folds the code (ctrl-m-o) one can see the first row like this:

/// This method does nothing. …
public void Foo() …

This is not an issue in vbnet.

To create a document out of this use Sandcastle which takes over after nDoc which is discontinued.

More comments on commenting are found here and here.

Use “??” for avoiding null

There is a nifty operator in dotnet2, ??

Use it to get the first thing that is not null.
   string name = firstName ?? lastName ?? email ?? “Has no name”;
sets name to the first value that is not null.

To set  a string to empty if it is null but keep it otherwise:
    message = message ?? string.Empty;
which is  the same as
    if( null ==  message ){
message = string.Empty;
}

One might consider it harder to read but I think it is a matter of getting used to.

Beware though of its low precedence.
    string user = userName ?? string.Empty +  description;
will always return only the userName if there is one.   Alas, insert a pair of parenthesises:
string user = ( userName ?? string.Empty ) +  description;

On the side I prefer
   string.Empty
to
   “”
because with string.Empty I am totally sure the string is empty.  There is no chance what so ever that a stray space slipped in between the quotes.

Use stored procedures

Some people complain about stored procedures as bad because they inject business logic into the database.
My answer to this is that then the stored procedures are used the wrong way.

Stored procedures should be used to get data in and out the database.  Used this way they represent the holes in and out of the database.
Name the stored procedures cunningly and you have an easy way to find the only ways to insert data into the customer table, the only way to update the order table and only ways to select multiple rows from role.

I have not found the perfect naming scheme.  Anyone?

Recreate the bug before fixing it

Before you start fixing a bug.  Make sure you can recreate it.

Before changing the first line of code always reproduce the bug.
Without having the same indata and getting the bug and the same indata and not getting the bug you can never be sure it is fixed.

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.

Hungarian notation

Hungarian notation was, and is, a good idea.
Unfortunately prefixing the variable with the type has today become suffixing:
sCustomerNumber -> customerNumber
sPassword -> passwordString
nMax -> maxValue

What is the reason for this? Is it harder to read nCustomer than customerNumber? I don’t think so. Instead more space/characters are used for communicating the same information.

Think of the ever present”customer number”. Written as customerNumber at first look it looks like a number, a series of figures. Now we know that a customer number has dashes and letters in them so it is really a string, like customerNumberString. Written with hungarian notation it is sCustomerNumber and clearly a string.

Now I have come to use PascalCasing or camelCasing like everyone else but only for strongly typed languages like C# which can by itself differ between strings and integers. For loosely typed languages like Javascript or PHP i still use hungarian notation.

My rules for hungarian notation in Javascript is like:
sXXX for strings
nXXS for integers (bytes, long integers, whatever)
fXXX for floats (doubles, decimal, whatever)
oXXX for many objects (oUser, oBoat, whatever)
myclassXXX for other object (userProtagonist, accountMain, accMain, whatever)
rsXXX for record sets
bXXX for booleans
anXXX for arrays of integers
asXXX for arrays of strings
cXXX for constants and characters – I am not totally happy with this

There has been no reason to make it more complex than that.

What priority levels to choose

When choosing how to number priorities I usually use 3 levels:
1) Critical. These are show stoppers. Without these fixed, the whole system is a waste of money.
2) Workaround exists. The customer have to call you (the developer), they might have to buy new hardware or send a backup copy by airmail deluxe. But a workaround still exists.
3) Cosmetic. This is anything that the users can figure out the solution for by themselves.

These 3 levels are not enough so they have 3 priorities in turn. 1, 2 and 3.

All in all 9 levels.

It is so simple it seems to work.