mirror of
https://github.com/labs42io/clean-code-typescript.git
synced 2024-11-10 08:24:04 +00:00
47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
# clean-code-typescript
|
|
|
|
Clean Code concepts adapted for TypeScript.
|
|
Inspired from [clean-code-javascript](https://github.com/ryanmcdermott/clean-code-javascript)
|
|
|
|
## Table of Contents
|
|
1. [Introduction](#introduction)
|
|
2. [Variables](#variables)
|
|
3. [Functions](#functions)
|
|
4. [Objects and Data Structures](#objects-and-data-structures)
|
|
5. [Classes](#classes)
|
|
6. [SOLID](#solid)
|
|
7. [Testing](#testing)
|
|
8. [Concurrency](#concurrency)
|
|
9. [Error Handling](#error-handling)
|
|
10. [Formatting](#formatting)
|
|
11. [Comments](#comments)
|
|
12. [Translation](#translation)
|
|
|
|
## Introduction
|
|
|
|
|
|
Software engineering principles, from Robert C. Martin's book
|
|
[*Clean Code*](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882),
|
|
adapted for TypeScript. This is not a style guide. It's a guide to producing
|
|
[readable, reusable, and refactorable](https://github.com/ryanmcdermott/3rs-of-software-architecture) software in TypeScript.
|
|
|
|
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!
|
|
|
|
**[⬆ back to top](#table-of-contents)** |