Wednesday, June 29, 2005

NMock 2 - new syntax, new features, same problem

NMock are working on a new version of their popular mocking framework.
You can now mock Properties and Events and it has a totally new syntax.

Expect.AtLeastOnce.On(joker).Method("Ha");

You are still limited to using "strings" for method names, so you still have the issue of changing your tests manually when you rename methods. (see EasyMock as an alternative)

Thanks to Roy Osherove's for highlighting NMock's latest efforts.

Monday, June 27, 2005

Comments are deodorant for code

"Code smell" is the rather evocative term used to describe an aspect of a piece of code that indicate a fundamental problem with the current design. Comments are frequently used to explain what is going on in complex code. Therefore they act like deodorant on smelly code.

Most comments I read in code are totally pointless. 'print "hello"; // this line prints hello' or worse 'print "goodbye"; // This line prints hello'. Another common use is as follows...
void someMethod()
{
//add a new user
... Code to add the new user ...
// give the user a new password
... Code to give the user a new password ...

...
}

What you have here are a whole bunch of methods all tied together. My money is that if you look elsewhere in the code you will find another method that also implements the 'add new user' code too. Methods like this make duplication much harder to spot.

Code should be self explanatory. If you have to put a comment in the code to explain some aspect of its behavior then the code is not clear enough.

There are three things you are trying to get across to the reader of your code:
1/ What is it doing?
3/ How is it doing it?
2/ Why is it doing it?

Here is how to address each of these concerns.

What is it doing?
The name of the method answers this question.

How is it doing it?
The body of the method should be an easy to read list of steps.

Why?
Very occasionally reading the 'How' of a method will leave you wondering 'why is it done this way? Usually this is time to refactor. Sometimes, however, this is not the case. Maybe the operations are order dependent or apparently superfluous steps are required for someone API to work correctly. Explaining these situations is what comments are for. It is also a good idea to have unit tests to verify these conditions remain true.

Situations where comments are require should be rare!

So... Next time you are adding a comment to explain some code, ask yourself the question "Is this comment explaining What? Why? or How?" if its not "why?" then it shouldn't be a comment!

Wednesday, June 08, 2005

Tuesday, June 07, 2005

Viral Marketing

I was reminded the other day about viral marketing. There is a great FREE book on the subject at http://www.sethgodin.com/ideavirus/01-getit.html

The basic concept that ideas act like viruses. Some ideas (the successful ones) catch on and spread. The book is about how to design and present ideas so they can be easily spread and hence improve the chances of them taking off.

A good recent example of this is beer commercials. Manufacturers have started creating adverts for release on the internet. If you wrap your message in something funny people will email it to each other. Jokes on the internet move very fast indeed. The adverts spread in this manner reach millions in no time, and costs the company practically nothing.

GitHub Projects