From 7139b525264abfc82223cf38882098c49813f8bd Mon Sep 17 00:00:00 2001 From: Romain Lafourcade Date: Sun, 3 Sep 2017 13:18:00 +0200 Subject: [PATCH 1/3] Experimenting with formatting --- README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index ef70ff62..01a197df 100644 --- a/README.md +++ b/README.md @@ -1,18 +1,18 @@ # clean-code-javascript -## Table of Contents +## Table des matières 1. [Introduction](#introduction) 2. [Variables](#variables) - 3. [Functions](#functions) - 4. [Objects and Data Structures](#objects-and-data-structures) + 3. [Fonctions](#fonctions) + 4. [Objets et structures de données](#objects-et-structures-de-donnees) 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) + 9. [Gestion d’erreur](#gestion-d-erreur) + 10. [Formattage](#formattage) + 11. [Commentaires](#commentaires) + 12. [Traduction](#traduction) ## Introduction ![Humorous image of software quality estimation as a count of how many expletives @@ -927,7 +927,7 @@ inventoryTracker('apples', req, 'www.inventory-awesome.io'); ``` **[⬆ back to top](#table-of-contents)** -## **Objects and Data Structures** +## **Objets et structures de données** ### Use getters and setters Using getters and setters to access data on objects could be better than simply looking for a property on an object. "Why?" you might ask. Well, here's an From b30d56c9e700c55988c03e17264d64329664cc07 Mon Sep 17 00:00:00 2001 From: Romain Lafourcade Date: Sun, 3 Sep 2017 13:50:53 +0200 Subject: [PATCH 2/3] Intoduction : premier essai --- README.md | 54 +++++++++++++++++++++++++++--------------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/README.md b/README.md index 01a197df..f58501ae 100644 --- a/README.md +++ b/README.md @@ -4,13 +4,13 @@ 1. [Introduction](#introduction) 2. [Variables](#variables) 3. [Fonctions](#fonctions) - 4. [Objets et structures de données](#objects-et-structures-de-donnees) + 4. [Objets et structures de données](#objects-et-structures-de-données) 5. [Classes](#classes) 6. [SOLID](#solid) - 7. [Testing](#testing) - 8. [Concurrency](#concurrency) - 9. [Gestion d’erreur](#gestion-d-erreur) - 10. [Formattage](#formattage) + 7. [Tester](#tester) + 8. [Simultaneité](#simultaneité) + 9. [Gestion des erreurs](#gestion-des-erreurs) + 10. [Formatage](#formatage) 11. [Commentaires](#commentaires) 12. [Traduction](#traduction) @@ -18,28 +18,28 @@ ![Humorous image of software quality estimation as a count of how many expletives you shout when reading code](http://www.osnews.com/images/comics/wtfm.jpg) -Software engineering principles, from Robert C. Martin's book +Principes d’ingénierie logicielle tirés du livre de Robert C. Martin [*Clean Code*](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882), -adapted for JavaScript. 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 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! +adaptés à JavaScript. Ce guide ne vise pas à définir un style, mais à permettre de produire +un code [lisible, reutilisable, et refactorisable](https://github.com/ryanmcdermott/3rs-of-software-architecture) en JavaScript. + +Les principes contenus dans ce guide ne sont pas tous destinés à être suivis +à la lettre et certains peuvent même provoquer le débat. Ce ne sont que des +lignes directrices, mais elles sont le fruit des années d’expérience des +auteurs de *Clean Code*. + +Notre pratique de l’ingénierie logicielle et vieille d’à peine plus de 50 ans +et nous sommes encore en plein aprentissage. Nous aurons peut-être des rêgles +plus définitive quand l’architecture logicielle sera aussi agée que +l’architecture elle-même mais, en attendant, nous pouvons utiliser ces +lignes directrices pour déterminer la qualité du code que nous produisons. + +De plus, apprendre ces lignes directrices ne va pas instantanément faire de vous +un meilleur développeur et les appliquer pendant des années ne va pas vous +empêcher de faire des erreurs. Nous commencons toujours par coder une ébauche +qui évolue jusqu'à sa forme finale, prète à être fignolée avant d'être montrée +à nos pairs. Au lieu de vous tracassez pour l’état de votre première ébauche, +travailler les détails de votre code petit à petit. ## **Variables** ### Use meaningful and pronounceable variable names @@ -1831,7 +1831,7 @@ async function getCleanCodeArticle() { **[⬆ back to top](#table-of-contents)** -## **Error Handling** +## **Gestion des erreurs** Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function execution on the current stack, killing the From 330552fdf36c3d4d0106ac2af98733e6a631d8f0 Mon Sep 17 00:00:00 2001 From: Romain Lafourcade Date: Sun, 3 Sep 2017 13:55:25 +0200 Subject: [PATCH 3/3] Navigation et formatage --- README.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index f58501ae..c1a2e4c1 100644 --- a/README.md +++ b/README.md @@ -41,7 +41,7 @@ qui évolue jusqu'à sa forme finale, prète à être fignolée avant d'être mo à nos pairs. Au lieu de vous tracassez pour l’état de votre première ébauche, travailler les détails de votre code petit à petit. -## **Variables** +## Variables ### Use meaningful and pronounceable variable names **Bad:** @@ -199,7 +199,7 @@ function createMicrobrewery(breweryName = 'Hipster Brew Co.') { ``` **[⬆ back to top](#table-of-contents)** -## **Functions** +## Fonctions ### Function arguments (2 or fewer ideally) Limiting the amount of function parameters is incredibly important because it makes testing your function easier. Having more than three leads to a @@ -927,7 +927,7 @@ inventoryTracker('apples', req, 'www.inventory-awesome.io'); ``` **[⬆ back to top](#table-of-contents)** -## **Objets et structures de données** +## Objets et structures de données ### Use getters and setters Using getters and setters to access data on objects could be better than simply looking for a property on an object. "Why?" you might ask. Well, here's an @@ -1025,7 +1025,7 @@ console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe **[⬆ back to top](#table-of-contents)** -## **Classes** +## Classes ### Prefer ES2015/ES6 classes over ES5 plain functions It's very difficult to get readable class inheritance, construction, and method definitions for classical ES5 classes. If you need inheritance (and be aware @@ -1246,7 +1246,7 @@ class Employee { ``` **[⬆ back to top](#table-of-contents)** -## **SOLID** +## SOLID ### Single Responsibility Principle (SRP) As stated in Clean Code, "There should never be more than one reason for a class to change". It's tempting to jam-pack a class with a lot of functionality, like @@ -1676,7 +1676,7 @@ inventoryTracker.requestItems(); ``` **[⬆ back to top](#table-of-contents)** -## **Testing** +## Tester Testing is more important than shipping. If you have no tests or an inadequate amount, then every time you ship code you won't be sure that you didn't break anything. Deciding on what constitutes an adequate amount is up @@ -1743,7 +1743,7 @@ describe('MakeMomentJSGreatAgain', () => { ``` **[⬆ back to top](#table-of-contents)** -## **Concurrency** +## Simultaneité ### Use Promises, not callbacks Callbacks aren't clean, and they cause excessive amounts of nesting. With ES2015/ES6, Promises are a built-in global type. Use them! @@ -1831,7 +1831,7 @@ async function getCleanCodeArticle() { **[⬆ back to top](#table-of-contents)** -## **Gestion des erreurs** +## Gestion des erreurs Thrown errors are a good thing! They mean the runtime has successfully identified when something in your program has gone wrong and it's letting you know by stopping function execution on the current stack, killing the @@ -1904,7 +1904,7 @@ getdata() **[⬆ back to top](#table-of-contents)** -## **Formatting** +## Formatage Formatting is subjective. Like many rules herein, there is no hard and fast rule that you must follow. The main point is DO NOT ARGUE over formatting. There are [tons of tools](http://standardjs.com/rules.html) to automate this. @@ -2036,7 +2036,7 @@ review.perfReview(); **[⬆ back to top](#table-of-contents)** -## **Comments** +## Commentaires ### Only comment things that have business logic complexity. Comments are an apology, not a requirement. Good code *mostly* documents itself. @@ -2157,7 +2157,7 @@ const actions = function() { ``` **[⬆ back to top](#table-of-contents)** -## Translation +## Traduction This is also available in other languages: