Was asked to analyse a library of Visual Basic 6 to determine the effort required to migrate it Visual Basic 2005/2008.
The good news was that most of the VB6 programs share common modules, so it will just be a case of fixing those modules once, then compiling and testing.
The bad news is that, yes, indeedly, the past is another country, they did things differently there; the code isn’t widely documented, and not what you’d call best practice these days.
An example is the use of the RtlCopyMemory function, which now is “banned” by Microsoft as it’s not secure.
Anyhow, to count the lines of VB6 code we have, I used a free utility called VB 6 Pure Code Lines Calculator, and I found it to be fast and accurate.
I would be most
I would like to discuss how you intend to use the line counts to estimate effort. IMO source line counts simply do not contain the information needed to estimate migration effort.
The migration effort is driven by redesign and refactoring activities — and of course regression testing. Clearly generic line counts cannot help you predict these very well. Estimating redesign and refactoring can require some deep, original thought and a tool cannot do that for us. Tools can provide all manner of data about the source, but they cannot tell us how to use that data. Tools also cannot decide for us what our system design should be — they can only provide very crude feedback on what our design cannot be — as in it wont compile in .NET or perhaps a little better it contains code that does not pass an automated code review.
It will take effort just to formulate a new design (aka .NET architecture/development standandards) and then more original thinking to understand the various refactoring transformations required to implement that design. The effort of refactoring iitself is not by lines of code either: it is driven by how much of the refactoring can be automated and how much must be done by hand. Industrial strength migration tools can help you with both the analysis and implementation in this respect. See for example http://www.greatmigrations.com.
And as far as estimating regression testing effort — lets just say it could be big — but that is a discussion for another day.
Migr8tor,
It's worth a follow-up post, that's for sure.
Using line counts gives a raw figure, which allows management to say, we've got 200 KLOC which we need to work on, with 80% of that in module form, that we just need to touch once (ha!).
Tools can highlight the obvious issues, which require attention. But not all of the issues. That will still require a programmer to review the converted code to ensure it works. Y2K code changes on a HUGE scale.
IMHO, the best way way forward for us, would be to get an expert in to convert the code to .Net, and work with us on any functional queries (ie. it looks like you're trying a do XYZ, it that right?)
Regression testing. Yes, testing is where we would be spending most of our time.
Thanks for calling past Migr8tor; I hadn't heard of greatmigrations.com before, I have some reading to do