Tuesday, October 02, 2007

ToolTip only showing shadow


Friday, January 26, 2007

QCon 2007 (London)

You might want to take a look at http://qcon.infoq.com/qcon/conference/. QCon will take place between the 12th and 16th of March. Should be a good event with plenty of .Net, Java, and other software goodies thrown into the mix.

Thursday, September 28, 2006

Refactoring away performance

Donald Knuth once said that "Premature optimization is the root of all evil (or at least most of it) in programming", something that the agile community advocates, and I myself agree with (for the most part).

The idea is that writing very fast tight code that performs amazingly well, but lacks readability, might be a waste of time. You might not need that amazing performance, or it could be that no matter how fast your code is the web service provider that it subscribes to or the database serving records is so slow that it doesn't really matter anyway. No, instead write readable, well designed and maintainable code. If you need to get more performance later then profile your software, find the slow bits and optimise them. After all, it's easier to optimise well structured easy to read code anyway.

This is all well and good, and most of the time is the right way to go. But I'm a little concerned that we might be building unnecessarily slow software. Take for example the refactoring technique "Replace temp with query". Replace temp with query states that this code:

string desc = MyObject.GetDescription ();

this.Text = desc;
AFileClass.SaveFile (desc);
AnoherClass.Description = desc;


should be replaced with:

this.Text = MyObject.GetDescription ();
AFileClass.SaveFile (MyObject.GetDescription ());
AnoherClass.Description = MyObject.GetDescription ();


So that rather than getting the description and storing it in a temporary variable we re-query the MyObject class each time.

This refactoring (as with some others) decreases performance and adds nothing to code readability. What is the cost to our application of a multitude of small performance degrading refactorings? Would we notice the drop in performance in our short code-deliver-test cycles? Or would we end up at the end of development with an application that just feels a bit sluggish?

If we did end up with an app that needed a performance boost it would be a long painful process to go through the code and remove all these small refactorings.

Refactoring: Improving the Design of Existing Code

Martin Fowler's discussion book and catalogue of common refactorings is a hugely interesting read. It presents the reader with an overview of what refactoring is, how it evolved, and why we should be making use of the technique in software development.

Refactoring is the process of improving software by making it more readable, maintainable, and shaping it into a better design. Many people consider the end point of a successful refactor to be a design pattern (Refactoring to Patterns).

The bulk of this book is given over to a catalogue of possible refactorings. Some very simple, such as Encapsulate field (i.e. replace a public field with a private field and a public property), to other more complicated efactorings such as Introduce Null Object.

A large part of refactoring is being able to test that your changes have not broken existing code. For that reason this book advocates and discusses automated unit testing as a way to verify that your refactorings haven't broken anything.

This book is getting on a bit now, but there are still a large number of software professionals who have not embraced a more agile way of working who would benefit from the gentle introduction that this book delivers.

Another point to make is that this book is Java based, but that should not put of any C# professional from reading it.

Effective C#

I found this book difficult to read, not because it was technically over heavy, but because the style didn't seem to let me really get into it. I've not been able to pin down exactly what it was about the style; maybe it was too bullet-point like and lacked depth.

Style aside this is a very good book, especially for anyone who is migrating from C/C++ to C#. In fact I'd say this book is essential if you are coming to C# from a C/C++ background. I wish I'd read this book when I first started programming in C#.

The book covers C# language, .Net mechanics, and even touches on some design issues. I found that I wanted more depth from the book, especially on some of the chapters about design. To be fair to the author he does say that he is not attempting to write a book about design, and that such topics are best dealt with by entire books rather than a few chapters, but I think a little more detail and discussion would have added to the book.

Unfortunately this book only covers .Net 1.1. I've been unable to find any news about a .Net 2.0 revision.

Friday, August 18, 2006

C# .Net 1.1 Compression

Unfortunately when using C# with .Net 1.1 there is no standard way to zip or unzip files. Various 3rd party products exist, both open source and closed source, but perhaps a better solution is to use J#.

J# exposes classes in the java.util.zip namespace which provide the ability to compress and uncompress files. This MSDN link describes how you can call those classes from your C# code.

Comment restrictions removed

I've removed any restrictions on who can comment. Apologies for not setting this sooner, an oversight on my part when I created this blog.

Wednesday, August 16, 2006

C# String Formats

In asnwering a google groups post this evening I found this particulary helpful list of string formatters. The google groups post was asking how one can format an int of value 3 to a string "003". Two methods that immediately spring to mind are:

int i = 3;
string s1 = i.ToString ("000");
string s2 = String.Format ("{0:000}", i);

The google groups post can be found here.

Microsoft Empower

Ian Moultster writes in his blog about Microsoft's Empower scheme. Empower provides developers with a heavily discounted MSDN sucscription as well as other Microsoft software including Windows and Office for about £260 a year.

Still a tad more expensive than a Linux/Mono setup, but a very reasonable offer non the less.

Monday, August 14, 2006

Clover

As I mentioned in the post below, Clover is one of the reasons that I have become such an advocate of unit testing. Clover is a test coverage analysis tool. Clover instruments your code, so that as each instruction, conditional, or method is executed calls are made to the Clover assemblies. The Clover assemblies keep track of which aspects of your code has been executed, which haven't, and very importantly what has been the result of conditional checks.

So, for example, if your code contains the line if (object == null) and you have 'Clovered' (the process of instrumenting your code with calls to the Clover assemblies) your code, then Clover will be able to generate a report which tells you not only how many times that line of code has been executed, but also how many times object == null has evaluated to true and how many times it has evaluated to false, even highlighting if the condition has always evaluated to true or to false.

How does this fit into Unit Testing? If automated unit tests are carried out on Clovered code then you can use the clover reporting tools to generate coverage reports that tell you exactly which aspects of your code have been exercised by the unit tests. By analysing the clover reports you can tweak and improve your unit tests until you have a satisfactory level of test coverage.

Clover is also extremely useful in system test, load test, soak test, and UI test scenarios. Imagine a situation where your C# GUI is delivered to a tester who has a test specification to work through. If clovered code is delivered, on completion of testing by the tester, a clover report can be generated showing exactly which lines of your GUI code have been executed, which branches have been tested, and which forms or controls were completely missed by the tester/test specification.

Unit Testing

When I first came across unit testing I was very skeptical as to how useful and productive it might be. Googling the topic seemed only to present trivial examples, with no really well reasoned discussion as to how applying automated unit testing to a project might yield significant benefits.

I am now, however, a firm believer in automated unit testing. What brought about the change in my attitude is live project experience of working with unit tests, a lot of discussions and debates with colleagues as to the effectiveness of unit tests, and Clover.

Over the next few days I'll be writing an article on unit testing and why I truly believe that it is one of the quickest and most effective ways of achieving high quality, robust, and well designed code.

I've added two new links to the excellent NUNIT unit testing framework and the equally good Clover test coverage tool.

New Link

I've added the blog's first link. The link is to Jon Skeet's C# page which contains some of the best written articles I've come across whilst I've been developing in C#.

In particular I think his discussion of the Singleton pattern and how BeforeFieldInit affects code execution are especially good.

Sunday, August 13, 2006

See Charp!

In time I hope this blog will become a great resource for all things C# and .Net related. Although I hope to post plenty of code tit bits I hope the blog will become more than just a programmer's cook book.

Let me know if you'd like to see anything in particular on this blog.

Until the next post,

Nick