Book Image

Clean Code in JavaScript

By : James Padolsey

Book Image

Clean Code in JavaScript

By: James Padolsey

Overview of this book

Building robust apps starts with creating clean code. In this book, you’ll explore techniques for doing this by learning everything from the basics of JavaScript through to the practices of clean code. You’ll write functional, intuitive, and maintainable code while also understanding how your code affects the end user and the wider community. The book starts with popular clean-coding principles such as SOLID, and the Law of Demeter (LoD), along with highlighting the enemies of writing clean code such as cargo culting and over-management. You’ll then delve into JavaScript, understanding the more complex aspects of the language. Next, you’ll create meaningful abstractions using design patterns, such as the Class Pattern and the Revealing Module Pattern. You’ll explore real-world challenges such as DOM reconciliation, state management, dependency management, and security, both within browser and server environments. Later, you’ll cover tooling and testing methodologies and the importance of documenting code. Finally, the book will focus on advocacy and good communication for improving code cleanliness within teams or workplaces, along with covering a case study for clean coding. By the end of this book, you’ll be well-versed with JavaScript and have learned how to create clean abstractions, test them, and communicate about them via documentation.

Preface

Who this book is for

What this book covers

To get the most out of this book

Section 1: What is Clean Code Anyway?

Section 1: What is Clean Code Anyway?

Free Chapter

Setting the Scene

Setting the Scene

Why we write code

Writing code for humans

The Tenets of Clean Code

The Tenets of Clean Code

Maintainability

The Enemies of Clean Code

The Enemies of Clean Code

Enemy #1 – JavaScript

Enemy #2 – management

Enemy #3 – Self

Enemy #4 – The cargo cult

SOLID and Other Principles

SOLID and Other Principles

The Law of Demeter

The abstraction principle

Functional programming principles

Naming Things Is Hard

Naming Things Is Hard

What's in a name?

Naming anti-patterns

Consistency and hierarchy

Techniques and considerations

Section 2: JavaScript and Its Bits

Section 2: JavaScript and Its Bits

Primitive and Built-In Types

Primitive and Built-In Types

Primitive types

Arrays and iterables

Dynamic Typing

Conversion, coercion, and casting

Operators

What is an operator?

Arithmetic and numeric operators

Logical operators

Comparative operators

Assignment operators

Property access operators

Other operators and syntax

Bitwise operators

Parts of Syntax and Scope

Parts of Syntax and Scope

Expressions, statements, and blocks

Scopes and declarations

Control Flow

What is control flow?

Imperative versus declarative programming

The movement of control

Statements of control flow

Handling cyclomatic complexity

Asynchronous control flow

Section 3: Crafting Abstractions

Section 3: Crafting Abstractions

Design Patterns

Design Patterns

The perspective of a designer

Architectural design patterns

JavaScript modules

Modular design patterns

Planning and harmony

Real-World Challenges

Real-World Challenges

The DOM and single-page applications

Dependency management

Section 4: Testing and Tooling

Section 4: Testing and Tooling

The Landscape of Testing

The Landscape of Testing

What is a test?

Types of testing

Test-Driven Development

Writing Clean Tests

Writing Clean Tests

Testing the right thing

Writing intuitive assertions

Creating clear hierarchies

Providing final clarity

Creating clean directory structures

Tools for Cleaner Code

Tools for Cleaner Code

Linters and formatters

E2E testing tools

Automated builds and CI

Section 5: Collaboration and Making Changes

Section 5: Collaboration and Making Changes

Documenting Your Code

Documenting Your Code

Aspects of clean documentation

Documentation is everywhere

Writing for non-technical audiences

Other Peoples' Code

Other Peoples' Code

Inheriting code

Dealing with third-party code

Communication and Advocacy

Communication and Advocacy

Planning and setting requirements

Communication strategies

Identifying issues and driving change

Case Study

The implementation

Other Books You May Enjoy

Other Books You May Enjoy

Leave a review - let other readers know what you think

Customer Reviews

5 star

0

4 star

0

3 star

0

2 star

0

1 star

0

Handling cyclomatic complexity

Cyclomatic complexity is a measure of how many linearly independent paths there are through a program's code.

Consider a simple program that contains several conditional checks and function invocations:

if (a) {
 alpha();
 if (b) bravo();
 if (c) charlie();
}
if (d) delta();

Even in this misleadingly simple piece of code, nine distinct paths can be taken. So, depending on the values of a, b, c, and d, there are nine possible sequences of alpha, bravo, charlie, and delta that will run:

alpha()
alpha() and bravo()
alpha(), bravo(), and charlie()
alpha(), bravo(), charlie(), and delta()
alpha(), bravo(), and delta()
alpha() and charlie()
alpha(), charlie(), and delta()
alpha() and delta()
delta()

A high level of cyclomatic complexity is undesirable. It can lead to the following:

Cognitive burden: Cyclomatically complex code can be difficult for...