21.4 Counting lines of code
| Often people like to measure the progress of a software project in terms of the number of lines of code in the project. One reason for doing this is that it may help you come up with a reasonable estimate for how long a project might take. That is, if you feel that project B is similar to project A, and you know that project A used nA lines of code, then you might guess that when you've written nB lines of code on project B, then project B is nB/nA of the way done. Or, again, if you want to add some feature G to a project and you know that the feature G is similar to a feature F that was already added, then once again, you can gauge your progress on feature G by tracking the ratio of nG to nF, where nG would measure the lines of code related to feature G and your baseline nF would measure the lines of code related to feature F. There are professional tools to track the number of lines of code, but here let's just mention a quick and dirty solution. It's a crude technique, but it's easy to use. It lets you come up with a painless, reasonably accurate estimate of how many lines of code you wrote. To count the number of lines of code in all your project files, open up your main project file and use the Edit Find In Files feature to search for the semicolon; in all the *.h and *.cpp files. If you want to count the lines of code in an individual file, you can change the Edit Find In Files to only search in that file. Other than the fact that for loops do introduce two extra semicolons apiece, there is a pretty close one-to-one correspondence between the number of semicolons in your project and the number of lines of code. This rough-and-ready metric can be thrown off a bit if you use a lot of semicolons in your comments. Another mild source of inaccuracy is that *.res files don't have semicolons, so your work on the interface doesn't get counted by the search-for-semicolons metric. To be completely accurate, you can separate out the starting code that you didn't write yourself. In the case of a new Visual Studio project, this will be about 100 lines of code scattered across something like 12 small files. Table 21.1. The number of lines of code in the Pop Framework.
If you keep the source for your successive builds in different directories, and are careful to put the date of the build into the caption bar of your successive builds, you can work out a little table to get an idea of how fast you program. Table 21.1 gives some data on the progress of the author's Pop Framework over the last couple of years . The 'Starting Code' represents the code that the Microsoft Visual Studio automatically generated when the author used the Visual Studio's 'AppWizard' to create a Document-View architecture (MDI) project named Pop. The values of the rates in the last column are deceptively high for the earlier builds, because in those early builds the author was still adding in modules of 'tool class' code that he'd written before. Adding in some old code modules accounts for most of the new lines added between Pop 2 and Pop 4. The lower rates further down the column are more indicative of the actual speed the author programs, even when he's working quite hard. The jump from version 7 to 17 is a little anomalous, as it covers ten versions at once, and these versions were done over a year during which there were long periods when the author wasn't programming at all. Though, all along, he was still thinking about the program. Thinking is slower than typing. The rather substantial jump from Pop 20 to Pop 21 represents the introduction of three-dimensional vectors and OpenGL graphics. As a program gets more developed and starts using high-level classes, you can actually make quite a large change to it with only a few lines. The hard thing, of course, is figuring out the lines. If they involve some tricky new concept like, say, a splitter window, just a dozen lines can take you all day, because most of that day you're reading up on splitter windows . |
