A 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 ones enforced by my mentor(s) and teachers when I learned to programme? Before I continue this rattle and list the items let me clarify, I am not intending this post to be a comprehensive checklist – it just happens to be the issues I noticed in this particular incident. I have grouped few of my findings into sections.
Reading a configuration file
- When reading a configuration file (like .config/XML) to load values, validate whether the file exists. If the file is not present either load default values and proceeds (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 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 workflow and the steps with the user of the application in mind. Think about the likely steps the user will follow. Do not design your code flow as the steps. In this application, this meant not having to select a configuration file and global settings screen as the 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.