Reading is what? Fundamental!
We passed the era of low level punch-card programming, assembly language has become a narrow niche; even C/C++ is no longer the default tool of choice in software development, meaning you have no excuse for not making your code readable.
“Clean code should read like well-written prose”
— Robert C. Martin
“Clean code should read like well-written prose” — I’d like to make it a bit more personal: “Your code should read like well-written prose”.
Readability goes hand in hand with maintainability. Be kind to future generations of developers who will have to read and maintain that codebase you created/contributed to.
When I’m doing code review I expect to read that code like a novel, get insight into application logic, developer’s reasoning, dramatic edge cases, thrilling twists and turns that culminate in elegant solution. Your code should comment itself. Which brings me to the point that it is very hard to write readable code if you are not reading! Books (and, arguably, media articles, blog posts and similar outlets) are strictly necessary for writing maintainable code that reads well.
Need a break or time off? Enjoy it with a book, it will pay off in the future big time. I’m even confident enough to speculate that literature majors will make excellent modern day software developers because they read a lot. Reading and vocabulary gives them great advantage when they are communicating problems, features, and written as code solutions.
Let’s do a basic, real life JavaScript example, this is what I see as unreadable code:
As you can see, it’s not clear what’s going on there. Convert? Convert what to what? What’s the context? acc? k? v? This code snippet is simple enough for you to tell what it is doing but other than that? Nothing. Now imagine this mess on a larger scale, application-wide scale?
Now let’s make it a little bit better:
Now we can see the context and can clearly tell what is going on here. It’s the conversion function for converting coordinates in the user input into internal zero-based drawing system.
Now how can we make it even better? That’s right, we need to get rid of the ternary operator. Ternary operator is not readable at all and better to avoid it as much as possible. To get rid of it and clearly communicate our intent we will need to utilize our domain knowledge.
Domain in which you are developing applications is very important, so read up about your industry, read industry-related books and articles, and on a micro-scale: engage in stakeholder meetings, read the requirements, communicate with product management.
It this case, our domain knowledge (and this code snippet!) tells us that users pass a lot of additional parameters that are not coordinates (not numbers) so we can default updatedValue variable to the direct value we got from a user and only convert when we are sure that value should be converted (a number). Ternary operator is gone.
Even though example was in JavaScript, code written with all high-level languages (Python, Java, JavaScript, GO, Scala etc etc) can be and should be readable. So go pick a book and go read, my darlings!
P.S. Even though the meaning of the word “read” in RuRaul’s show is completely different from the literal one I’m using for programming or software development, I decided to use it in supporting pictures because of the charisma, uniqueness, nerve, and talent with which this message is being communicated in the show.
P.P.S. Although, “reading” with the RuPauls’s show context can jokingly be used in software development, assuming the right and friendly setting: “I’m not just gonna read your Pull Request, I’ll read it for filth!”
