Software comprehension is one of the largest costs in the software lifecycle. In an attempt to control the cost of comprehension, various complexity metrics have been proposed to characterize the difficulty of understanding a program and, thus, allow accurate estimation of the cost of a change. Such metrics are not always evaluated. This paper evaluates a group of metrics recently proposed to assess the "spatial complexity" of a program (spatial complexity is informally defined as the distance a maintainer must move within source code to build a mental model of that code). The evaluation takes the form of a large-scale empirical study of evolving source code drawn from a commercial organization. The results of this investigation show that most of the spatial complexity metrics evaluated offer no substantially better information about program complexity than the number of lines of code. However, one metric shows more promise and is thus deemed to be a candidate for further use and investigation.

This paper has briefly presented an approach to identifying the comprehensibility of a program and initial results from its application. The results obtained so far, indicate that this approach is useful in modelling the comprehensibility of a program as it evolves. However further work is required to calibrate this approach to more accurately reflect comprehensibility and to identify at what point corrective action should be undertaken to maintain the quality of the program.

As systems evolve, they become harder to understand because the implementation of concepts (e.g. business rules) becomes less coherent. To preserve source code comprehensibility, we need to be able to predict how this property will change. This would allow the construction of a tool to suggest what information should be added or clarified (e.g. in comments) to maintain the code's comprehensibility. We propose a framework to characterize types of concept change during evolution. It is derived from an empirical investigation of concept changes in evolving commercial COBOL II files. The framework describes transformations in the geometry and interpretation of regions of source code. We conclude by relating our observations to the types of maintenance performed and suggest how this work could be developed to provide methods for preserving code quality based on comprehensibility.