40
loading...
3 Steps Improve Code Readability
Do you want to write great code or step up as a developer? Every programmer wants to write perfect code, but due to ever-demanding business needs, hustle culture, we need to make trade-offs. We often don’t get to write that ideal code we dream of. Despite all that, we can ensure that the code we write is reasonably good. Here are three tips that I use that prevent your code from becoming a noodly mess.
Instead of jumping ahead and starting to code, when you see a problem, take a step back, and I said the problem into a chunk of solvable pieces. You lose the power of visualization when you start dealing with files with classes and functions. The program deconstruction helps us to look at the problems on a deeper level. I often take a piece of paper and lay down the necessary modules to solve the problem and visualize how they interact.
Once you have a solid design, it’s time to poke holes in it and find flaws. Does it bear the load the Product managers going to bring in for the next release? Trust me, “Agile,” “Hustle,” and “startups” are not doing us any favor. You don’t have to over-engineer, but being aware of future changes lets us design change-friendly interfaces.
An intuitive Codebase is a step up from readable code. Remember, you are not coding just for yourself. You are coding for your team, your future self, and as the common joke goes, the Psychopath will take over your code 10 years from now. A well-modularised code that reads like English is much better than a single file with 200 lines.
Look at the following example,
questions = read_quiz_questions()
for question in questions:
display_question(question)
answer = get_answer()
calculate_score(question, answer)Without telling much about what this program does, You understand what’s happening. It’s more than readable. It’s intuitive.
The above methods ensure that the code is easy to consume for other team members or the future you. While these give you reasonably good code, remember that it is just a starting point. Just because you are doing the above three doesn’t mean ignoring test cases, documentation, design patterns, etc. We will touch base on them in future posts.
Originally published at https://thelearning.dev.
40