DRY – The first step

It has been said that a thousand miles journey starts with a single step. So in case journey = becoming a better developer, then first step = DRY. DRY stands for Don’t Repeat Yourself. I see way too much copy-paste development around. This needs to stop. If you constantly copy-paste code around, you’re limiting yourself of becoming a better developer. Code duplication is evil, and it’s simply against common sense. So why do we do it? We do it probably because it’s easier, it doesn’t require us to think. When we stop thinking, our journey of becoming a better developer ends. Anyway, does anybody know how do you disable CTRL+C in VS :)? 

Pseudocode Programming Process

Today I had to implement a feature on project I'm working on. The feature was not a trivial one. It was rather complex. I had a general idea how it could be implemented. The implementation I was having in mind involved several complex data structures and some recursion function calls as well. After short thinking about the problem I started to do the actual implementation in C#. To be more precise I tried several implementations, but I kept failing, and found myself rewriting the code over and over. I was completely lost in complexity of the problem and all the details (complex data structures and recursion calls). I kept doing so for about 1.5 hours (maybe two), and I still had no working solution. Then I realized that I have to change my problem solving approach.

If you have read "Code complete" book you probably remember Pseudocode Programming Process (PPP) that Steve described in the book. Pseudocode Programming Process is a way of designing algorithms in pseudo code. Basically, this means that an algorithm is described in high-level English-like way. You can find more about the PPP on following links:

• Does anyone use the Pseudocode Programming Process?
• Pseudocode
• The Pseudocode Programming Process

Anyway, after writing down the algorithm in high-level English and then making every line of comment into a line or fewof code (applying PPP practices), I had working solution in about 20 minutes. YES, 20 minutes including pseudocode and C# implementation. How that compares to 1.5 hours spent for literally nothing? I can only but recommend PPP as way of handling complex algorithms.

Bugs and bytes

Yesterday, at work we had a bug in application we’re developing. Nothing critical but rather inconvenient. Our application has a very common functionality of file download. Some users can upload files to the system and some other users can download those files. Pretty straightforward functionality, right? It’s an ASP.NET application so it should be very easy to implement this. Here's the code (not the real code but the relevant part of it):

 protected void ViewFile(int fileId)
       {
           byte[] fileData = DAL.GetFile(fileId);
           Response.ContentType = "application/octet-stream";
           Response.AddHeader("Content-Disposition", "attachment; filename=test.txt");
           Response.OutputStream.Write(fileData, 0, fileData.Length);
           Response.End();
       } 

So what could possibly go wrong here? Not much? Except…, files can be EMPTY too! An empty file is a file that is 0 bytes in size. So if you try to write an empty file with the code above an exception would be throw at Response.OutputStream.Write() line. How do we write an empty file to HttpResponse then? Very simple: you DONT write anything. Just skip Response.OutputStream.Write line and call the Response.End(). Anyway, what am I trying to prove here with this simple example? My point is that we need to be more thoughtful when writing code. We must carefully think about code we write. What could go wrong? How is API we’re using behaving? What exceptions can be thrown? What assumptions are being made? One approach I find useful with dealing this kind of issues is Defensive programming. Here’s quote from wiki about Defensive programming:

A difference between defensive programming and normal practices is that few assumptions are made by the programmer, who attempts to handle all possible error states. In short, the programmer never assumes a particular function call or library will work as advertised, and so handles it in the code.

If the code had been written in Defensive programming mind-set this bug would have never been made. I must also note that Defensive programming is not only choice for solving these kind of issues. Another approach is Design by contract. In the end it really does not matter which approach you choose, the goal is to create more robust and quality software.