Today, my daughter Lisa is born. I was speechless. And I'm so proud.
Just have a peek here.
Windows Workflow Foundation is the programming model, engine and tools for quickly building workflow enabled applications on Windows. It consists of a WinFX namespace, an in-process workflow engine, and designers for Visual Studio 2005. Windows Workflow Foundation is available (currently in beta) for both client and server versions of Windows. Windows Workflow Foundation includes support for both system workflow and human workflow across a wide range of scenarios including: workflow within line of business applications, user interface page-flow, document-centric workflow, human workflow, composite workflow for service oriented applications, business rule driven workflow and workflow for systems management.
Microsoft has published an article on MSDN which is designed to help us developers get started with Windows Workflow Foundation. If you're interested in WWF, then you should definitely check it out. The article starts with explaining what WWF is al about. And next to that you have the Windows Workflow Foundation labs in which you can play with in the Visual Studio Hosted Experience.
The article will give you basic information on the following subjects:
- Creating a first workflow. This is a "Hello World" workflow.
- Receiving and consuming data. Explains how the workflow can receive and consume data.
- The workflow runtime. Explains what the runtime class can handle for you.
- Workflows and activities. An overview of the building blocks that come with WWF.
- Developing a custom activity. Explains how you can add new activities to add to the already existing building blocks.
- A more realistic workflow. Explains how a simple order process with some basic order states can be implemented.
Microsoft is going to replace VBA with Microsoft Visual Studio 2005 Tools for Applications. MVSTA is a subset of the Visual Studio 2005 environment which we all love so much. And it fully supports the .Net framework. It will allow us to develop Office applications using Visual Basic .NET and Visual C#. More information can be found when you follow this link.
I guess a lot of you found this already, but I bumped into the Visual Studio Hosted Experience by accident. This section on the MSDN website allows you to try-out several Visual Studio technologies in on-line labs:
The Visual Studio Hosted Experience allows you to either quickly evaluate Visual Studio .NET 2003, or learn how to build great applications for Windows and the Web with the MSDN Virtual Labs - a series of guided, hands-on labs which can be completed in under an hour. The best part is, you can begin accessing the Visual Studio Hosted Experience immediately with no installation require
Among others, you will find the labs for:
Obviously, the labs will not support all options. But they should give you enough information to see what the product is all about. I'm definitely going to try some of these labs.
In this post, I want to share my experiences with metrics in software development, and more specifically with DevMetrics 2.0 by Anticipating Minds. Metrics are a valuable tool when I need to inspect and/or refactor code. I've blogged about using DevMetrics before and was reminded about this when Rene Schrieken mentioned metrics in his blog.
Metrics tools
As Rene Schrieken already mentioned, metrics can provide information from software projects. This information is usually extracted using tools. Which information is extracted from the projects depend on the tool you use.
I have been using the free community version of DevMetrics for more than a year now, to gather information about my projects and solutions. It integrates into the Visual Studio IDE and provides me with the following information about a Visual Studio C# solution:
- Projects - The number of projects in a solution.
- Files - Number of files in each project and total.
- Classes - Total number of classes in each project and overall.
- Lines of code - Total number of lines in a project and overall.
- Statements - total statements in a project, overall and for each member. Provides average and maximum for projects as well.
- Member functions - Total count for project and overall, average and maximum for projects.
- Statements per member - Average and maximum values for projects and overall.
- Members per class - Average and maximum values for projects and overall.
- Cyclomatic code complexity - Average and maximum for project and detailed measures for each member.
DevMetrics creates an HTML file containing the information. You can click here to see the results for my custom commandbuilder project. I The information in these reports can be used for various purposes, as I will describe below.
There are more tools, obviously. Some are commercial, others are free to use. Check out the links at the end of this post for some examples.
Cyclomatic code complexity
Cyclomatic code complexity calculation is an algorithm to calculate the number of linearly-independent paths in application code. The algorithm was introduced by Thomas McCabe back in 1976 and is language independent. The result of the algorithm provides insight in the complexity of the code.
We all know that the more complex your code is, the more risk you stand of introducing new bugs when you try to fix one. I think everyone will agree to that. Another risk with complex code is the difficulty in transferring the code to other (less experienced) developers. The values calculated by the cyclomatic code complexity algorithm can be used to asses the potential risks in your code. It is the information I use the most when I use DevMetrics.
The following table can be used as a reference for assessing the risks:
| Cyclomatic complexity |
Risk evaluation |
| 1-10 |
Simple, without much risk |
| 11-20 |
More complex, moderate risk |
| 21-50 |
Complex, high risk program |
| greater than 50 |
Untestable program (very high risk) |
For more detailed information on cyclomatic code complexity and possible uses check out the links section at the end of this post.
Complexity / Risk analysis
The first obvious use for cyclomatic code complexity calculations is of course analyzing the complexity of the code and as a result, the risks involved in maintaining the code. You could use the metrics during the development process to keep track of complexity build-up of the code. If you do that, you can decide to refactor at an early stage, rather than wait until you're near the deadline.
Find suspects for Code inspections
When I have to inspect software code, I start by running the metrics tool on my solution. By viewing the results in the report, I can quickly find the areas in the code that have a high risk value. These areas are the ones that I check and comment about. Especially code that has a complexity number that falls into the last two categories of the above table gets my special attention. And believe me, I have found code where the complexity value was greater than 50. Only recently, I was confronted with one method that exceeded 900 lines of code (!!!) and had a complexity value was 88.
Refactoring
The same numbers can be used to decide if a method or class should be refactored or not. Which level of complexity should be refactored is up to the development team. It could be part of a code standard. The great thing about these numbers is that the way they are calculated is well defined. I usually start refactoring when the number exceeds 15. But you will have to keep in mind that refactoring extremely complex methods is a risk in itself. You should carefully weigh the pros and con's of refactoring before you decide to go ahead and do it.
Plan test efforts
As stated earlier, the value calculated is a measurement for the number of linear-independent paths in the code. In simpler terms, the number of different paths you can follow when you run the code. Theoretically, when you write a unit test for a method, the number of tests should at least equal the complexity value for the method. If this is always the case remains to be seen. But what is definitely true, is that the higher the complexity value for a method (or class) the more extensive your unit tests should be.
Conclusion
Code metrics are a very useful tool when developing software. It can give you insight into the complexity and size of your project at any given time. As such, you can use it to help keep the code understandable and reduce risks for maintenance.
Links
A few weeks back I blogged about the Design Guidelines for Class Library Developers. In my private libraries, I had an MyException class which derived from System.Exception. According to the forementioned guidelines, I should have derived from System.ApplicationException instead. The exact guideline states:
Inherit from SystemException only when creating new exceptions in System namespaces. Inherit from ApplicationException when creating new exceptions in other namespaces.
So I changed it, and ran FxCop on my project to check the code and it found a breaking error on MyException?!?!?! It told me this:
For .NET Framework version 1, it was recommended to derive new exceptions from ApplicationException. The recommendation has changed and new exceptions should derive from System.Exception or one of its subclasses in the System namespace. For more information, see Error Raising and Handling Guidelines
Am I misreading the message, or is FxCop really contradicting the guidelines here? Because when I follow the link to the guidelines, it tells me to derive from ApplicationException.