README

clean-code-javascript

 Table of Contents

1. Introduction
2. Variables
3. Functions
4. Objects and Data Structures
5. Classes
6. SOLID
7. Testing
8. Concurrency
9. Error Handling
10. Formatting
11. Comments
12. Translation

 Introduction

!Humorous image of software quality estimation as a count of how many expletives
you shout when reading code

Software engineering principles, from Robert C. Martin's book
_Clean Code_,
adapted for JavaScript. This is not a style guide. It's a guide to producing
readable, reusable, and refactorable software in JavaScript.

Not every principle herein has to be strictly followed, and even fewer will be
universally agreed upon. These are guidelines and nothing more, but they are
ones codified over many years of collective experience by the authors of
_Clean Code_.

Our craft of software engineering is just a bit over 50 years old, and we are
still learning a lot. When software architecture is as old as architecture
itself, maybe then we will have harder rules to follow. For now, let these
guidelines serve as a touchstone by which to assess the quality of the
JavaScript code that you and your team produce.

One more thing: knowing these won't immediately make you a better software
developer, and working with them for many years doesn't mean you won't make
mistakes. Every piece of code starts as a first draft, like wet clay getting
shaped into its final form. Finally, we chisel away the imperfections when
we review it with our peers. Don't beat yourself up for first drafts that need
improvement. Beat up the code instead!

 Variables

 Use meaningful and pronounceable variable names

Bad:

javascript
const yyyymmdstr = moment().format("YYYY/MM/DD");


Good:

javascript
const currentDate = moment().format("YYYY/MM/DD");


⬆ back to top

 Use the same vocabulary for the same type of variable

Bad:

javascript
getUserInfo();
getClientData();
getCustomerRecord();


Good:

javascript
getUser();


⬆ back to top

 Use searchable names

We will read more code than we will ever write. It's important that the code we
do write is readable and searchable. By _not_ naming variables that end up
being meaningful for understanding our program, we hurt our readers.
Make your names searchable. Tools like
buddy.js and
ESLint
can help identify unnamed constants.

Bad:

javascript
// What the heck is 86400000 for?
setTimeout(blastOff, 86400000);


Good:

javascript
// Declare them as capitalized named constants.
const MILLISECONDS_PER_DAY = 60  60  24  1000; //86400000;

setTimeout(blastOff, MILLISECONDS_PER_DAY);


⬆ back to top

 Use explanatory variables

Bad:

javascript
const address = "One Infinite Loop, Cupertino 95014";
const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s(\d{5})?$/;
saveCityZipCode(
  address.match(cityZipCodeRegex)[1],
  address.match(cityZipCodeRegex)[2]
);


Good:

javascript
const address = "One Infinite Loop, Cupertino 95014";
const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s(\d{5})?$/;
const [_, city, zipCode]

Top issues