8 JavaScript Habits That Add Value to Your Projects

As developers when we write code we can often get carried away with writing code without much thought just to get things done. Most of the time this won't be a problem until someone reads your code and doesn't understand what is going on. When that happens, you might grow a following of toxic haters who are out to bash you for giving them a hard time when they read your code. Why not just make it easier on yourself and everyone else? You'll sleep better as well as everyone else around you.

With that said, you can start right here in this post!

This post will go over 8 JavaScript Habits that Add Value to Your Projects so that people other than you who are reading your code will value you more. I have been a lead for almost two years and these are the top most loved habits I adapted from my teammates as a Team Lead.

Be a Documenter While You Write

This one makes it to the top of the list because to me this makes my teammates more valuable as opposed to "good" coders who write confusing code! What's the point of collaborating or working together when you're not being a team player?

When you document your code you bring forth a host of benefits, emitting that attractive aura of charisma that give people a sense of security because you're establishing trust and confidence in the code. The more comments a complex code has, the more people would like to have you as a collaborator in a team environment.

Take a look at this example below:

/**
 * true: ".Global.currentUser.vertex.name.firstName@"
 *
 * true: "..message.doc.1.name@"
 *
 * false: "..message.doc.1.name"
 */

export default function isAwaitReference(
  v = '',
): v is ReferenceString<string, '@'> {
  if (v.endsWith('@') && v.substring(v.lengt  - 1) === 'e') return true
  return false
}

Will you be able to understand what this function does without the comments? Probably not. Just by reading the comments we can almost immediately predict what kinds of strings will return true. There's one thing the two examples in the top part of the comments have in common: the @ symbol and ending words with ending letters 'e'. We can say that any string containing dot separated words ending with 'e' followed by @ is called an "await reference".

Documenting your code has good benefits:

1. It helps save everyone time. They don't have to go out of their way to hunt you down for an explanation in the middle of coding something around it.
2. Parsers can capture them. This is a nice benefit because you hit two birds with one stone. Parsers like TypeScript can parse comments and there are generators out there like TypeDoc that can utilize your documentative code including code written using JSDoc syntax. Their example page was automatically generated using TypeDoc.

Here is an example in practice:

This:

Turns into:

3. It helps Junior Developers. When you explain your code with comments you're helping junior developers who are coming in feel more confident jumping straight into the codebase. Junior developers often become frustrated in start up companies because they hardly find documentation for startup code.
4. It makes it more welcoming to introduce complexity in implementation. It's all about readability and maintainability. If you write a function that is complex but have the documentative code to back it all up where it is easy to work from, then it makes up for it.

Adapt to Their Style in Their Code

This is a personal favorite habit that I find valuable in teammates I work with. I am speaking mostly in my experience working with developers in companies.

I have experienced both sides of this habit and it is one of the biggest nerve wrecking pet peeves to read code in the same repo that are not written following the coding style that everyone is following in the repo.

For example, in one of the repos I have worked on we use let and const to declare variables throughout our code. A teammate then wrote this:

Yes it's true that there is nothing wrong with this code and it is just "another way of declaring variables" but var is discouraged because it is less error prone due to the nature of it being function scoped which can lead to unexpected behavior and confusions in shadowing.

The real problem with mixing var with let or const is that if you're debugging a function already written with let (block scoped) and "fixed" a bug within the scope and unknowingly redeclared with var you might be introducing a bug that the original developer already had in mind with var and avoided with let.

Similar Code Implementation with Same Input/Output, Different Files

If you have two functions that do the same thing but are both being imported in different locations, it's time to combine them or import from one location.

The reason this is a bad practice is not only because it's confusing but because if the implementation was updated then all of those functions need to be updated.

I've worked on two in-house sdks where the second one was branched from the first sdk but had some of the major functions copied and pasted, except there were minor updates to parameters along with a single implementation update where it attaches it as a key to an object inside the function block. Both sdks were still being used in conjunction in apps.

It bring problems to the code. It also forces teammates to question your interest, motivation and habits in collaborative projects.

A Reason or Explanation For Every Decision

From experience I realized that teammates grow more respect when I have an explanation for every decision I make in my code, even if it's bad (I learn from them). This is how I feel about teammates who have an answer for every question I have for them. It tells me that they are confident in what they do and they research.

If you use a tool like TypeScript and someone asks you on why you rewrote the function to a class and you give answers like "It's the modern way" they're going to start questioning your confidence in what you write. There's a major difference in positivity if you explained what real benefit you gained from it like "TypeScript is able to infer a lot more types from class syntax". No one's going to say no to that.

Clean Code and Best Practices

The more clean code practices you apply in your code the more developers will pick up from them and follow. By constantly applying best practices in cleaner code you will spend time less debugging and your code will be in the front lines for interns to adapt from so you're actually helping others out as well.

Legacy/Deprecated Syntax When They Were Deprecated for a Reason

Moving away from legacy/deprecated syntax shows that you are keeping up with the latest news in the JavaScript community. This makes you more valuable as a teammate as opposed to someone who doesn't because staying up to date with the latest technology is a good way to stay competitive in the industry (as long as you don't keep things to yourself).

Error Handling

No one likes taking credit for writing code that shipped to production that ends up crashing. Users finding errors before you is the worst case scenario and it happens every day. The less errors you produce in production the more people will be confident in you as a developer.

Handle Variations of Data Type Input

At a really old company I used to work for (prior to being an front end engineer) I had a co-worker that was working there for years. He never talks to anyone but always gets the job done. Whenever he called in sick I would be the one to finish his work. I remember how quickly it stressed me out for just half of the day performing loads of tasks in administrative duties involving heavy manual labor by constantly working with stacks of paper. I knew deep down that the supervisor liked having the employee here because he always handled the work and the supervisor didn't have to worry about that part of his job.

The same concept also applies in code. Handle your data type inputs in your functions and you will save everyone time. People will respect you for validating data inputs.

Conclusion

And that concludes the end of this post! I hope you found this to be useful and look out for more in the future!