In modern software engineering, the maintenance usually consumes 70% of the total life cycle cost of a software product \cite{Buse_2010} while the most time-consuming task in the maintenance is reading source code. I am confident that the percentage of maintenance in the total life cycle will keep growing in the next decades, therefore, maintain a highly-readable source code is significant to any enterprise software products. \cite{Buse_2010} conducted a survey of 120 human annotators on 100 code snippets, presented a novel descriptive model of software readability and revealed significant correlations between their metric for readability and external notions of quality. \cite{Siegmund_2017} contrasted bottom-up and semantic cues comprehensions by fMRI, and found that comprehension based on semantic cues leads to a lower activation intensity as compared to bottom-up comprehension and leads to neural efficiency. \cite{Barnett_2015} proposed a tool to investigate changesets for review. They conducted both quantitative evaluation and qualitative user study and showed that it can be used widely, at least at Microsoft and most developers agree with the proposed decomposition.
In the past, we usually focus on text features to measure the code readability, i.e. line length, number of keywords/parentheses etc. However, some source code, even with extremely easy-to-understand text features, is still hard to understand. For example, the famous Fast Inverse Square Root Method appeared in the Quake III engine:
float InvSqrt (float x)
{
float xhalf = 0.5f*x;
int i = *(int*)&x;
i = 0x5f3759df - (i>>1); // seems simple, but what's this?
x = *(float*)&i;
return x*(1.5f - xhalf*x*x);
}