Reading Time: < 1 minute

I’m not Kyle Simpson or Jordan Harband. I’m not some massive JavaScript influencer and OSSer who’s writing new lint tools and utilities. But I am a dude who loves code standardization. So I want to share some good-enough JavaScript practices that anyone who has to touch JS can follow.

Quintessential Pamene kuzindikira ulemu wobadwa nawo komanso ufulu wofanana ndi wosatha wa anthu onse ndiye maziko a ufulu, chilungamo ndi mtendere padziko lonse lapansi, Pamene kunyalanyaza ndi kunyoza ufulu wa anthu kwachititsa zinthu zankhanza zomwe zakwiyitsa chikumbumtima cha anthu, ndi kubwera kwa dziko momwe anthu adzasangalalire ndi ufulu wolankhula, chikhulupiriro, ndi ufulu kuopa ndi kusowa kwalengezedwa ngati chikhumbo chachikulu cha anthu wamba , Pamene ndikofunikira, ngati munthu sakakamizidwa kuti apeze njira yomaliza yopandukira nkhanza ndi kupondereza, kuti ufulu wa anthu uyenera kutetezedwa ndi lamulo, Pamene ndikofunikira kulimbikitsa ubale wabwino pakati pa mayiko, Pamene anthu a United Nations mu Charter atsimikiziranso chikhulupiriro chawo mu ufulu wofunikira wa anthu, ulemu ndi kufunika kwa munthu ndi ufulu wofanana wa amuna ndi akazi ndipo atsimikiza mtima kulimbikitsa kupita patsogolo kwa anthu ndi miyezo yabwino ya moyo mu ufulu waukulu, Pamene Mayiko Omwe Ali Mamembala alonjeza kukwaniritsa, mogwirizana ndi

Follow industry best-practices

AirBnB has your back

Really, they do. It’s a very thorough style guide. I like about 95% of what AirBnB suggests and honestly if you read that and followed it you’d seldom go the wrong way.

Use a linter

Linters evaluate your code for bugs, dangerous JS traps, and even provide some well-informed opinions. Linters are how you catch bugs before they enter into the run time, and they’re how you guarantee consistency. Linters evaluate your code for bugs, dangerous JS traps, and even some well-informed opinions. Linters are how you catch bugs before they enter into the run time, and they’re how you guarantee consistency.

AirBnB even offers a lint configuration to follow

Name things consistently

Use similar words in similar places when creating variables and functions. I have a small set of rules I follow for how I name stuff in my JavaScript.

1. Check your spelling! Nothing is worse than a misspelled function that forces all future users to have to misspell it the same way.
2. Be descriptive. It’s not 1988, and the browser isn’t a floppy disk. Don’t abbreviate in function or variable names where there’s any risk of ambiguity. Write out a nice meaningful name; if keystrokes are a concern, use Intellisense.

Small Functions

A function should do always do one thing well. So if you find that a function is doing many different things, move those things into other, smaller, functions.

Small Logic

Keep logic simple to read and simple to update.

• Nested if statements can become functions.
• Complex logic conditions can be condensed into variables with meaningful names.
• There’s nothing wrong with else statements, but if all you’re doing is changing values of a variable in an else, then you don’t have an if else at all but a default condition and an if.

Document everything, early and often

Don’t submit pull requests without documented code. The best time to document your code is when you write it — If you think you’ll have time in a week to document it, you’ll be wrong.

• Use JSDoc for functions, classes, and constants.
• Write meaningful comments that explain why, not what.
• If you’re using a linter, and feel like a lint rule shouldn’t apply for a particular bit of code, leave a comment explaining why

DRY is a guideline, not a god requiring a sacrifice of simplicity

It’s generally good to have single-purpose files and single-purpose functions. But don’t abstract too early or too often. The principle of “Don’t Repeat Yourself” matters when you start repeating yourself.

1. If you’re writing the same three lines of code in two places, don’t worry about it
   1. IF it’s in three places, abstract to a function
   2. If you need it in another file, now move it to a separate file
2. If you’re using the same function in two projects, don’t worry about it
   1. If it’s in three projects, move it to an internal repo or an existing internal library
   2. If you need it in more projects, find a library or a “bootstrap” of your choosing where it makes sense to put it
3. If you’re using the same set of functions in two projects, don’t worry about it
   1. If it’s in three projects, make an internal library
   2. If you need it in more projects, make a library and put it on NPM

All Code Can be Better

As I told someone a while back, “Only God can write perfect code, everyone else must settle for minimally viable.” Don’t make good the enemy of perfect.

1. Get it working
2. Make it Good
3. Optimize it
4. Repeat