Few weeks back I was with a developer doing a code-review for one of his application. The application was a Windows Forms Application written in C# that monitors several running jobs and reports on any event/failure found in the log file.

Many gaps came up in the review which made me thinking (me thinking is surprising isn't it), hence this post. The abstractions in the form of frameworks and IDEs that are available today make programming definitely accessible but at what cost. Do they make a formal (structured) learning of programming unnecessary?. Are today's engineers getting away by not following any coding disciplines like the one's enforced by my mentor(s) and teachers when I learned programming. Before I continue this rattle and list the items let me clarify, I am not intending this post to be a comprehensive check list - it just happens to be the issues I noticed in this particular incident. I have grouped few of my findings in sections.

Reading a configuration file

• When reading a configuration file (like .config/xml) to load values, validate whether the file exists. If file is not present either load default values and proceed  (or) exit gracefully. Having a simple try/catch  block doesn't mean you have handled all exceptions and you no further work
• Try not to read the entire file to memory. In .NET this will be for example using StreamReader.ReadToEnd method. Think about what will happen if you the file has been corrupted or wrongly replaced with a 10GB video file. You will crash the machine by running out of memory. In typical configuration files especially for your applications you can identify the maximum likely size which will be say few MBs. So in .NET try to use StreamReader.ReadLine for as many lines as you will need
• Similarly don't load the entire XML into XMLDOM (like by using XmlDocument) where it is not necessary. Instead try to use XmlReader which is a stream based XML processor and doesn't take up memory (many times of the full XML filesize)

UI Related items

• While designing design the work flow and the steps with the user of the application in mind. Think about the likely steps the user will follow. Do not design with your code flow as the steps. In this application this meant not having to select a configuration file and global settings screen as first step in the Tab order. Instead have the first screen after application launch as the one the user will use repeatedly

In an earlier project I gave the complete UI design specification in Visio format to a developer that avoided all the iterations and confusions. You can read about that in this earlier post.