Sometimes, as the developer when we write the code we might want to get the job done quickly without much thought. Most of the time this might not be a problem until someone reads your code or you get back to work with it again after several months.
When that happens, your colleague might come up with the question "Why do you write the code like this?". Why not make it easier to read from the beginning?
In this post, we will go over 6 good habits as a developer that can add value to your projects so that people who read your code will be more appreciative of what you did.
1. Always document your code
I will prioritize this to the top of the list. What is the point when you write really good code, but no one understands it and also has no idea how to use or provide an option to it?
Why should we document our code?
It can save everyones time, they don't need to dig deeper into each function you wrote just to make sure how to use it. If you write JSDoc for the comment, it will show through IntelliSense in most editors.
Let's check the function below:
type ParserOptionType = {
/**
* Capitalized your attribute name.
* @example
* ```
* const data = parser("{ 'name': 'Hello World' }", { useCapitalize: true });
* console.log(data); // { 'Name': 'Hello World' }
* ```
*/
useCapitalize?: boolean;
/**
* Using UTC Date String if specified as True, otherwise showing the timezone.
* @example
* ```
* const data = parser("{ 'dob': '2022-01-31' }", { showJSONDate: true });
* console.log(data); // { 'dob': '2022-01-31T00:00:00.000Z' }
*
* const data = parser("{ 'dob': '2022-01-31' }", { showJSONDate: false });
* console.log(data); // { 'dob': '2022-01-31T00:00:00.000+0700' }
* ```
*/
useUTCDate?: boolean;
}
/**
* Parse the JSON Object from the plain text.
* @params text The text that you want to parse.
* @params options Additional options for customize your returned object.
* @returns The parsed JSON object from the provided options.
*/
function parser(text: string, options: ParserOptionType) {
return Object.assign({});
}
When other developers provide the options parameter, they will understand easier how to use it by just hovering their mouse pointer over the parameter that they want.
2. Implement clean code and adhere to best practices
By constantly applying best practices in cleaner code you will spend less time debugging and your code will be in the front lines for interns to adapt from so you’re actually helping others out as well.
You can find a lot of best practices of the language that you work with just typing in the search engine with this keyword
[language] best practices github
I search with this keyword and always get up-to-date information. Searching for GitHub repositories you will find many people trying to share their thought, you can join the discussion and help shape best practices of a framework/language.
3. Avoiding deprecated/legacy code as much as possible
Moving away from legacy/deprecated code shows that you are keeping up with the latest news in the JavaScript community. Also, you can explain or review the code of your colleague if you know which code/functions are deprecated.
4. Always handle the errors
No one is proud of writing code that is shipped to production that ends up crashing. Users finding errors before you is the worst-case scenario and it happens every day. The fewer errors you produce in production the more people will be confident in you as a developer.
5. Always gather all requirements or ask before starting
Many developers believe they are not good with communicators. But it is really important to gather all of the requirements, limitations, rules, and logic from clients or businesses before starting to write any single line of code.
Is there anything worse than you write the code that others don't want or violent the project rules or limitations? Or even more than is required?
Developers who take more time to understand the problems before they actually start will work more efficiently.
6. Implement the same coding styles
To be a good team player, developers should have the rules or policies to write the code in the same style to prevent conflicts and improve the readability of the codebase. It will be easier if everyone writes code in the same style.
People will easily catch the weird code smell if someone does not follow the style. This just makes it easier in the code review process.
The most practical way is to integrate a Linter into the project. You can set up rules or warnings if some agreement was discussed and decided up-on with your team.
Conclusion
Coding is just like art, it can be a masterpiece or an ugly picture depending on the artist who painted it. Why not bring pleasure to the person who reads it?
At OOZOU, we stay up to date and help each other review their code. We have an adored community that always shares the best practices, tips, and tricks across multiple projects each month!
I'm a fullstack javascript developer who love talking about architecture, system design, framework and libraries, developer mindset. I also interesting in business and investing as well.
