Better code practices, readability.

One feature of a good code practice is its readability.

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.” ― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship.

Photo by Alvaro Reyes on Unsplash.

Code readability is a very good practice in the software environment today. Writing readable code can set the relationships between co-workers and even save you a headache as a person. Why is unreadable code so frowned upon among developers? A code is said to be unreadable if the code is read and it gives no real meaning/understanding to the author or the developer. Sometimes I will write a code and it will be working, fast forward 2 months, I will revisit this codebase and I will not understand a thing, perhaps you have witnessed this situation before. In a block post on Microsoft docs, Paul DiLascia said good code has these clarities: simplicity, readability, modularity, layering, design, efficiency, elegance, and clarity. In this blog post let’s talk about code readability.

Though codes are written for computers to execute the way an author wants it, computers don’t care about how bad you wrote your code, you and your team care about how readable it is. Writing readable code means writing a code that others and you find easy to read. Here are some tips and tricks that will make our code readable:

• Create descriptive names.
• Keep a consistent naming scheme.
• Make comments but don’t overuse them.

Create descriptive names. How variables are named always affects the readability of our code. When naming variables, we must make sure our variable’s names match the use of the variable. We must ask these questions: Do my variable names and class names match what they are used for? Is it best if I named the variable ‘shortestPerson’ or ‘shortest’? Should I name this class ‘print’ or ‘printTheValueOfHeights’? All we must keep in mind is that we must make our variable names and class names depicts the function they perform. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment says, Robert. C. Martin the author of Clean Code: A Handbook of Agile Software Craftsmanship.

Keep a consistent naming scheme. Naming schemes are generally agreed-on schemes for naming things. We must follow the naming scheme of the language we use or the naming scheme of the team we are working on. Usually naming schemes comes in 3 different ways:

1. Pascal case: The first letter of every word in the identifier is upper case. ‘LentghOfTable’.
2. Camel case: The first letter of the first word in the identifier is lower case, while the first letter of every subsequent word is uppercase. ‘lentghOfTable’.
3. Underscores: That is the use of underscore between each word. ‘length_of_table’.

Photo by Christopher Robin Ebbinghaus on Unsplash

In various industries naming schemes shows what type a variable or a class is. For example, whenever I am coding I use camel case for all my public variables, I also use underscores for all my private variables, and lastly, I use pascal case for all my method names. This way if another programmer reads my code and he/she knows the naming scheme it will be easier for him/her to read and understand.

Make comments but don’t overuse them. There is no doubt that good code must have comments, but sometimes we overuse our comments as programmers. The rules of commenting are:

· Don’t comment on the obvious.

· Don’t comment on codes that can be solved with better naming.

When you see commented-out code, delete it! — Robert. C. Martini.

There are many more(Part will come). So the bottom line is comment codes which will not be obvious to another programmer also comments can also indicate why you chose a certain approach over the normal one. Also one mistake sometimes we all make is commenting out the unused code, Robert. C. Martini wrote in his book Clean Code: A Handbook of Agile Software Craftsmanship “when you see commented-out code, delete it!”, this helps in making our code clarified and uncluttered. Code commenting is good, it gives us a clear understanding of the code we write but we must not go overboard.

To conclude.

Code readability is a requirement every developer should take into account. We all must make sure we write codes that others understand. I must confess I am guilty of some of the points I wrote but I am working on them, so it’s never too late to start writing readable and good code. Let us all write good code and save ourselves from a headache the next time we open our projects.

I hope these tips helped you and gave you some idea of how a readable code should look like, if you have any ideas please don’t hesitate to share them with me either in the comments or on Twitter or lets have a cup of coffee on YouTube.

If you enjoyed the article you can leave as many as 50 claps to help us create more content you love, you can also follow for more thoughts about programming, lifestyle, productivity and anything about tech. You can also join our newsletter “Programmer’s diary.” here. I wish you all the best and until next time happy coding.