File Systems

I was reading Coding for a Living: A Pattern for Fluent Syntax and started a reply that went so off topic and was too long in my opinion for a comment, so I decided to post it here.

I couldn't agree more with what Richard wrote about the shortcomings of the file system. Folders for files are fine when you have a few files, but I repeatedly find myself wanting folders organised for different points of view.

For example, say you file quotations and invoices on your server. Are the top level folders the company name, the status of the client (Archived, Active, Potential)? There will be a greater need, as we produce more electronic files, to view the files by their categorisation rather than their location within folders. Most of the time I don't want a Windows Explorer, I want a Windows File Finder where I can say I want to see the files tagged with "Invoice" and "Acme Corporation" and "created between October and December 2007". Sound like SQL to you? That's where I hope the file system will go one day.

Reading XML? Use XmlReader, not SqlDataReader

I just know I'm going to want to look this up one day, so here it is for my reference:

If you have SQL that produces XML, you might be tempted to try read that XML using a normal SqlDataReader. But doing it that way will not work if the resulting XML is large. In order to read large XML results from SQL Server, you will need to use the XmlReader rather than the SqlDataReader.

How unit testing becomes coding

Recently I was writing unit tests for some non-trivial methods on a few classes. I noticed that a lot of the tests were similar, but varied in terms of their input values and expected result values. Which then led to some refactoring within the unit tests to produce code with less duplication. Which led me to think about how I was going to test the test code I had just refactored. The thought process took me on to think about domains; in particular the fields of mathemetics or finance. My thoughts ramble here, so bear with me or leave if you like.

Let's assume we have a clever mathematician or actuary called Tess. Tess produces a formula for us to code up in a business object. My thought is this: "How would Tess test the formula in her domain?" We would attack a formula such as this with inputs and expected outputs because that's what our unit tests lean towards. But how does Tess validate the function? She steps through every part of the forumla, proving with known rules, that the formula is sound. She never uses inputs and outputs to verify the formula because she knows that this is statistically insignificant. That is to say, even 100 test values out of the possible hundreds of millions is insufficient to be considered a representative sample.

My conclusion after all this nonsense is that code reviews are under rated and far too infrequently employed. And, and this is what bites, we don't do them well enough. I know that some people do very good code reviews, and I am going to find out what they do that makes their code reviews more effective and complete than the code walkthroughs I've seen in the past.