Or to be more specific, by Microsoft StyleCop. Now this may not be new to you, and that's very likely since StyleCop was announced in May of this year, but it was new to me.
The tool checks your code for coding style and more specific, the Microsoft coding style. It was developed outside the VSTS team and has absolutely no connections to FxCop. FxCop focusses on .Net Framework standards and correct use, StyleCop focuss on the way your code looks. Among others, it checks your code for the following items:
- Layout of elements, statements, expressions, and query clauses
- Placement of curly brackets, parenthesis, square brackets, etc
- Spacing around keywords and operator symbols
- Line spacing
- Placement of method parameters within method declarations or method calls
- Standard ordering of elements within a class
- Formatting of documentation within element headers and file headers
- Naming of elements, fields and variables
- Use of the built-in types
- Use of access modifiers
- Allowed contents of files
- Debugging text
The idea behind StyleCop, as can be read on their teamblog:
The ultimate goal of StyleCop is to allow you to produce elegant, consistent code that your team members and others who view your code will find highly readable. In order to accomplish this, StyleCop does not allow its rules to be very configurable. StyleCop takes a one-size-fits-all approach to code style, layout, and readability rules. It is highly likely that you will not agree with all of the rules and may even find some of the rules annoying at first!
I downloaded the tool (click here) and installed it to test drive it on my CrystalHelper class, and boy are they right. Some of those rules are annoying. I previously checked that class with FxCop and got little to comments there. From people that used the code, I always received comments that is was readable, easy to comprehend, etc. Then again, those differences make sense. FxCop looks at usage of the .Net Framework and does so by analyzing the compiled binaries. StyleCop uses the actual code. But let me give you some examples of what StyleCop has to say about my code.
Running StyleCop
The first thing I noticed when I ran StyleCop (or Source Analysis as it's called in the menu) is the enormous amount of comments. My first reaction was to remove the tool and forget about it. Actually, I had the same reaction when I first ran FxCop. I was curious enough to continue though, so let's look at what the tool had to say about the following code segment.
489 /// <summary>
490 /// Gets or sets the data source.
491 /// </summary>
492 /// <value>The data source.</value>
493 public DataSet DataSource
494 {
495 get
496 {
497 return _reportDataSource;
498 }
499 set
500 {
501 if (_reportDataSource != null) _reportDataSource.Dispose();
502
503 _reportDataSource = value;
504 }
505 }
Here we have 16 lines of code which most C# developers will accept as properly styled. StyleCop however gave me remarks about almost every line of code code:
- Tabs are not allowed. Uses spaces instead. On almost every line.
- The call to _reportData must begin with the 'this.' prefix to indicate that the item is a member of the class. On lines 497, 501, 502 and 504.
- Statements or elements wrapped in curly brackets must be followed by a blank line. On line 498.
- The body of the if statement must be wrapped in opening and closing curly brackets. On line 501.
In addition to this, it also mentioned that the fieldname should not start with an underscore. This was a remark abou the _dataSource class variable I use in this property code. For this section of code, I received a total of 23 comments!
Changing the code to satisfy the tool
As I said, most C# developers will not really have a problem with the coding style used in the above segment. But apparently, this is totally unacceptable for Microsoft developers. My next step was to change the above code so that the tool would not complain about this code. And this is what it looks like after those changes:
489 /// <summary>
490 /// Gets or sets the data source.
491 /// </summary>
492 /// <value>The data source.</value>
493 public DataSet DataSource
494 {
495 get
496 {
497 return this.ReportDataSource;
498 }
499
500 set
501 {
502 if (this.ReportDataSource != null)
503 {
504 this.ReportDataSource.Dispose();
505 }
506
507 this.ReportDataSource = value;
508 }
509 }
All tabs are now replaced with spaces. The body if the if statement is now enclosed in brackets. There's an empty line after the closing brackets for the get body and the if body. All class members are now preceded by 'this.'. And yes, I removed the underscore from the class member. Not that much different, but some of the changes make sense, I guess.
Other comments found by the tool
The tool does find other things as well. Here's a short list of some other comments the tool made about my CrystalHelper class:
- Invalid spacing around the comma. All comma's should be followed by a single space
- Invalid spacing around the opening parenthesis. There should not be a single space after an opening parenthesis
- Invalid spacing around the closing parenthesis. There should not be a single space before a closing parenthesis
- The spacing around the symbol '=' is invalid. You need to add a single space before and after the '='symbol
- All using directives must be placed inside of the namespace
- All methods must be placed after all constructors
- All methods must be placed after all properties
- All private methods must be placed after all protected methods
- All private methods must be placed after all public methods
- All protected constructors must be placed after all public constructors
- The method must have a documentation header
- The summary section in the documentation header must not be empty
Should you use it?
A difficult question. My first reaction, as I said before, was to remove the tool and forget about it. But that was the same reaction I had when I first started using FxCop. And yet, that is now a tool I use on a daily basis.
I also have a problem with non-enforceable coding standards. Put 10 developers in a room to talk about coding standards and you end up with either 10 slightly different versions, or one that none of them will adhere to. My experience over the last 20 years is that, if you can't enforce coding standards, you can forget about introducing them and hope that it will all go well.
And that's exactly where this tool comes in. You can now enforce a number of rules to make code more readable and understandable. You might want to disagree to some of them (I don't agree to using spaces instead of tabs) but you can run the tool and check if your coding style matches that of the tool. And when all developers in your team use the tool and change their code accordingly, then all your code looks quite similar. Making it easier for your teammembers to work on code by other developers. And that's the main objective for any development team to create a coding standard.
The tool can also be included in MS-Build scripts, so you can easily make sure the build is broken when a developer ignores the coding standard. So yes, use it!
Some tips when using StyleCop
Once you have installed the tool and are ready to check your code using the tool, you might want to consider doing the following first:
- Go to the C# section in Tools -> Options -> TextEditor and change the properties for the tabs so that it inserts spaces and click the OK button
- Open the class file and select all code using CTRL-A
- Now hold the CTRL key and press K, followed by F. This automatically re-aligns the entire class and replaces any tabs in your code with spaces. Do this for all class files in your project.
When you do this, the following will happen in your code.
- Tabs are converted into spaces
- Spacing before and after open and closing parenthesis is adjusted
- Spacing around symbols is adjusted
StyleCop will not give yo any comments about those items. Which leaves the more interesting items to fix.
What's next for StyleCop?
Like all Microsoft tools, this is a work in progress. New features and options will be added and bugs will be fixed. But for the near future, the following has already been announced:
- The tool is still called Source Analysis when you look for it in the Tools menu. It will be renamed to StyleCop
- A small SDK will be made available to allow you to extend the tool with your own rules
- Documentation about the currently available rules (which in fact opens up the Microsoft C# coding standards to the community)
- Automatically change your code to enforce some of the rules
So keep an eye on the StyleCop blog for future releases of this tool. I will be discussing the tool with my team as soon as possible and start using it. Finally a way to have our code look similar!
Introduction
I have been browsing the web for a good and simple class to handle delimited file imports. My current assignment has an import option that needs to deal with that. However, the current implementation (using StreamReader) is not good enough. It doesn't handle all the exceptions you encounter with delimited files. I found a number of examples on the internet, but none of them really suited my needs. What I really missed was a simple example that I could extend so that it would suite my needs. So, being the developer that I am, I created my own class to import delimited files. After this was completed, I though I'd share it as an example to others.
Using StreamReader
The easiest way to process delimited files is to use a StreamReader object. You then simply open the file, read each line and then use the split method to get the various column values. For example:
public void ImportDelimitedFile(string filename, string delimiter)
{
using (StreamReader file = new StreamReader(filename))
{
string line;
while ((line = file.ReadLine()) != null)
{
if (line.Trim().Length > 0)
{
string[] columns = line.Split(delimiter, StringSplitOptions.None);
// Add code to process the columns
}
}
}
}
In a lot of cases this works just fine, but there are limitations to this scenario.
- It's difficult to split a line into columns. For example, when you use Comma Separated File (CSV) it is well possible that a comma is in one of the columns. Using a simple string.Split is therefor not an option
- When you only need certain columns or lines, you will need to scan all of them and handle all lines and filter what you need
- It's not possible to return to a previous line
Using the Jet Engine
The above mentioned problems are eliminated when you use the Jet engine. The following code shows how a CSV file can be processed.
public void ImportCsvFile(string filename)
{
FileInfo file = new FileInfo(filename);
using (OleDbConnection con = new OleDbConnection(
"Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=\"" + file.DirectoryName + "\";Extended Properties='text;HDR=Yes;FMT=Delimited(,)';"))
{
using (OleDbCommand cmd = new OleDbCommand(string.Format("SELECT * FROM [{0}]", file.Name), con))
{
con.Open();
// Using a DataReader to process the data
using (OleDbDataReader reader = cmd.ExecuteReader())
{
while (reader.Read())
{
// Process the current reader entry...
}
}
// Using a DataTable to process the data
using (OleDbDataAdapter adp = new OleDbDataAdapter(cmd))
{
DataTable tbl = new DataTable("MyTable");
adp.Fill(tbl);
foreach (DataRow row in tbl.Rows)
{ // Process the current row...
}
}
}
}
}
As you can see in the example, once you have the Command object, you have the option of using anything a command object will allow you to do. You could process the file using a DataReader object, create a DataTable object containing the data or even add a where clause to the CommandText of your Command object to specifiy better which data is to be imported.
Helper Class
Using this, and the information provided in this Microsoft Article, I created a small class that allows you to import delimited files. The class is very basic, but can easily be extended to suit your specific needs. This class will solve the most important issues when you're going to use Jet as your import engine.
Some things you need to consider when you are importing delimited files, be it with this class or using custom code:
- The Jet engine makes assumptions about the content of the file. This can result in incorrect imports. For example, it might think a column contains date values. But in fact, you're file should treat the columns as a string. In these cases, you should create a Schema.Ini file that describes the type of value for each column. The class creates a Schema.Ini file before it opens the delimited file, but only to specify what the delimiter is. You may want to change this to use pre-defined ini files that describe your input file. Details on the Schema.Ini file can be found here .
- The class uses an OleDbDataReader to read each line in the import file. But it is easily replaced with the option of adding the data into a DataSet or DataTable object. It's also possible to use SqlBulkCopy to instantly insert all the data into a SQL server database.
- The above mentioned Microsoft Article is the best starting point for this type of import. You might want to read that before you start building imports for delimited files, even if this class is usefull to you. The article provides interesting background information and links to various Microsoft resources with more details and information.
- The helper class uses an event to allow you to handle the information being read. You can, of course, also provide an overridable method.
Valuable resources
The information I used to to build this class was found on the Internet. I used the following resources:
Disclaimer
The code presented in the helper class is not an all-purpose import solution. It's just a basic class to help you build your own import class. If you need other import types, or a way to influence the content of the default Schema.ini file, you will need to do that your self. If you find any problems, please feel free to point them out to me.
You can download the file here
This article is also published on CodeProject.com.
A while ago, one of my colleagues (Chi Wai Man) asked about my experience in code reviews, or as I would prefer to call it, code inspections. He is assigned to a project at one of our customers and, triggered by my "This thing is huge post" conducted a little review on the source code in that project. Based on what he then saw (code complexity figures exceeding 50, no code standard) and starting a new project to move from ASP and VB6 to ASP.Net and VB.Net, he wanted to start a code inspection practice in that project. You can read about that here.
If you're a regular visitor of this web log, then you're probably aware that I believe that code inspections can improve the quality of the deliverables. Mr. Man's question triggered me to think about code inspections and how I think this process could (or should) take place. The result is this post, in which I will try to explain how you might setup a formal process to conduct code inspections for .Net applications. It has become quite a large post, my apologies for that. Feel free to comment!
Before I start...
The process I will try to explain is based on the formal process first described my Michael Fagan in 1976. I have experience in conducting code inspections using that formal process at Exact International Development, my previous employer. I helped introduce this process in the Dutch branch of the company and acted as a moderator and inspector on numerous inspections. I was also fortunate enough to be able to introduce this method at other companies while working for LogicaCmg, my current employer.
You may also want to read my views on software development in general and coding standards in particular. The views expressed in that post have influenced the way I look at the code inspection process. Everyone is talking about RUP, MSF, SOA and SOD to just name a few hot development methods and architecture in today's IT business. All claim to help build better software. Yet none of them provided methods to help you improve the quality of your code. And they shouldn't, probably...
A lot of what you'll read in this post is based on past experience and various other resources. Links to related resources are summarized at the end of this post. If you have anything to add, then please let me know. Any suggestions and/or corrections are greatly appreciated. Please keep in mind that I am not explaining or promoting the Fagan process. So if you think stuff is missing or different when you compare it to Fagan methods, you're absolutely right. I use a simplified version of the process, because it makes it easier and faster to implement.
Is code inspection really that useful?
At this moment, there are so many free and commercial tools available that check your source code that you might think it is no longer necessary to check the code your self. I will be the first to admit that more and more checks on your source code can be automated. And that is a good thing. An automated check of your source code will ensure everything is checked against the same basic rules. For example: When you use Microsoft FxCop, the source code is checked for compliance to a large list of rules on various areas such as Globalization, Performance, Security, etc.
From a quality point of view
But there are problems in your code that automated tools cannot (yet) find. And it is likely that a unit test or a functional test might not find as well. A few examples:
The following code shows a method which copies the contents from one typed DataRow object to another.
static void CopyFileRow(myTypedDataset.FileRow source, myTypedDataset.FileRow target)
{ target.Id = source.Id;
target.FileName = source.FileName;
target.DateReceived = source.DateReceived;
}
The compiler will not give you any warnings on this code. FxCop will also tell you everything is fine. But is it really? What if the column DateReceived is allowed to contain a DBNull value? This method could then throw an exception with the message "Cannot get value because it is DBNull" when this is actually the case. It is this type of behavior that you might never find in a unit test or even a functional test. By conducting a human inspection of the code, you might have caught it before the application is tested. And you would have changed the code to something like this:
static void CopyFileRow(myTypedDataset.FileRow source, myTypedDataset.FileRow target)
{ target.Id = source.Id;
target.FileName = source.FileName;
if (!source.IsDateReceivedNull)
target.DateReceived = source.DateReceived;
}
Another example is the following method:
static decimal Division(int a, int b)
{ return a / b;
}
The compiler will not give you any warnings. FxCop will tell you there's nothing wrong. Yet as a .Net developer you should be aware that there are two major problems in this method. The first and most obvious problem is of course a division-by-zero problem. Most developers will immediately notice this, but I still see code like this in numerous applications. But this method will not return the expected result and that's even worse. Try running this method with a = 1 and b = 2. You would expect 0.5 as a result, but the method will actually return 0.
Now I know there are developers that will argue that they never make mistakes like this. And that only inexperienced (or unqualified) developers will make mistakes such as this one. Well, then call me stupid, because this is actually a mistake I made recently. Luckily, this was found during testing. But I wish I had found it before a tester ran into this problem. And yes, I did check the code with FxCop and I have a unit test that runs successfully. So from that perspective I argue that inspecting your code is useful.
From a cost-of-maintenance point of view
This may sound too good to be true, but consider the following scenarios
Scenario 1 - A developer finds the problem before the application is sent to test.
Developer A writes some code and tests it. When he/she finds a problem it will be solved. The code is then retested. This process repeats until the developer no longer finds any problems.
Scenario 2 - A tester finds the problem before it is sent to the user.
Tester B receives an application for test from Developer A. When a problem occurs, the problem is logged and an error description is sent back to Developer A. Developer A tries to reconstruct the problem. The problem is then solved and the code is tested. The application is then sent back to Tester B who can resume testing.
Scenario 3 - A user finds the problem while using the application
User C installs the application developed by Developer A and tested by Tester B. When a problem occurs, the user contacts the helpdesk. They will identify if it is a real problem. If so, the problem is logged and sent to the Tester B. Tester B will verify if the problem still occurs. It might have been solved already. If it is not solved, Tester B sends the error description to Developer A. Developer A then tries to reconstruct the problem. The code is changed to fix the problem and the application is sent to Tester B. Tester B verifies that the problem is solved. When this is the case, the user can redeploy the application with the implemented fix.
Needless to say that it is a lot cheaper to find problems as early as possible. Especially when a user finds a problem. the costs to solve the problem increase enormously. And there's the risk of a damaged reputation for your company. From that perspective, a code inspection process has the potential to reduce the cost-of-maintenance.
The average software projects contains about major 50 defects per 1000 lines of code. You will find this figure being mentioned in various resources. Finding these defects makes sense although it is an illusion to think that we can solve all of them. The code inspection process is one of the things you can do to get rid of as many defects as possible before you deliver the product to the end-user.
There are a number of things you gain from conducting a code inspection:
- Code inspections help reduce the number of technical defects in the code. This will improve the technical quality of the end project.
- When you have less technical defects, you have more time to find functional defects.
- Developers learn from their mistakes and from comments made by their peers. One might expect them to write better code in future projects as a result.
- Improved technical quality will reduce the time lost by testers when they run into a problem that was caused by a technical defect.
- Logging the results of the inspections will give insight in the technical quality of your projects.
- Your product quality will improve and results in a happier customer!
The basic process
Acceptance
An important requisite for an inspection process to be successful, is the acceptance of the process by the developers on the team. If you cannot get the developers to agree to this process, you will never get good results from this process. In those case, you will often see that the inspection process is abandoned, especially when the project reaches the deadline and pressure on the development team increases.
Management must also accept that the inspection process will take up time and resources. They will need to be convinced that the inspection process can improve the quality of the end product. Logging the results of the process and thereby proving that problems have been eliminated before the product reaches the delivery phase can play a vital part in convincing management. The inspection process can be seen as an investment.
Roles
A formal inspection is conducted by an inspection team. The members of this team will have the following roles:
- Moderator. Responsible for administrative tasks, disseminating inspection materials, scheduling meetings, moderating the inspection meeting, collecting data, overseeing follow-up, and issuing the inspection report
- Author. Responsible for the code to be inspected satisfying inspection entry criteria, for providing the overview of the code, for providing clarifications at the meeting, and for rework needed.
- Reader. During the meeting, leads the inspection team through the code being inspected.
- Inspector. Familiarizes himself/herself with the code to be inspected and identifies issues with it
- Recorder. Documents issues, decisions, and recommendations. Records inspection data for process analysis.
It is possible for a member of the inspection team to have more than one role. Exceptions to this are the Author and the Inspector roles. Members of the team with this role should only be concerned with the tasks assigned to that role. The Moderator could be allowed take on the additional roles of Reader and Recorder.
Inspection process
The inspection process consists of 7 steps as can be seen in this flow chart:
The process starts with selecting the code (step 1) that will be inspected. A meeting is planned (step 2) where the inspection team will discuss the results of the inspection. The Inspectors and the Author prepare (step 3) for the meeting by inspecting the code and logging all defects they find. During the meeting (step 4) the Reader leads the members of the inspection team through the code. The Moderator is also in this meeting, making sure everything runs smoothly. During the meeting, the Recorder makes sure all found defects are logged categorized. After the meeting, the Author will fix any defects (step 5) that have been designated for rework. The Author will inform the moderator (step 6) when the defects have been fixed . The moderator will then report the results (step 7).
Artifacts
The code inspection process uses a number of artifacts which are re-used throughout the entire process:
- DefectLog v1.0.XLS. This workbook is a form in which each Inspector (and the Author) log the defects they encounter.
- InspectionReport v1.0.XLS. This workbook is a form which is filled in at the end of the inspection meeting. The log will contain summary data about the inspection.
- InspectionData v1.0.XLS. The results of each inspection are entered in this excel workbook. The accumulated data can be used for reporting to management. The data also gives the inspection teams insight in the improvements they accomplish after conducting inspections.
A sample inspection data report can be downloaded here. It contains data from a project in which I introduced this method of inspections.
There are some other artifacts to consider that can play an additional role in this process:
- Code standards. Every project has one and there's no definite list. I prefer to use standards that can be checked automatically, but there are things that automated checks just can't do. That's the sort of thing I would add to a code standard. But there are so many views on this that I would suggest you use Google to find a version you can live with.
- Check lists. Based on best practices, you should keep a short-list of items to check for when you do a code inspection. Just to make sure you don't forget the most obvious and important checks. A sample for C# can be found here. It's not an ultimate list, just some things I check when I do an inspection of C# code. Check lists should always be work-in-progress. There are checks on the list that can be automated, so in time they could be replaced by new checks that cannot (yet) be automated.
The process in detail
Step 1 - Selection
Roles involved
Description
In the most ideal situation, a code inspection process is put in place when you start with a project. In that scenario, you can start inspections from the moment the first code has been written. The reality however is that code inspections are put in place when a project has been running for months and unexpected behavior is found during testing.
You will need to decide what code is likely to be a candidate for reviewing. To do this, you have the following options:
- Use a code metrics analysis tool which will give you an indication into the code complexity. There are a number of commercial and open-source options available. I have used the community version of DevMetrics in the past, but the company that created that software has stopped development and moved the project to source-forge. Compuware has a commercial product called DevPartner Professional, which I really like. There's also a Reflector Add-in that can do this. Once you know which methods are the most complex, then start inspecting the code that contains these methods.
- From the test results, it is likely that you (or the development team) can pinpoint the problems to only a select number of components. These components are a good place to start.
- Talk to the developers on the current project. They usually have a good idea which code could be a candidate for inspection.
Do not start inspecting any code until the following entry criteria are met:
- All VB.Net code must compile without problems with the following options:
- Option Strict set to On.
- Enable build warnings checked
- Treat compiler warnings as errors checked.
- All C#.Net code must compile without problems with the following options set:
- Warning level 4
- Treat Warnings as errors set to true
- All code must pass the checks that are performed by FxCop or any other code inspection tool such as Compuware Devpartner. When certain checks are ignored, then it should be documented why they are ignored.
- Technical documentation about the code must be present, describing at least the purpose and context of the code.
The entry criteria ensure that a number of obvious checks on the code have already been performed. The inspection tools check the code for naming conventions, best-practices and other common mistakes. The compiler options ensure that the highest level of checks that can be performed by the compiler have been executed. As these are all automated steps, you are guaranteed that all checks always take place and that all code pass at least these checks. Inspectors can focus on other issues.
Step 2 - Planning
Roles involved
Description
Once the code has been selected, it is time for the Moderator to plan the meeting. The code and accompanying documentation is gathered. The Moderator will check if the code meets the entry criteria. If that is the case, team members can be selected for the inspection. The team consists of at least the following members:
- The Moderator. He/she is responsible for the entire process and should be present at the meeting to ensure that meeting is conducted in a proper way.
- At lease two Inspectors. The Inspectors will check the code for defects. You should at least have two inspectors. There will be defects that both Inspectors will find. But more important, you will find that some defects are detected by Inspector A and others by Inspector B.
- The Author. The Author has to be present. He/she knows the exact context and add additional information about the code to the Inspectors.
All team members will receive the following artifacts:
- The code to be inspected.
- Technical documentation.
- Background information.
- Defect log.
There is a limit to the number of code lines that can be reviewed in a amount of time. Based on previous experience, and resources on the Internet confirm this, you get the best results when you review approximately 200 lines of code per hour. In the scatter graph to the right, you can see the effect of the number of lines inspected per hour compared to the number of major defects found. The trend line clearly shows that the more lines that are inspected in one hour, the less major defects are found. The data for this graph was taken from an actual inspection process in one of the projects I was involved in.
You should also try to spend a maximum of 4 hours on inspections as preparation for a meeting. That limits the number of lines for any inspection to roughly 800 lines.
When you take this into account, you should make sure that the team members are properly informed about which part of the code they will receive should be inspected. You must at all times make sure the inspection team all check the same piece of code. For example: When the code selected for inspection is 1500 lines long, then the inspection team will need to know where to start the inspection and where to stop.
Step 3 - Preparation
Roles involved
Description
During the preparation phase, the Inspectors and the Author inspect the code and log the defects they find in the defect log. Each defect should be categorized into one of the following two categories:
- Major defect. A major defect is any problem that will lead to problems when the code is used. This can be a problem that the end user will notice, or one that will cause another piece of code to misbehave. Major defects either change the program source code or would ultimately cause a source code change if not fixed in time.
- Minor defect. A minor defect is anything that doesn't fall into the Major defect category. Think of type errors, not conforming to the naming conventions, no comments in the code, etc.
The inspection team is allowed to use every tool available to them. The Inspectors may also contact the Author in case they need additional information. Neither the Author or the Inspectors are allowed to rework any of the problems. Code should be frozen until after the inspection meeting has taken place. I've had inspection meetings where during the meeting it became apparent that the Author already reworked some parts of the code. This resulted in a completely failed inspection meeting, because a number of the issues found where no longer there. But also, because new problems had been introduced.
Step 4 - Inspection meeting
Roles involved
- Moderator
- Reader
- Recorder
- Author
- Inspectors
Description
When all Inspectors, and the Author, have finished their inspection a meeting is called by the Moderator. The meeting is used to compare the findings and to create an inspection log. This inspection log is actually a accumulation of all defects on each separate defect log. Preferably, the meeting should be scheduled within a 2 or 3 days after the inspection team is invited to the meeting. This will make clear to all team members when their work should be finished.
The reader will lead the inspectors and authors through the code and check if and what kind of defects have been found. All defects will be logged in the Inspection log by the recorder. The Inspection log should also indicate which defects should be fixed during the rework phase.
Step 5 - Rework
Roles involved
Description
After the meeting, the author receives a copy of the inspection log and proceeds to fix the defects. It might happen that not all defects can be solved. If that is the case, then this should be reported back to the moderator. He/She will then need to decide what must be done with these defects.
Reworked code will need to be tested. Although this is not part of the inspection process, it should be clear that any changes to the code will need to be tested to make sure the changes do not introduce new problems in the application.
Step 6 - Follow up
Roles involved
Description
The Author informs the Moderator about the results of the rework he/she has executed. These results will be logged by the moderator and will be used for reporting purposes.
Step 7 - Report results
Roles involved
Description
The moderator now has all information available to update the reports. The data will be entered into the appropriate documents. These documents will be made available to all parties involved, including management. The reports will keep all parties informed on the progress of the inspection process.
Some last remarks
I have experienced problems trying to introduce this process into some of the projects I worked on. Biggest issue has always been trying to convince management to invest in this process. Because let's face it, this process takes time to implement and uses resources that most managers like to assign to actual coding tasks. It becomes increasingly difficult in projects where the deadline is approaching. Yet I found that in those situations, code inspections become even more vital in keeping the quality of the code on an acceptable level.
I said it at the beginning and I'll repeat it again here. This process is how I think it could be done. If you want to introduce a formal code inspection process in your development cycle, then there might be things you want to change. I do think though, that this document can be useful in setting up a formal code inspection process.
Resources
Previous blog posts by me on Code inspection:
Tools
Information on code inspections