SQL Server, Analytics, .Net, Machine Learning, R, Python
Mitch Wheat has been working as a professional programmer since 1984, graduating with a honours degree in Mathematics from Warwick University, UK in 1986. He moved to Perth in 1995, having worked in software houses in London and Rotterdam. He has worked in the areas of mining, electronics, research, defence, financial, GIS, telecommunications, engineering, and information management. Mitch has worked mainly with Microsoft technologies (since Windows version 3.0) but has also used UNIX. He holds the following Microsoft certifications: MCPD (Web and Windows) using C# and SQL Server MCITP (Admin and Developer). His preferred development environment is C#, .Net Framework and SQL Server. Mitch has worked as an independent consultant for the last 10 years, and is currently involved with helping teams improve their Software Development Life Cycle. His areas of special interest lie in performance tuning
Tuesday, February 13, 2007
Reviewing Managed Code
MSDN has a recent article on Reviewing Managed Code:
“Summary. This document will discuss best practices for reviewing managed code.
This brief article does not go into as much detail as The Elements of C# style but does contain a few excellent bits of advice, such as incorporating FxCop into the build process and checking for and reviewing warning suppression statements as part of the code review process.
I noticed in the comments section that the following advice was given: “Comments must be clear and accurately describe the associated code.” This should be stated as “Comments must be clear and accurately describe the intention of the associated code.”
One thing that we all come across from time to time (at least, I know I’ve been guilty a few times), is we quickly prototype an application with literal strings embedded (message boxes, exceptions etc). We know that these should be packaged into a string resource file, so that changes are localised and globalization is supported, but then the application grows and the amount of work to convert those literals seems daunting. Check out the Resource Refactoring Tool, mentioned in this article, which can be used to refactor string literals out of code into a resource file.
MSN, Email: mitch døt wheat at gmail.com