When optimising for speed, profiling first can help focus the effort on the parts of the code that bring most benefit. Since speed can be measured objectively, the benefit can also be measured objectively by profiling before and after making a change.
Is there any analogous approach when optimising for readability? I'm not expecting to find a method of saying objectively that one version of the code is more readable than another. Measuring by profiling before and after a change is therefore out of scope. Instead I'm looking for ways of identifying parts of the code that would most benefit from an improvement in readability. How to make any improvement will still be a human judgement call.
For example, even if a section of code is already more readable that other sections, it may still be the most beneficial place to make a further readability improvement if it is read more often.
In thinking this through I've considered the following as possibilities:
- Measuring how many other parts of the code depend on this part
- Measuring how frequently this part is edited
- Measuring how frequently parts of the code that depend on this part are edited
- Measuring how much time is spent per change to this part of the code
What I'm trying to indirectly measure is "How much time is spent reading this part of the code?". I'm trying to think of indirect approaches because I can't think of a currently practical way of directly measuring how long is spent reading code. I want ways of estimating this using data that is already being recorded, rather than something impractical/intrusive like setting up eye tracking for everyone who works on the codebase.
I'm assuming that code that is read often is worth making more readable, and that code that is read slowly is worth making more readable. Estimating the total length of time spent reading each part of the code seems like a good way of capturing both cases.
Measuring which parts of the code are dependent on which other parts requires knowledge of the specific programming language(s) being used. Measuring how frequently part of the code is changed or how much time is spent per change could potentially be done in a language agnostic way using version control data. Time spent per change probably can't be measured in any meaningful way for individual changes, but I include it in case there is some way of estimating it as a long term average (perhaps from the average lifetime of raised issues that went on to involve a change to that part of the code?).
I can imagine version control based results being very tailored to the particular team that happened to be working on the code during the period of measurement, but if the team working on the code in future will be mostly the same people I can see this as being useful. In some cases tailoring to a specific team may even be preferable.
My guess is that building such a profiler will be more effort than it is worth for an individual team working on a specific project. Ideally I'd like to find an approach that can be as widely used as possible, making it worthwhile as an open source project to be used by anyone. For this reason I'd lean more towards language agnostic approaches, but I'm open to arguments that a language specific approach would be worth the effort.