3 ms·

> readability and maintainability are ... actually quite well defined. Would you care to expand on this? My experience has been that readability and maintainab

• klibertp 4y ago
  "Readability" concept, as commonly understood, is a misnomer - when you say something is readable, you most often mean "it's close to my expectations of how it should be written," regardless of how easy or hard it would be to read. This meaning is very subjective, as there are numerous ways of writing the same thing, and which one you would choose depends on everything you've read and written to date. It's pretty trivial to prove how subjective the notion is: find a few lines of code you think are very readable right now and keep them somewhere, then try to read them a year later. New experiences you've had during the year will, with high probability, change the way you'd write that code, making it less (a bit or more, depending on what you experienced) "readable" to you. You can, however, cast readability as a problem in the domain of cognitive science - how easy or hard it is to understand the ideas based on their textual descriptions. We more-or-less know how human memory works: there's a working area, short-term memory, long-term memory, and the need to copy data between these segments. The working area is limited in capacity, short-term memory is volatile, and long-term memory is costly to access. In addition, we know that context switches are expensive, and if they last long enough, they can break the flow - or rather, make your working memory reset itself. You then need to reassemble all the pieces required for solving the problem again, from scratch. Readability is a score that says how many operations your brain must perform before fully converting the description into understanding. The more readable description requires holding fewer pieces/concepts/ideas in your working memory, minimizes the need for context switches, and doesn't rely on long-term memory too much. I felt this would be the case for a long while, but I only recently read a book where most of my suspicions were proved correct. The title is: "The Programmer's Brain - what every programmer should know about cognition," and I can't recommend it enough. It's a bit boring at times, but it provides a good explanation and practical guidelines for writing code that actively supports your cognitive process - or, in other words, is readable. One example: to abbreviate or not? Abbreviation may look more readable because it doesn't obscure other nearby identifiers. On the other hand, each time you see an abbreviation, your brain has to expand it, adding to its workload. In this light, you might be tempted to say that we should never abbreviate identifiers. That is not so: other than the brain, between the code and its understanding sits an eye. AbstractFactoryOfConreteFactoryWorkerBean-style identifiers are just as bad as abbreviations, because then your eye has more work to do. So, keep your identifiers not abbreviated as long as you can see the whole identifier in a single glace - start abbreviating after that. Ideally, keep identifiers between 1 and 5 full words. The book discusses a lot of similar characteristics of source code, presents empirical studies that back up many of its claims, and in general gives you quite a lot of insight into the mechanics of reading (and writing, but less so) programming languages.