CODE READABILITY

Programmers complain about readability and talk about bad code and unclean code, and the difficulties they run into trying to understand and maintain that code. What do we mean by code readability? What makes code unreadable?

Code readability is one of the most important qualities of good code, like the art of writing code it’s a subjective topic which varies between developers.

If code is easy to read, it will be easy to understand which makes it easy to debug, maintain and extend. Writing readable code is easier said than done, making complicated code easy to read and understand is a very difficult skill. Learning to make code readable/understandable is difficult for inexperienced developers to not only do but understand because it can be difficult to quantify the differences between readable code and un-readable code.

It often easy to spot good code and even (often) easier to spot bad code but when asked to explain why some code is good and other code is bad a lot of developers will shrug there shoulders and just say “Because it is”. Similar to when you know something isn’t right, it doesn’t feel right but you are not sure why.

What really makes code readable?

Comments — people might think the way to make your code readable is put loads of comments in it. Some well placed comments will certainly help when you get to a tricky bit but most code should be self commenting by using well named variables, functions, classes etc. More comments does not equal better readability and in some cases extra comments can just clutter up the code. Well structured code — well structured code is split up into logical/well named classes and methods. “Codes should have a clear purpose. Small is beautiful. Small is beautiful — methods and classes should not be to long, if they are the code is doing too much. Methods should do one thing and decoupled (which will allow for reuse)

Reframing the Problem — By analogy, plenty of people find reading Homer, Shakespeare, or Nabokov difficult and challenging, but we don’t say “Macbeth is unreadable.” We understand that the problem lies with the reader. We may not have sufficient experience with the language and idioms. We may not have enough historical and cultural context (similar to lacking domain expertise when looking at software). We may not have the patience or desire to invest time learning how to read a challenging book. Wikipedia articles and Cliff’s Notes exist to give tl;dr versions of books to people who can’t or don’t want to read the original. When we observe this tendency in other (non-programming) contexts we may interpret it as laziness or short attention span. When we react this way to code we blame the code and the original programmer.

Programmer Bias — Programmers looking at code they don’t understand or don’t like can find examples of sacred principles and so-called best practices violated: “This breaks the Single-Responsibility Principle.” “This looks like a DRY violation.” “Globals are a code smell.” Then they propose rewriting the system, or maybe rewriting pieces of it in their preferred language, idiom, and style (often erroneously called “refactoring” because that sounds like a technical thing to the customer or boss).

“Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent. — Martin Fowler.”

All respect to Martin Fowler, but those quotes illustrate my point. My experience leads me to expect I will “have to think” to understand unfamiliar code. How hard I have to think matters, but I don’t expect to immediately understand non-trivial code at a glance, with my infinitesimal experience. After I understand the code I may think I can write it more clearly and refactor it, or I may feel like I learned something new from the code and leave it alone. I don’t think code has to yield to understanding at a glance, especially considering the very wide range in skills and experience among programmers. And I don’t call other programmers fools if I don’t immediately understand their code. “Other humans,” or even other programmers, includes far too many people across a vast skill and experience spectrum to make “write code that humans can understand” a meaningful goal. If good authors wrote books that everyone could instantly understand we’d have nothing but The Hungry Caterpillar and Puppy Peek-a-boo on our bookshelves.

“Just because people tell you it can’t be done, that doesn’t necessarily mean that it can’t be done. It just means that they can’t do it. — Anders Hejlsberg”

That applies just as much when reading code as it does when writing code. Remember that the next time you or someone you work with declares some code “unreadable” and “impossible to maintain.”

“The true test of intelligence is not how much we know how to do, but how to behave when we don’t know what to do. — John Holt”

Better programming comes through practice, study (from books and other code), and mentoring. It doesn’t come from trying to blindly adhere to rules and dogma and cargo cults you don’t understand or can’t relate to actual code. MAKE IT PLAIN…

Related posts:

I registered as a teacher but have been rejected. Could you please let me know the problem?. It could be either one of the below issues. Please check your document and contact support staff Tom if the problem persists..

How is it that we are below-ground for so much longer than we walk the surface? At least the carbon, anyway. How can a half-life be longer than a life? How can our imprint be tallied up to a stain of…

Hasz Suit and Uniform adalah konveksi yang menyediakan jasa pembuatan baju seragam kerja, seragam sekolah, kaos seragam, baju kantor dan sejenisnya. Kami memberikan kemudahan akses informasi tentang…