A google search for “What is readability in software engineering?” actually returns a number of interesting results, most of them research papers.
In Code Complete by Steve McConnell, readability is defined as:
The ease with which you can read and understand the source code of a system, especially at the detailed-statement level.
As someone who has been a software developer for some time, readability of code has become one of my main metrics for beauty and usefulness of code. There are some studies of code in the wild which have determined that code is read at least ten times more than it is written. McConnell mentions two studies in Code Complete that provide further detail:
One study found that 10 generations of maintenance programmers work on an average program before it gets rewritten (Thomas 1984). Maintenance programmers spend 50 to 60 percent of their time trying to understand the code they have to maintain, and they appreciate the time you put into documenting it (Parikh and Zvegintzov 1983).
That makes code readability very important. Unclear code usually leads to bugs. Many practicing software devs have inadvertently introduced a bug during refactoring, or accidentally removed functionality, because of confusion around the meaning of code. And if a software developer works with Java, this is all the more likely to be so because Java is so often the choice of large enterprises, where there are hundreds of integration points with other systems.
Based on these two items (the google search and the experience of practicing software developers) readability is important. I don’t think I see enough discussion about readability. It may be worth more thought and discussion by the community. To me, it is just as important as if the code does its job. Unfortunately too many developers are content to leave code as it is the moment they write it, and “work around” it the rest of its life. Here’s to hoping that will change.