How to write highly readable code - 10 coding style tips

When doing code reviews developers get rarely enough time to review the code properly. So, every time when I review I look for certain points to help me quickly to understand the code properly. In this article, it'll be helpful to you all to know how you can write better code so that other developers will get a better understanding. This article will give you a quick introduction to certain techniques that I use when developing applications.

Note that we’ll stick mostly to ReactJS here, but that some of these points which may apply to using other JavaScript libraries as well.

Yes, using comments help most developers to understand the code properly. And it makes your code more readable and easier to understand. Adding comments in react looks like this:

As you can see above this makes your code more readable. This thing makes the developer understand your codebase properly.

If your code is about your sanity, then you should start using a linter right away.

Linters will help you make your code similar to other developers or your teammates, By following this set of rules, you can be certain that your whole codebase will be consistent. For example, if you said your co-worker to add brackets at the start or semicolons at the end of a line. And in case, if they don't then the linter will throw an error or a warning based on your settings.

The Linter which I use is mostly ESLint but you can choose any linter you wish to use.

Whether you are developing a new feature or fixing an error, there are chances that you'll push your code or create a pull request.

The problem with this is that you don't even review your code properly and directly push your code, but the right approach is that you should first check your code and if something is missing you should refactor it properly and then push the code. Practicing this habit, you'll feel that your improving your code might help you.

Splitting your code into multiple smaller functions will make the functions reusable, They'll also make it easier to test.

You can also create many utility files which can help you remove duplicate code from multiple files. After creating multiple files, look at them and you will see that there are many duplicated lines of code. You can take these lines are create a utility file. You can then reuse the same utility file across multiple files.

Reviewing one big file is always harder than reviewing multiple smaller files.

But I suggest you, make multiple files instead of creating one big file. As it's so hard to review code in one big file and it gets so tough code by code.

If you split your code into multiple smaller files and each file contains only one logic, then it becomes very easy for the reviewer to review that particular file.

Another thing you should remember is about while naming your files, it's so important that name your file by the job the file is doing. For eg. You're working on a homepage component in react so the name should be like - HomePage.js or HomePage.jsx, Go with PascalCase for naming your files.

After looking at the name of the file, other developers should understand what the file is supposed to do.

A better way will be to prefix them with the job that they are supposed to perform. For instance, userDropdown.js, fileDropdown.js, etc. Something like this makes it easier and more readable to other developers. As it shows what the job file is performing.

HoC is a good pattern for avoiding code duplication, and because an HoC is a pure function it will not mutate any component.

Definition from React documentation: “Concretely, a higher-order component is a function that takes a component and returns a new component.”

For example, we can create a high-order component that adds an auth guard to our component and show it only if the user is authenticated.

The AuthGuardcomponent checks if the user is logged in, if not logged in, it will render null instead of the component.

Our withAuthGuardHoC looks like this:

Let's take a look at this directory structure below:

src

• components
  • Breadcrumb.js
  • CollapsedSeparator.js
  • Input
    • index.js
    • Input.js
    • utils.js
    • focusManager.js
  • Card
    • index.js
    • Card.js
    • CardDivider.js
  • Button.js
  • Typography.js

Breadcrumbs are commonly known to be associated with some sort of separator as one of their core functionalities. The CollapsedSeparator component is imported inside  Breadcrumb.js, so we know that they are both related to implementation. However, someone who doesn't know this information might assume that Breadcrumband Collapsed Separator is two completely separate components that are not related to each other at all--especially if the CollapsedSeparator does not have any clear indications of it being related to a breadcrumb-like having the prefix (BreadcrumbCollapsedSeparator.js) for example.

And, Folderizing the Breadcrumbs looks like this:

src

• components
  • Breadcrumb
    • index.js
    • Breadcrumb.js
    • CollapsedSeparator.js
    • Expander.js
    • BreadcrumbText.js
    • BreadcrumbHotdog.js
    • BreadcrumbFishes.js
    • BreadcrumbLeftOvers.js
    • BreadcrumbHead.js
    • BreadcrumbAddict.js
    • BreadcrumbDragon0814.js
    • BreadcrumbContext.js
  • Input
    • index.js
    • Input.js
    • utils.js
    • focusManager.js
  • Card
    • index.js
    • Card.js
    • CardDivider.js
  • Button.js
  • Typography.js

And when we write it in a component looks like this:

Something I like to do when writing code is to put things in order, like when importing files (except the react import):

Some of you may think to yourself that this isn't even in alphabetical order. That's only part of what this ordering scheme is.

The way I like to order my imports for a clean approach is using these guidelines, in order of precedence:

React import

Library imports (Alphabetical order)

Absolute imports from project (Alphabetical order)

Relative imports (Alphabetical order)

Yes, I end this post by prettifying your code 😉. We follow neat & clean code, Most of the formatters are available on the marketplace, You can use any code formatted I mostly use Prettier which helps you and your team stay consistent with code formatting. It saves time, and energy, and reduces the need to discuss the style in code reviews. It also enforces clean code practices which you can configure based on your opinions on what feels right and what doesn't.

And we come to the end of this post, I hope you've found these 10 coding style tips helpful. Do like the post, and comment below if you follow any of these tips!