├── .gitattributes
├── LICENSE
└── README.md


/.gitattributes:
--------------------------------------------------------------------------------
1 | *.md linguist-documentation=false
2 | *.md linguist-language=JavaScript
3 | 


--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
 1 | The MIT License (MIT)
 2 | 
 3 | Copyright (c) 2017 Ryan McDermott, Felipe Santos
 4 | 
 5 | Permission is hereby granted, free of charge, to any person obtaining a copy
 6 | of this software and associated documentation files (the "Software"), to deal
 7 | in the Software without restriction, including without limitation the rights
 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 | 
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 | 
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
   1 | # clean-code-javascript
   2 | 
   3 | ## Índice
   4 |   1. [Introdução](#introdução)
   5 |   2. [Variáveis](#variáveis)
   6 |   3. [Funções](#funções)
   7 |   4. [Objetos e Estruturas de Dados](#objetos-e-estruturas-de-dados)
   8 |   5. [Classes](#classes)
   9 |   6. [Testes](#testes)
  10 |   7. [Concorrência](#concorrência)
  11 |   8. [Tratamento de Erros](#tratamento-de-erros)
  12 |   9. [Formatação](#formatação)
  13 |   10. [Comentários](#comentários)
  14 | 
  15 | ## Introdução
  16 | ![Imagem humorística da estimativa de qualidade do software baseado na contagem de quantos palavrões você gritou enquanto lia o código.](http://www.osnews.com/images/comics/wtfm.jpg)
  17 | 
  18 | Princípios da Engenharia de Software, do livro de Robert C. Martin
  19 | [*Código Limpo*](https://www.amazon.com.br/C%C3%B3digo-Limpo-Habilidades-Pr%C3%A1ticas-Software/dp/8576082675),
  20 | adaptados para JavaScript. Isto não é um guia de estilos. É um guia para se produzir código legível, reutilizável e refatorável em JavaScript.
  21 | 
  22 | Nem todo principio demonstrado deve ser seguido rigorosamente, e ainda menos são os que possuem consenso universal. São orientações e nada mais, entretanto, foram usadas em código durante muitos anos de experiencia coletiva pelos autores de *Código limpo*.
  23 | 
  24 | Nosso ofício de engenharia de software tem pouco mais de 50 anos e ainda estamos aprendendo muito. Quando a arquitetura de software for tão velha quando a própria arquitetura, talvez então tenhamos regras mais rígidas para seguir. Por enquanto, deixe que estas orientações sirvam como critério para se avaliar a qualidade de código JavaScript que tanto você e o seu time produzirem.
  25 | 
  26 | Mais uma coisa: aprender isto não irá lhe transformar imediatamente em um desenvolvedor de software melhor e trabalhar com eles por muitos anos não quer dizer que você não cometerá erros. Toda porcão de código começa com um rascunho, como argila molhada sendo moldada em sua forma final. Finalmente, talhamos as imperfeições quando revisamos com nossos colegas. Não se bata pelos primeiros rascunhos que ainda precisam de melhorias. Ao invés, bata em seu código.
  27 | 
  28 | ## **Variáveis**
  29 | ### Use nomes de variáveis que tenham significado e sejam pronunciáveis
  30 | 
  31 | **Ruim:**
  32 | ```javascript
  33 | const yyyymmdstr = moment().format('YYYY/MM/DD');
  34 | ```
  35 | 
  36 | **Bom:**
  37 | ```javascript
  38 | const currentDate = moment().format('YYYY/MM/DD');
  39 | ```
  40 | **[⬆ voltar ao topo](#Índice)**
  41 | 
  42 | ### Use o mesmo vocabulário para o mesmo tipo de variável
  43 | 
  44 | **Ruim:**
  45 | ```javascript
  46 | getUserInfo();
  47 | getClientData();
  48 | getCustomerRecord();
  49 | ```
  50 | 
  51 | **Bom:**
  52 | ```javascript
  53 | getUser();
  54 | ```
  55 | **[⬆ voltar ao topo](#Índice)**
  56 | 
  57 | ### Use nomes pesquisáveis
  58 | Nós leremos mais código do que jamais seremos capazes de escreveremos. É importante que o código que escrevemos seja legível e pesquisável. *Não* dando nomes em variáveis que sejam significativos para entender nosso programa, machucamos nossos leitores. Torne seus nomes pesquisáveis. Ferramentas como [buddy.js](https://github.com/danielstjules/buddy.js) e [ESLint](https://github.com/eslint/eslint/blob/660e0918933e6e7fede26bc675a0763a6b357c94/docs/rules/no-magic-numbers.md) podem ajudar a identificar constantes sem nome.
  59 | 
  60 | **Ruim:**
  61 | ```javascript
  62 | // Para que diabos serve 86400000?
  63 | setTimeout(blastOff, 86400000);
  64 | 
  65 | ```
  66 | 
  67 | **Bom:**
  68 | ```javascript
  69 | // Declare-as como `const` global em letras maiúsculas.
  70 | const MILLISECONDS_IN_A_DAY = 86400000;
  71 | 
  72 | setTimeout(blastOff, MILLISECONDS_IN_A_DAY);
  73 | 
  74 | ```
  75 | **[⬆ voltar ao topo](#Índice)**
  76 | 
  77 | ### Use variáveis explicativas
  78 | **Ruim:**
  79 | ```javascript
  80 | const address = 'One Infinite Loop, Cupertino 95014';
  81 | const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s*(\d{5})?$/;
  82 | saveCityZipCode(address.match(cityZipCodeRegex)[1], address.match(cityZipCodeRegex)[2]);
  83 | ```
  84 | 
  85 | **Bom:**
  86 | ```javascript
  87 | const address = 'One Infinite Loop, Cupertino 95014';
  88 | const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s*(\d{5})?$/;
  89 | const [, city, zipCode] = address.match(cityZipCodeRegex) || [];
  90 | saveCityZipCode(city, zipCode);
  91 | ```
  92 | **[⬆ voltar ao topo](#Índice)**
  93 | 
  94 | ### Evite Mapeamento Mental
  95 | Explicito é melhor que implícito.
  96 | 
  97 | **Ruim:**
  98 | ```javascript
  99 | const locations = ['Austin', 'New York', 'San Francisco'];
 100 | locations.forEach((l) => {
 101 |   doStuff();
 102 |   doSomeOtherStuff();
 103 |   // ...
 104 |   // ...
 105 |   // ...
 106 |   // Espera, para ques serve o `l` mesmo?
 107 |   dispatch(l);
 108 | });
 109 | ```
 110 | 
 111 | **Bom:**
 112 | ```javascript
 113 | const locations = ['Austin', 'New York', 'San Francisco'];
 114 | locations.forEach((location) => {
 115 |   doStuff();
 116 |   doSomeOtherStuff();
 117 |   // ...
 118 |   // ...
 119 |   // ...
 120 |   dispatch(location);
 121 | });
 122 | ```
 123 | 
 124 | **Melhor:**
 125 | ```javascript
 126 | const locations = ['Austin', 'New York', 'San Francisco']
 127 | 
 128 | const doStuff = (element, index) => {}
 129 | const doSomeOtherStuff = (element, index) => {}
 130 | const dispatchLocation = (accumulator, current) => {}
 131 | 
 132 | const locationsAll = locations.map(doStuff)
 133 |                               .map(doSomeOtherStuff)
 134 |                               .reduce(dispatchLocation)
 135 | });
 136 | ```
 137 | **[⬆ voltar ao topo](#Índice)**
 138 | 
 139 | ### Não adicione contextos desnecessários
 140 | Se o nome de sua classe/objeto já lhe diz alguma coisa, não as repitas nos nomes de suas variáveis.
 141 | 
 142 | **Ruim:**
 143 | ```javascript
 144 | const Car = {
 145 |   carMake: 'Honda',
 146 |   carModel: 'Accord',
 147 |   carColor: 'Blue'
 148 | };
 149 | 
 150 | function paintCar(car) {
 151 |   car.carColor = 'Red';
 152 | }
 153 | ```
 154 | 
 155 | **Bom:**
 156 | ```javascript
 157 | const Car = {
 158 |   make: 'Honda',
 159 |   model: 'Accord',
 160 |   color: 'Blue'
 161 | };
 162 | 
 163 | function paintCar(car) {
 164 |   car.color = 'Red';
 165 | }
 166 | ```
 167 | **[⬆ voltar ao topo](#Índice)**
 168 | 
 169 | ### Use argumentos padrões ao invés de curto circuitar ou condicionais
 170 | 
 171 | **Ruim:**
 172 | ```javascript
 173 | function createMicrobrewery(name) {
 174 |   const breweryName = name || 'Hipster Brew Co.';
 175 |   // ...
 176 | }
 177 | 
 178 | ```
 179 | 
 180 | **Bom:**
 181 | ```javascript
 182 | function createMicrobrewery(breweryName = 'Hipster Brew Co.') {
 183 |   // ...
 184 | }
 185 | 
 186 | ```
 187 | **[⬆ voltar ao topo](#Índice)**
 188 | 
 189 | ## **Funções**
 190 | ### Argumentos de funções (idealmente 2 ou menos)
 191 | Limitar a quantidade de parâmetros de uma função é incrivelmente importante porque torna mais fácil testá-la. Ter mais que três leva a uma explosão combinatória onde você tem que testar muitos casos diferentes com cada argumento separadamente.
 192 | 
 193 | Nenhum argumento é o caso ideal. Um ou dois argumentos é bom, e três deve ser evitado. Qualquer coisa a mais que isso deve ser consolidado. Geralmente, se você tem mais que dois argumentos então sua função esta tentando fazer muitas coisas. Nos casos em que não esta, na maioria das vezes um objeto é suficiente como argumento.
 194 | 
 195 | Já que JavaScript nos permite criar objetos instantaneamente, sem ter que escrever muita coisa, você pode usar um objeto se você se pegar precisando usar muitos argumentos.
 196 | 
 197 | **Ruim:**
 198 | ```javascript
 199 | function createMenu(title, body, buttonText, cancellable) {
 200 |   // ...
 201 | }
 202 | ```
 203 | 
 204 | **Bom:**
 205 | ```javascript
 206 | function createMenu(config) {
 207 |   // ...
 208 | }
 209 | 
 210 | createMenu({
 211 |   title: 'Foo',
 212 |   body: 'Bar',
 213 |   buttonText: 'Baz',
 214 |   cancellable: true
 215 | });
 216 | 
 217 | ```
 218 | 
 219 | **Melhor:**
 220 | ```javascript
 221 | function createMenu(config) {
 222 |   // ...
 223 | }
 224 | 
 225 | const config = {
 226 |   title: 'Foo',
 227 |   body: 'Bar',
 228 |   buttonText: 'Baz',
 229 |   cancellable: true
 230 | }
 231 | 
 232 | createMenu(config)
 233 | 
 234 | ```
 235 | **[⬆ voltar ao topo](#Índice)**
 236 | 
 237 | 
 238 | ### Funções devem fazer uma coisa
 239 | Essa é de longe a regra mais importante em engenharia de software. Quando funções fazem mais que uma coisa, elas se tornam difíceis de serem compostas, testadas e raciocinadas. Quando você pode isolar uma função para realizar apenas uma ação, elas podem ser refatoradas facilmente e seu código ficará muito mais limpo. Se você não levar mais nada desse guia além disso, você já estará na frente de muitos desenvolvedores.
 240 | 
 241 | **Ruim:**
 242 | ```javascript
 243 | function emailClients(clients) {
 244 |   clients.forEach((client) => {
 245 |     const clientRecord = database.lookup(client);
 246 |     if (clientRecord.isActive()) {
 247 |       email(client);
 248 |     }
 249 |   });
 250 | }
 251 | ```
 252 | 
 253 | **Bom:**
 254 | ```javascript
 255 | function emailClients(clients) {
 256 |   clients
 257 |     .filter(isClientActive)
 258 |     .forEach(email);
 259 | }
 260 | 
 261 | function isClientActive(client) {
 262 |   const clientRecord = database.lookup(client);
 263 |   return clientRecord.isActive();
 264 | }
 265 | ```
 266 | 
 267 | **Melhor:**
 268 | ```javascript
 269 | const emailClients = (clients) =>
 270 |   clients
 271 |     .filter(isClientActive)
 272 |     .map(getEmail);
 273 | 
 274 | 
 275 | const getEmail = (client) => client.email
 276 | 
 277 | const isClientActive = (client) => 
 278 |   database
 279 |     .lookup(client)
 280 |     .isActive()
 281 | 
 282 | ```
 283 | **[⬆ voltar ao topo](#Índice)**
 284 | 
 285 | ### Nomes de funções devem dizer o que elas fazem
 286 | 
 287 | **Ruim:**
 288 | ```javascript
 289 | function addToDate(date, month) {
 290 |   // ...
 291 | }
 292 | 
 293 | const date = new Date();
 294 | 
 295 | // É difícil dizer pelo nome da função o que é adicionado
 296 | addToDate(date, 1);
 297 | ```
 298 | 
 299 | **Bom:**
 300 | ```javascript
 301 | function addMonthToDate(month, date) {
 302 |   // ...
 303 | }
 304 | 
 305 | const date = new Date();
 306 | addMonthToDate(1, date);
 307 | ```
 308 | **[⬆ voltar ao topo](#Índice)**
 309 | 
 310 | ### Funções devem ter apenas um nível de abstração
 311 | Quando você tem mais de um nível de abstração sua função provavelmente esta fazendo coisas demais. Dividir suas funções leva a reutilização e teste mais fáceis.
 312 | 
 313 | **Ruim:**
 314 | ```javascript
 315 | function parseBetterJSAlternative(code) {
 316 |   const REGEXES = [
 317 |     // ...
 318 |   ];
 319 | 
 320 |   const statements = code.split(' ');
 321 |   const tokens = [];
 322 |   REGEXES.forEach((REGEX) => {
 323 |     statements.forEach((statement) => {
 324 |       // ...
 325 |     });
 326 |   });
 327 | 
 328 |   const ast = [];
 329 |   tokens.forEach((token) => {
 330 |     // lex...
 331 |   });
 332 | 
 333 |   ast.forEach((node) => {
 334 |     // parse...
 335 |   });
 336 | }
 337 | ```
 338 | 
 339 | **Bom:**
 340 | ```javascript
 341 | function tokenize(code) {
 342 |   const REGEXES = [
 343 |     // ...
 344 |   ];
 345 | 
 346 |   const statements = code.split(' ');
 347 |   const tokens = [];
 348 |   REGEXES.forEach((REGEX) => {
 349 |     statements.forEach((statement) => {
 350 |       tokens.push( /* ... */ );
 351 |     });
 352 |   });
 353 | 
 354 |   return tokens;
 355 | }
 356 | 
 357 | function lexer(tokens) {
 358 |   const ast = [];
 359 |   tokens.forEach((token) => {
 360 |     ast.push( /* ... */ );
 361 |   });
 362 | 
 363 |   return ast;
 364 | }
 365 | 
 366 | function parseBetterJSAlternative(code) {
 367 |   const tokens = tokenize(code);
 368 |   const ast = lexer(tokens);
 369 |   ast.forEach((node) => {
 370 |     // parse...
 371 |   });
 372 | }
 373 | ```
 374 | **[⬆ voltar ao topo](#Índice)**
 375 | 
 376 | ### Remova código duplicado
 377 | Faça absolutamente seu melhor para evitar código duplicado. Código duplicado quer dizer que existe mais de um lugar onde você deverá alterar algo se precisar mudar alguma lógica.
 378 | 
 379 | Imagine que você é dono de um restaurante e você toma conta do seu estoque: todos os seus tomates, cebolas, alhos, temperos, etc. Se você tem multiplas listas onde guarda estas informações, então você terá que atualizar todas elas quando servir um prato que tenha tomates. Se você tivesse apenas uma lista, teria apenas um lugar para atualizar!
 380 | 
 381 | Freqüentemente, você possui código duplicado porque você tem duas ou mais
 382 | coisas levemente diferentes, que possuem muito em comum, mas suas diferenças lhe forçam a ter mais duas ou três funções que fazem muito das mesmas coisas. Remover código duplicado significa criar uma abstração que seja capaz de lidar com este conjunto de coisas diferentes com apenas uma função/modulo/classe.
 383 | 
 384 | Conseguir a abstração correta é crítico, por isso que você deveria seguir os princípios SOLID descritos na seção *Classes*. Abstrações ruins podem ser piores do que código duplicado, então tome cuidado! Dito isto, se você puder fazer uma boa abstração, faça-a! Não repita a si mesmo, caso contrário você se pegará atualizando muitos lugares toda vez que precisar mudar qualquer coisinha.
 385 | 
 386 | **Ruim:**
 387 | ```javascript
 388 | function showDeveloperList(developers) {
 389 |   developers.forEach((developer) => {
 390 |     const expectedSalary = developer.calculateExpectedSalary();
 391 |     const experience = developer.getExperience();
 392 |     const githubLink = developer.getGithubLink();
 393 |     const data = {
 394 |       expectedSalary,
 395 |       experience,
 396 |       githubLink
 397 |     };
 398 | 
 399 |     render(data);
 400 |   });
 401 | }
 402 | 
 403 | function showManagerList(managers) {
 404 |   managers.forEach((manager) => {
 405 |     const expectedSalary = manager.calculateExpectedSalary();
 406 |     const experience = manager.getExperience();
 407 |     const portfolio = manager.getMBAProjects();
 408 |     const data = {
 409 |       expectedSalary,
 410 |       experience,
 411 |       portfolio
 412 |     };
 413 | 
 414 |     render(data);
 415 |   });
 416 | }
 417 | ```
 418 | 
 419 | **Bom:**
 420 | ```javascript
 421 | function showList(employees) {
 422 |   employees.forEach((employee) => {
 423 |     const expectedSalary = employee.calculateExpectedSalary();
 424 |     const experience = employee.getExperience();
 425 | 
 426 |     let portfolio = employee.getGithubLink();
 427 | 
 428 |     if (employee.type === 'manager') {
 429 |       portfolio = employee.getMBAProjects();
 430 |     }
 431 | 
 432 |     const data = {
 433 |       expectedSalary,
 434 |       experience,
 435 |       portfolio
 436 |     };
 437 | 
 438 |     render(data);
 439 |   });
 440 | }
 441 | ```
 442 | **[⬆ voltar ao topo](#Índice)**
 443 | 
 444 | ### Defina (set) objetos padrões com Object.assign
 445 | 
 446 | **Ruim:**
 447 | ```javascript
 448 | const menuConfig = {
 449 |   title: null,
 450 |   body: 'Bar',
 451 |   buttonText: null,
 452 |   cancellable: true
 453 | };
 454 | 
 455 | function createMenu(config) {
 456 |   config.title = config.title || 'Foo';
 457 |   config.body = config.body || 'Bar';
 458 |   config.buttonText = config.buttonText || 'Baz';
 459 |   config.cancellable = config.cancellable === undefined ? config.cancellable : true;
 460 | }
 461 | 
 462 | createMenu(menuConfig);
 463 | ```
 464 | 
 465 | **Bom:**
 466 | ```javascript
 467 | const menuConfig = {
 468 |   title: 'Order',
 469 |   // Usuário não incluiu a chave 'body'
 470 |   buttonText: 'Send',
 471 |   cancellable: true
 472 | };
 473 | 
 474 | function createMenu(config) {
 475 |   config = Object.assign({
 476 |     title: 'Foo',
 477 |     body: 'Bar',
 478 |     buttonText: 'Baz',
 479 |     cancellable: true
 480 |   }, config);
 481 | 
 482 |   // configuração agora é: {title: "Order", body: "Bar", buttonText: "Send", cancellable: true}
 483 |   // ...
 484 | }
 485 | 
 486 | createMenu(menuConfig);
 487 | ```
 488 | **[⬆ voltar ao topo](#Índice)**
 489 | 
 490 | 
 491 | ### Não use flags como parâmetros de funções
 492 | Flags falam para o seu usuário que sua função faz mais de uma coisa. Funções devem fazer apenas uma coisa. Divida suas funções se elas estao seguindo caminhos de código diferentes baseadas em um valor boleano.
 493 | 
 494 | **Ruim:**
 495 | ```javascript
 496 | function createFile(name, temp) {
 497 |   if (temp) {
 498 |     fs.create(`./temp/${name}`);
 499 |   } else {
 500 |     fs.create(name);
 501 |   }
 502 | }
 503 | ```
 504 | 
 505 | **Bom:**
 506 | ```javascript
 507 | function createFile(name) {
 508 |   fs.create(name);
 509 | }
 510 | 
 511 | function createTempFile(name) {
 512 |   createFile(`./temp/${name}`);
 513 | }
 514 | ```
 515 | **[⬆ voltar ao topo](#Índice)**
 516 | 
 517 | ### Evite Efeitos Colaterais (parte 1)
 518 | Uma função produz um efeito colateral se ela faz alguma coisa que não seja receber um valor de entrada e retornar outro(s) valor(es). Um efeito colateral pode ser escrever em um arquivo, modificar uma variável global, ou acidentalmente transferir todo seu dinheiro para um estranho.
 519 | 
 520 | Agora, você precisa de efeitos colaterais ocasionalmente no seu programa. Como no exemplo anterior, você pode precisar escrever em um arquivo. O que você quer fazer é centralizar aonde está fazendo isto. Não tenha diversas funções e classes que escrevam para uma arquivo em particular. Tenha um serviço que faça isso. Um e apenas um.
 521 | 
 522 | O ponto principal é evitar armadilhas como compartilhar o estado entre objetos sem nenhuma estrutura, usando tipos de dados mutáveis que podem ser escritos por qualquer coisa, e não centralizando onde seu efeito colateral acontece. Se você conseguir fazer isto, você sera muito mais feliz que a grande maioria dos outros programadores.
 523 | 
 524 | **Ruim:**
 525 | ```javascript
 526 | // Variável global referenciada pela função seguinte
 527 | // Se tivéssemos outra função que usa esse nome, então seria um vetor (array) e poderia quebrar seu código
 528 | let name = 'Ryan McDermott';
 529 | 
 530 | function splitIntoFirstAndLastName() {
 531 |   name = name.split(' ');
 532 | }
 533 | 
 534 | splitIntoFirstAndLastName();
 535 | 
 536 | console.log(name); // ['Ryan', 'McDermott'];
 537 | ```
 538 | 
 539 | **Bom:**
 540 | ```javascript
 541 | function splitIntoFirstAndLastName(name) {
 542 |   return name.split(' ');
 543 | }
 544 | 
 545 | const name = 'Ryan McDermott';
 546 | const newName = splitIntoFirstAndLastName(name);
 547 | 
 548 | console.log(name); // 'Ryan McDermott';
 549 | console.log(newName); // ['Ryan', 'McDermott'];
 550 | ```
 551 | **[⬆ voltar ao topo](#Índice)**
 552 | 
 553 | ### Evite Efeitos Colaterais (parte 2)
 554 | Em JavaScript, tipos primitivos são passados por valor e objetos/vetores são passados por referência. No caso de objetos e vetores, se nossa função faz uma mudança em um vetor de um carrinho de compras, por exemplo, adicionando um item para ser comprado, então qualquer outra função que use o vetor `cart` também será afetada por essa adição. Isso pode ser ótimo, mas também pode ser ruim. Vamos imaginar uma situação ruim:
 555 | 
 556 | O usuário clica no botão "Comprar", botão que invoca a função `purchase` que dispara uma série de requisições e manda o vetor `cart` para o servidor. Devido a uma conexão ruim de internet, a função `purchase` precisa fazer novamente a requisição. Agora, imagine que nesse meio tempo o usuário acidentalmente clique no botão `Adicionar ao carrinho` em um produto que ele não queria antes da requisição começar. Se isto acontecer e a requisição for enviada novamente, então a função `purchase` irá enviar acidentalmente o vetor com o novo produto adicionado porque existe uma referência para o vetor `cart` que a função `addItemToCart` modificou adicionando um produto indesejado.
 557 | 
 558 | Uma ótima solução seria que a função `addCartToItem` sempre clonasse o vetor `cart`, edita-se-o, e então retornasse seu clone. Isso garante que nenhuma outra função que possua uma referência para o carrinho de compras seja afetada por qualquer mudança feita.
 559 | 
 560 | Podem haver casos onde você realmente quer mudar o objeto de entrada, mas quando você adota este tipo de programação você vai descobrir que estes casos são bastante raros. A maioria das coisas podem ser refatoradas para não ter efeitos colaterais.
 561 | 
 562 | Duas ressalvas desta abordagem:
 563 | 
 564 |   1. Podem haver casos onde você realmente quer mudar o objeto de entrada, mas quando você adota este tipo de programação você vai descobrir que estes casos são bastante raros. A maioria das coisas podem ser refatoradas para não terem efeitos colaterais.
 565 | 
 566 |   2. Clonar objetos grandes pode ser bastante caro em termos de performance. Com sorte, na prática isso não é um problema, porque existem [ótimas bibliotecas](https://facebook.github.io/immutable-js/) que permitem que este tipo de programação seja rápida e não seja tão intensa no uso de memória quanto seria se você clonasse manualmente objetos e vetores.
 567 | 
 568 | 
 569 | **Ruim:**
 570 | ```javascript
 571 | const addItemToCart = (cart, item) => {
 572 |   cart.push({ item, date: Date.now() });
 573 | };
 574 | ```
 575 | 
 576 | **Bom:**
 577 | ```javascript
 578 | const addItemToCart = (cart, item) => {
 579 |   return [...cart, { item, date : Date.now() }];
 580 | };
 581 | ```
 582 | 
 583 | ### Não escreva em funções globais
 584 | Poluir globais é uma pratica ruim em JavaScript porque você pode causar conflito com outra biblioteca e o usuário da sua API não faria a menor ideia até que ele tivesse um exceção sendo levantada em produção. Vamos pensar em um exemplo: e se você quisesse estender o método nativo Array do JavaScript para ter um método `diff` que poderia mostrar a diferença entre dois vetores? Você poderia escrever sua nova função em `Array.prototype`, mas poderia colidir com outra biblioteca que tentou fazer a mesma coisa. E se esta outra biblioteca estava apenas usando `diff` para achar a diferença entre o primeiro e último elemento de um vetor? É por isso que seria muito melhor usar as classes padrões do ES2015/ES6 e apenas estender o `Array` global.
 585 | 
 586 | **Ruim:**
 587 | ```javascript
 588 | Array.prototype.diff = function diff(comparisonArray) {
 589 |   const hash = new Set(comparisonArray);
 590 |   return this.filter(elem => !hash.has(elem));
 591 | };
 592 | ```
 593 | 
 594 | **Bom:**
 595 | ```javascript
 596 | class SuperArray extends Array {
 597 |   diff(comparisonArray) {
 598 |     const hash = new Set(comparisonArray);
 599 |     return this.filter(elem => !hash.has(elem));
 600 |   }
 601 | }
 602 | ```
 603 | **[⬆ voltar ao topo](#Índice)**
 604 | 
 605 | ### Favoreça programação funcional sobre programação imperativa
 606 | JavaScript não é uma linguagem funcional da mesma forma que Haskell é, mas tem um toque de funcional em si. Linguagens funcionais são mais limpas e fáceis de se testar. Favoreça esse tipo de programação quando puder.
 607 | 
 608 | **Ruim:**
 609 | ```javascript
 610 | const programmerOutput = [
 611 |   {
 612 |     name: 'Uncle Bobby',
 613 |     linesOfCode: 500
 614 |   }, {
 615 |     name: 'Suzie Q',
 616 |     linesOfCode: 1500
 617 |   }, {
 618 |     name: 'Jimmy Gosling',
 619 |     linesOfCode: 150
 620 |   }, {
 621 |     name: 'Gracie Hopper',
 622 |     linesOfCode: 1000
 623 |   }
 624 | ];
 625 | 
 626 | let totalOutput = 0;
 627 | 
 628 | for (let i = 0; i < programmerOutput.length; i++) {
 629 |   totalOutput += programmerOutput[i].linesOfCode;
 630 | }
 631 | ```
 632 | 
 633 | **Bom:**
 634 | ```javascript
 635 | const programmerOutput = [
 636 |   {
 637 |     name: 'Uncle Bobby',
 638 |     linesOfCode: 500
 639 |   }, {
 640 |     name: 'Suzie Q',
 641 |     linesOfCode: 1500
 642 |   }, {
 643 |     name: 'Jimmy Gosling',
 644 |     linesOfCode: 150
 645 |   }, {
 646 |     name: 'Gracie Hopper',
 647 |     linesOfCode: 1000
 648 |   }
 649 | ];
 650 | 
 651 | const totalOutput = programmerOutput
 652 |   .map((programmer) => programmer.linesOfCode)
 653 |   .reduce((acc, linesOfCode) => acc + linesOfCode, 0);
 654 | ```
 655 | **[⬆ volta ao topo](#table-of-contents)**
 656 | 
 657 | ### Encapsule condicionais
 658 | 
 659 | **Ruim:**
 660 | ```javascript
 661 | if (fsm.state === 'fetching' && isEmpty(listNode)) {
 662 |   // ...
 663 | }
 664 | ```
 665 | 
 666 | **Bom:**
 667 | ```javascript
 668 | function shouldShowSpinner(fsm, listNode) {
 669 |   return fsm.state === 'fetching' && isEmpty(listNode);
 670 | }
 671 | 
 672 | if (shouldShowSpinner(fsmInstance, listNodeInstance)) {
 673 |   // ...
 674 | }
 675 | ```
 676 | **[⬆ voltar ao topo](#Índice)**
 677 | 
 678 | ### Evite negações de condicionais
 679 | 
 680 | **Ruim:**
 681 | ```javascript
 682 | function isDOMNodeNotPresent(node) {
 683 |   // ...
 684 | }
 685 | 
 686 | if (!isDOMNodeNotPresent(node)) {
 687 |   // ...
 688 | }
 689 | ```
 690 | 
 691 | **Bom:**
 692 | ```javascript
 693 | function isDOMNodePresent(node) {
 694 |   // ...
 695 | }
 696 | 
 697 | if (isDOMNodePresent(node)) {
 698 |   // ...
 699 | }
 700 | ```
 701 | **[⬆ voltar ao topo](#Índice)**
 702 | 
 703 | ### Evite condicionais
 704 | Esta parece ser uma tarefa impossível. Da primeira vez que as pessoas escutam isso, a maioria diz, “como eu supostamente faria alguma coisa sem usar `if`? ” A resposta é que você pode usar polimorfismo para realizar a mesma tarefa em diversos casos. A segunda questão é geralmente, “bom, isso é ótimo, mas porque eu deveria fazer isso?” A resposta é um conceito de código limpo aprendido previamente: uma função deve fazer apenas uma coisa. Quando você tem classes e funções que tem declarações `if`, você esta dizendo para seu usuário que sua função faz mais de uma coisa. Relembre-se, apenas uma coisa.
 705 | 
 706 | **Ruim:**
 707 | ```javascript
 708 | class Airplane {
 709 |   // ...
 710 |   getCruisingAltitude() {
 711 |     switch (this.type) {
 712 |       case '777':
 713 |         return this.getMaxAltitude() - this.getPassengerCount();
 714 |       case 'Air Force One':
 715 |         return this.getMaxAltitude();
 716 |       case 'Cessna':
 717 |         return this.getMaxAltitude() - this.getFuelExpenditure();
 718 |     }
 719 |   }
 720 | }
 721 | ```
 722 | 
 723 | **Bom:**
 724 | ```javascript
 725 | class Airplane {
 726 |   // ...
 727 | }
 728 | 
 729 | class Boeing777 extends Airplane {
 730 |   // ...
 731 |   getCruisingAltitude() {
 732 |     return this.getMaxAltitude() - this.getPassengerCount();
 733 |   }
 734 | }
 735 | 
 736 | class AirForceOne extends Airplane {
 737 |   // ...
 738 |   getCruisingAltitude() {
 739 |     return this.getMaxAltitude();
 740 |   }
 741 | }
 742 | 
 743 | class Cessna extends Airplane {
 744 |   // ...
 745 |   getCruisingAltitude() {
 746 |     return this.getMaxAltitude() - this.getFuelExpenditure();
 747 |   }
 748 | }
 749 | ```
 750 | **[⬆ voltar ao topo](#Índice)**
 751 | 
 752 | ### Evite checagem de tipos (parte 1)
 753 | JavaScript não possui tipos, o que significa que suas funções podem receber qualquer tipo de argumento. Algumas vezes esta liberdade pode te morder, e se torna tentador fazer checagem de tipos em suas funções. Existem muitas formas de evitar ter que fazer isso. A primeira coisa a se considerar são APIs consistentes.
 754 | 
 755 | **Ruim:**
 756 | ```javascript
 757 | function travelToTexas(vehicle) {
 758 |   if (vehicle instanceof Bicycle) {
 759 |     vehicle.peddle(this.currentLocation, new Location('texas'));
 760 |   } else if (vehicle instanceof Car) {
 761 |     vehicle.drive(this.currentLocation, new Location('texas'));
 762 |   }
 763 | }
 764 | ```
 765 | 
 766 | **Bom:**
 767 | ```javascript
 768 | function travelToTexas(vehicle) {
 769 |   vehicle.move(this.currentLocation, new Location('texas'));
 770 | }
 771 | ```
 772 | **[⬆ voltar ao topo](#Índice)**
 773 | 
 774 | ### Evite checagem de tipos (parte 2)
 775 | Se você estiver trabalhando com valores primitivos básicos como strings, inteiros e vetores, e você não pode usar polimorfismo mas ainda sente a necessidade de checar o tipo, você deveria considerar usar TypeScript. É uma excelente alternativa para o JavaScript normal, já que fornece uma tipagem estática sobre a sintaxe  padrão do JavaScript. O problema com checagem manual em JavaScript é que para se fazer bem feito requer tanta verborragia extra que a falsa “tipagem-segura” que você consegue não compensa pela perca de legibilidade. Mantenha seu JavaScript limpo, escreve bons testes, e tenha boas revisões de código. Ou, de outra forma, faça tudo isso mas com TypeScript (que, como eu falei, é uma ótima alternativa!).
 776 | 
 777 | **Ruim:**
 778 | ```javascript
 779 | function combine(val1, val2) {
 780 |   if (typeof val1 === 'number' && typeof val2 === 'number' ||
 781 |       typeof val1 === 'string' && typeof val2 === 'string') {
 782 |     return val1 + val2;
 783 |   }
 784 | 
 785 |   throw new Error('Must be of type String or Number');
 786 | }
 787 | ```
 788 | 
 789 | **Bom:**
 790 | ```javascript
 791 | function combine(val1, val2) {
 792 |   return val1 + val2;
 793 | }
 794 | ```
 795 | **[⬆ voltar ao topo](#Índice)**
 796 | 
 797 | ### Não otimize demais
 798 | Navegadores modernos fazem muitas otimizações por debaixo dos panos em tempo de execução. Muitas vezes, se você estiver otimizando esta apenas perdendo o seu tempo. [Existem bons recursos](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers) para se verificar onde falta otimização. Foque nesses por enquanto, até que  eles sejam concertados caso seja possível.
 799 | 
 800 | **Ruim:**
 801 | ```javascript
 802 | 
 803 | // Em navegadores antigos, cada iteração de `list.length` não cacheada seria custosa
 804 | // devido a recomputação de `list.length`. Em navegadores modernos, isto é otimizado.
 805 | for (let i = 0, len = list.length; i < len; i++) {
 806 |   // ...
 807 | }
 808 | ```
 809 | 
 810 | **Bom:**
 811 | ```javascript
 812 | for (let i = 0; i < list.length; i++) {
 813 |   // ...
 814 | }
 815 | ```
 816 | **[⬆ voltar ao topo](#Índice)**
 817 | 
 818 | ### Remova código morto
 819 | Código morto é tão ruim quanto código duplicado. Não existe nenhum motivo para deixá-lo em seu código. Se ele não estiver sendo chamado, livre-se dele. Ele ainda estará a salvo no seu histórico de versionamento se ainda precisar dele.
 820 | 
 821 | **Ruim:**
 822 | ```javascript
 823 | function oldRequestModule(url) {
 824 |   // ...
 825 | }
 826 | 
 827 | function newRequestModule(url) {
 828 |   // ...
 829 | }
 830 | 
 831 | const req = newRequestModule;
 832 | inventoryTracker('apples', req, 'www.inventory-awesome.io');
 833 | 
 834 | ```
 835 | 
 836 | **Bom:**
 837 | ```javascript
 838 | function newRequestModule(url) {
 839 |   // ...
 840 | }
 841 | 
 842 | const req = newRequestModule;
 843 | inventoryTracker('apples', req, 'www.inventory-awesome.io');
 844 | ```
 845 | **[⬆ voltar ao topo](#Índice)**
 846 | 
 847 | ## **Objetos e Estruturas de Dados**
 848 | ### Use getters e setters
 849 | JavaScript não possui interfaces ou tipos então é muito difícil forçar esse padrão, porque nós não temos palavras-chave como `public` e `private`. Usar getters e setters para acessar dados nos objetos é bem melhor que simplesmente procurar por uma propriedade em um objeto. "Por que?" você deve perguntar. Bem, aqui vai uma lista desorganizada de motivos:
 850 | 
 851 | * Quando você quer fazer mais além de pegar (get) a propriedade de um objeto, você não tem que procurar e mudar todos os acessores do eu código.
 852 | * Torna mais fácil fazer validação quando estiver dando um `set`.
 853 | * Encapsula a representação interna
 854 | * Mais fácil de adicionar logs e tratamento de erros quando dando get and set.
 855 | * Herdando esta classe, você pode sobrescrever as funcionalidades padrões.
 856 | * Você pode usar lazy loading nas propriedades de seu objeto, digamos por exemplo pegando ele de um servidor.
 857 | 
 858 | 
 859 | **Ruim:**
 860 | ```javascript
 861 | class BankAccount {
 862 |   constructor() {
 863 |     this.balance = 1000;
 864 |   }
 865 | }
 866 | 
 867 | const bankAccount = new BankAccount();
 868 | 
 869 | // Buy shoes...
 870 | bankAccount.balance -= 100;
 871 | ```
 872 | 
 873 | **Bom:**
 874 | ```javascript
 875 | class BankAccount {
 876 |   constructor(balance = 1000) {
 877 |     this._balance = balance;
 878 |   }
 879 | 
 880 |   // Não precisa ter como prefixo `get` ou `set` para ser um getter/setter
 881 |   set balance(amount) {
 882 |     if (verifyIfAmountCanBeSetted(amount)) {
 883 |       this._balance = amount;
 884 |     }
 885 |   }
 886 | 
 887 |   get balance() {
 888 |     return this._balance;
 889 |   }
 890 | 
 891 |   verifyIfAmountCanBeSetted(val) {
 892 |     // ...
 893 |   }
 894 | }
 895 | 
 896 | const bankAccount = new BankAccount();
 897 | 
 898 | // Comprar sapatos...
 899 | bankAccount.balance -= shoesPrice;
 900 | 
 901 | // Get o balanço
 902 | let balance = bankAccount.balance;
 903 | 
 904 | ```
 905 | **[⬆ voltar ao topo](#Índice)**
 906 | 
 907 | 
 908 | ### Faça objetos terem membros privados
 909 | Isto pode ser alcançado através de closures (para ES5 e além).
 910 | 
 911 | **Ruim:**
 912 | ```javascript
 913 | 
 914 | const Employee = function(name) {
 915 |   this.name = name;
 916 | };
 917 | 
 918 | Employee.prototype.getName = function getName() {
 919 |   return this.name;
 920 | };
 921 | 
 922 | const employee = new Employee('John Doe');
 923 | console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
 924 | delete employee.name;
 925 | console.log(`Employee name: ${employee.getName()}`); // Employee name: undefined
 926 | ```
 927 | 
 928 | **Bom:**
 929 | ```javascript
 930 | const Employee = function (name) {
 931 |   this.getName = function getName() {
 932 |     return name;
 933 |   };
 934 | };
 935 | 
 936 | const employee = new Employee('John Doe');
 937 | console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
 938 | delete employee.name;
 939 | console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
 940 | ```
 941 | **[⬆ voltar ao topo](#Índice)**
 942 | 
 943 | 
 944 | ## **Classes**
 945 | ### Principio da Responsabilidade Única (SRP)
 946 | Como dito em Código Limpo, "Nunca deveria haver mais de um motivo para uma classe ter que mudar". É tentador empacotar uma classe em excesso com muitas funcionalidades, como quando você pode levar apenas uma mala em seu voo. O problema com isso é que sua classe não sserá conceitualmente coesa e lhe dará diversos motivos para mudá-la. Minimizar o número de vezes que você precisa mudar uma classe é importante. É importante porque se muitas funcionalidades estão em uma classe e você mudar uma porção dela, pode ser difícil entender como isto afetará outras módulos que dependem dela no seu código.
 947 | 
 948 | **Ruim:**
 949 | ```javascript
 950 | class UserSettings {
 951 |   constructor(user) {
 952 |     this.user = user;
 953 |   }
 954 | 
 955 |   changeSettings(settings) {
 956 |     if (this.verifyCredentials()) {
 957 |       // ...
 958 |     }
 959 |   }
 960 | 
 961 |   verifyCredentials() {
 962 |     // ...
 963 |   }
 964 | }
 965 | ```
 966 | 
 967 | **Bom:**
 968 | ```javascript
 969 | class UserAuth {
 970 |   constructor(user) {
 971 |     this.user = user;
 972 |   }
 973 | 
 974 |   verifyCredentials() {
 975 |     // ...
 976 |   }
 977 | }
 978 | 
 979 | 
 980 | class UserSettings {
 981 |   constructor(user) {
 982 |     this.user = user;
 983 |     this.auth = new UserAuth(user);
 984 |   }
 985 | 
 986 |   changeSettings(settings) {
 987 |     if (this.auth.verifyCredentials()) {
 988 |       // ...
 989 |     }
 990 |   }
 991 | }
 992 | ```
 993 | **[⬆ voltar ao topo](#Índice)**
 994 | 
 995 | ### Princípio do Aberto/Fechado (OCP)
 996 | Como foi dito por Bertrand Meyer, "entidades de software (classes, módulos, funções, etc.) devem se manter abertas para extensões, mas fechadas para modificações." Mas o que isso significa? Esse principio basicamente diz que você deve permitir que usuários adicionem novas funcionalidades sem mudar códigó já existente.
 997 | 
 998 | **Ruim:**
 999 | ```javascript
1000 | class AjaxAdapter extends Adapter {
1001 |   constructor() {
1002 |     super();
1003 |     this.name = 'ajaxAdapter';
1004 |   }
1005 | }
1006 | 
1007 | class NodeAdapter extends Adapter {
1008 |   constructor() {
1009 |     super();
1010 |     this.name = 'nodeAdapter';
1011 |   }
1012 | }
1013 | 
1014 | class HttpRequester {
1015 |   constructor(adapter) {
1016 |     this.adapter = adapter;
1017 |   }
1018 | 
1019 |   fetch(url) {
1020 |     if (this.adapter.name === 'ajaxAdapter') {
1021 |       return makeAjaxCall(url).then((response) => {
1022 |         // transforma a resposta e retorna
1023 |       });
1024 |     } else if (this.adapter.name === 'httpNodeAdapter') {
1025 |       return makeHttpCall(url).then((response) => {
1026 |         // transforma a resposta e retorna
1027 |       });
1028 |     }
1029 |   }
1030 | }
1031 | 
1032 | function makeAjaxCall(url) {
1033 |   // faz a request e retorna a promessa
1034 | }
1035 | 
1036 | function makeHttpCall(url) {
1037 |   // faz a request e retorna a promessa
1038 | }
1039 | ```
1040 | 
1041 | **Bom:**
1042 | ```javascript
1043 | class AjaxAdapter extends Adapter {
1044 |   constructor() {
1045 |     super();
1046 |     this.name = 'ajaxAdapter';
1047 |   }
1048 | 
1049 |   request(url) {
1050 |     // faz a request e retorna a promessa
1051 |   }
1052 | }
1053 | 
1054 | class NodeAdapter extends Adapter {
1055 |   constructor() {
1056 |     super();
1057 |     this.name = 'nodeAdapter';
1058 |   }
1059 | 
1060 |   request(url) {
1061 |     // faz a request e retorna a promessa
1062 |   }
1063 | }
1064 | 
1065 | class HttpRequester {
1066 |   constructor(adapter) {
1067 |     this.adapter = adapter;
1068 |   }
1069 | 
1070 |   fetch(url) {
1071 |     return this.adapter.request(url).then((response) => {
1072 |       // transforma a resposta e retorna
1073 |     });
1074 |   }
1075 | }
1076 | ```
1077 | **[⬆ voltar ao topo](#Índice)**
1078 | 
1079 | 
1080 | ### Princípio de Substituição de Liskov (LSP)
1081 | Esse é um termo assustador para um conceito extremamente simples. É formalmente definido como “Se S é um subtipo de T, então objetos do tipo T podem ser substituídos por objetos com o tipo S (i.e., objetos do tipo S podem substituir objetos do tipo T) sem alterar nenhuma das propriedades desejáveis de um programa (corretude, performance em tarefas, etc.).” Esta é uma definição ainda mais assustadora.
1082 | 
1083 | A melhor explicação para este conceito é se você tiver uma classe pai e uma classe filha, então a classe base e a classe filha pode ser usadas indistintamente sem ter resultados incorretos. Isso ainda pode ser confuso, então vamos dar uma olhada no exemplo clássico do Quadrado-Retângulo (Square-Rectangle). Matematicamente, um quadrado é um retângulo, mas se você modelá-lo usando uma relação “isto-é” através de herança, você rapidamente terá problemas.
1084 | 
1085 | **Ruim:**
1086 | ```javascript
1087 | class Rectangle {
1088 |   constructor() {
1089 |     this.width = 0;
1090 |     this.height = 0;
1091 |   }
1092 | 
1093 |   setColor(color) {
1094 |     // ...
1095 |   }
1096 | 
1097 |   render(area) {
1098 |     // ...
1099 |   }
1100 | 
1101 |   setWidth(width) {
1102 |     this.width = width;
1103 |   }
1104 | 
1105 |   setHeight(height) {
1106 |     this.height = height;
1107 |   }
1108 | 
1109 |   getArea() {
1110 |     return this.width * this.height;
1111 |   }
1112 | }
1113 | 
1114 | class Square extends Rectangle {
1115 |   setWidth(width) {
1116 |     this.width = width;
1117 |     this.height = width;
1118 |   }
1119 | 
1120 |   setHeight(height) {
1121 |     this.width = height;
1122 |     this.height = height;
1123 |   }
1124 | }
1125 | 
1126 | function renderLargeRectangles(rectangles) {
1127 |   rectangles.forEach((rectangle) => {
1128 |     rectangle.setWidth(4);
1129 |     rectangle.setHeight(5);
1130 |     const area = rectangle.getArea(); // RUIM: Retornará 25 para o Quadrado. Deveria ser 20.
1131 |     rectangle.render(area);
1132 |   });
1133 | }
1134 | 
1135 | const rectangles = [new Rectangle(), new Rectangle(), new Square()];
1136 | renderLargeRectangles(rectangles);
1137 | ```
1138 | 
1139 | **Bom:**
1140 | ```javascript
1141 | class Shape {
1142 |   setColor(color) {
1143 |     // ...
1144 |   }
1145 | 
1146 |   render(area) {
1147 |     // ...
1148 |   }
1149 | }
1150 | 
1151 | class Rectangle extends Shape {
1152 |   constructor() {
1153 |     super();
1154 |     this.width = 0;
1155 |     this.height = 0;
1156 |   }
1157 | 
1158 |   setWidth(width) {
1159 |     this.width = width;
1160 |   }
1161 | 
1162 |   setHeight(height) {
1163 |     this.height = height;
1164 |   }
1165 | 
1166 |   getArea() {
1167 |     return this.width * this.height;
1168 |   }
1169 | }
1170 | 
1171 | class Square extends Shape {
1172 |   constructor() {
1173 |     super();
1174 |     this.length = 0;
1175 |   }
1176 | 
1177 |   setLength(length) {
1178 |     this.length = length;
1179 |   }
1180 | 
1181 |   getArea() {
1182 |     return this.length * this.length;
1183 |   }
1184 | }
1185 | 
1186 | function renderLargeShapes(shapes) {
1187 |   shapes.forEach((shape) => {
1188 |     switch (shape.constructor.name) {
1189 |       case 'Square':
1190 |         shape.setLength(5);
1191 |         break;
1192 |       case 'Rectangle':
1193 |         shape.setWidth(4);
1194 |         shape.setHeight(5);
1195 |     }
1196 | 
1197 |     const area = shape.getArea();
1198 |     shape.render(area);
1199 |   });
1200 | }
1201 | 
1202 | const shapes = [new Rectangle(), new Rectangle(), new Square()];
1203 | renderLargeShapes(shapes);
1204 | ```
1205 | **[⬆ voltar ao topo](#Índice)**
1206 | 
1207 | ### Princípio da Segregação de Interface (ISP)
1208 | JavaScript não possui interfaces então esse principio não se aplica estritamente como os outros. Entretanto, é importante e relevante até mesmo com a falta de um sistema de tipos em JavaScript.
1209 | 
1210 | ISP diz que "Clientes não deve ser forcados a depender de interfaces que eles não usam." Interfaces são contratos implícitos em JavaScript devido a sua tipagem pato (duck typing).
1211 | 
1212 | Um bom exemplo para se observar que demonstra esse principio em JavaScript é de classes que requerem objetos de configurações grandes. Não pedir para clientes definirem grandes quantidades de opções é benéfico, porque na maioria das vezes eles não precisarão de todas as configurações. Torná-las opcionais ajuda a prevenir uma “interferência gorda”.
1213 | 
1214 | **Ruim:**
1215 | ```javascript
1216 | class DOMTraverser {
1217 |   constructor(settings) {
1218 |     this.settings = settings;
1219 |     this.setup();
1220 |   }
1221 | 
1222 |   setup() {
1223 |     this.rootNode = this.settings.rootNode;
1224 |     this.animationModule.setup();
1225 |   }
1226 | 
1227 |   traverse() {
1228 |     // ...
1229 |   }
1230 | }
1231 | 
1232 | const $ = new DOMTraverser({
1233 |   rootNode: document.getElementsByTagName('body'),
1234 |   animationModule() {} //  Na maioria das vezes, não precisamos animar enquanto atravessamos (traversing).
1235 |   // ...
1236 | });
1237 | 
1238 | ```
1239 | 
1240 | **Bom:**
1241 | ```javascript
1242 | class DOMTraverser {
1243 |   constructor(settings) {
1244 |     this.settings = settings;
1245 |     this.options = settings.options;
1246 |     this.setup();
1247 |   }
1248 | 
1249 |   setup() {
1250 |     this.rootNode = this.settings.rootNode;
1251 |     this.setupOptions();
1252 |   }
1253 | 
1254 |   setupOptions() {
1255 |     if (this.options.animationModule) {
1256 |       // ...
1257 |     }
1258 |   }
1259 | 
1260 |   traverse() {
1261 |     // ...
1262 |   }
1263 | }
1264 | 
1265 | const $ = new DOMTraverser({
1266 |   rootNode: document.getElementsByTagName('body'),
1267 |   options: {
1268 |     animationModule() {}
1269 |   }
1270 | });
1271 | ```
1272 | **[⬆ voltar ao topo](#Índice)**
1273 | 
1274 | ### Princípio da Inversão de Dependência  (DIP)
1275 | Este principio nos diz duas coisas essenciais:
1276 | 1. Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
1277 | 2. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
1278 | 
1279 | Isso pode ser difícil de entender a principio, mas se você já trabalhou com Angular.js, você já viu uma implementação deste principio na forma de injeção de dependência (DI). Apesar de não serem conceitos idênticos, DIP não deixa módulos de alto nível saber os detalhes de seus módulos de baixo nível, assim como configurá-los. Isso pode ser alcançado através de DI. Um grande beneficio é que reduz o acoplamento entre os módulos. Acoplamento é um padrão de desenvolvimento muito ruim porque torna seu código mais difícil de ser refatorado.
1280 | 
1281 | Como dito anteriormente, JavaScript não possui interfaces, então as abstrações que são necessárias são contratos implícitos. Que quer dizer que, os métodos e as classes que um objeto/classe expõe para outros objeto/classe. No exemplo abaixo, o contrato implícito é que qualquer modulo de Request  para `InventoryTracker` terá um método `requestItems`:
1282 | 
1283 | **Ruim:**
1284 | ```javascript
1285 | class InventoryRequester {
1286 |   constructor() {
1287 |     this.REQ_METHODS = ['HTTP'];
1288 |   }
1289 | 
1290 |   requestItem(item) {
1291 |     // ...
1292 |   }
1293 | }
1294 | 
1295 | class InventoryTracker {
1296 |   constructor(items) {
1297 |     this.items = items;
1298 | 
1299 |     // Ruim: Nós criamos uma dependência numa implementação de request especifica.
1300 |     // Nós deveriamos apenas ter requestItems dependendo de um método de request: `request`
1301 |     this.requester = new InventoryRequester();
1302 |   }
1303 | 
1304 |   requestItems() {
1305 |     this.items.forEach((item) => {
1306 |       this.requester.requestItem(item);
1307 |     });
1308 |   }
1309 | }
1310 | 
1311 | const inventoryTracker = new InventoryTracker(['apples', 'bananas']);
1312 | inventoryTracker.requestItems();
1313 | ```
1314 | 
1315 | **Bom:**
1316 | ```javascript
1317 | class InventoryTracker {
1318 |   constructor(items, requester) {
1319 |     this.items = items;
1320 |     this.requester = requester;
1321 |   }
1322 | 
1323 |   requestItems() {
1324 |     this.items.forEach((item) => {
1325 |       this.requester.requestItem(item);
1326 |     });
1327 |   }
1328 | }
1329 | 
1330 | class InventoryRequesterV1 {
1331 |   constructor() {
1332 |     this.REQ_METHODS = ['HTTP'];
1333 |   }
1334 | 
1335 |   requestItem(item) {
1336 |     // ...
1337 |   }
1338 | }
1339 | 
1340 | class InventoryRequesterV2 {
1341 |   constructor() {
1342 |     this.REQ_METHODS = ['WS'];
1343 |   }
1344 | 
1345 |   requestItem(item) {
1346 |     // ...
1347 |   }
1348 | }
1349 | 
1350 | // Construindo nossas dependências externamente e injetando-as, podemos facilmente
1351 | // substituir nosso modulo de request por um novo mais chique que usa WebSockets
1352 | const inventoryTracker = new InventoryTracker(['apples', 'bananas'], new InventoryRequesterV2());
1353 | inventoryTracker.requestItems();
1354 | ```
1355 | **[⬆ voltar ao topo](#Índice)**
1356 | 
1357 | ### Prefira classes do ES2015/ES6 ao invés de funções simples do ES5
1358 | É muito difícil conseguir que herança de classe, construtores, e definições de métodos sejam legíveis para classes de ES5 clássicas. Se você precisa de herança (e esteja ciente que você talvez não precise), então prefira classes. Entretanto, prefira funções pequenas ao invés de classes até que você precise de objetos maiores e mais complexos.
1359 | 
1360 | **Ruim:**
1361 | ```javascript
1362 | const Animal = function(age) {
1363 |   if (!(this instanceof Animal)) {
1364 |     throw new Error('Instantiate Animal with `new`');
1365 |   }
1366 | 
1367 |   this.age = age;
1368 | };
1369 | 
1370 | Animal.prototype.move = function move() {};
1371 | 
1372 | const Mammal = function(age, furColor) {
1373 |   if (!(this instanceof Mammal)) {
1374 |     throw new Error('Instantiate Mammal with `new`');
1375 |   }
1376 | 
1377 |   Animal.call(this, age);
1378 |   this.furColor = furColor;
1379 | };
1380 | 
1381 | Mammal.prototype = Object.create(Animal.prototype);
1382 | Mammal.prototype.constructor = Mammal;
1383 | Mammal.prototype.liveBirth = function liveBirth() {};
1384 | 
1385 | const Human = function(age, furColor, languageSpoken) {
1386 |   if (!(this instanceof Human)) {
1387 |     throw new Error('Instantiate Human with `new`');
1388 |   }
1389 | 
1390 |   Mammal.call(this, age, furColor);
1391 |   this.languageSpoken = languageSpoken;
1392 | };
1393 | 
1394 | Human.prototype = Object.create(Mammal.prototype);
1395 | Human.prototype.constructor = Human;
1396 | Human.prototype.speak = function speak() {};
1397 | ```
1398 | 
1399 | **Bom:**
1400 | ```javascript
1401 | class Animal {
1402 |   constructor(age) {
1403 |     this.age = age;
1404 |   }
1405 | 
1406 |   move() { /* ... */ }
1407 | }
1408 | 
1409 | class Mammal extends Animal {
1410 |   constructor(age, furColor) {
1411 |     super(age);
1412 |     this.furColor = furColor;
1413 |   }
1414 | 
1415 |   liveBirth() { /* ... */ }
1416 | }
1417 | 
1418 | class Human extends Mammal {
1419 |   constructor(age, furColor, languageSpoken) {
1420 |     super(age, furColor);
1421 |     this.languageSpoken = languageSpoken;
1422 |   }
1423 | 
1424 |   speak() { /* ... */ }
1425 | }
1426 | ```
1427 | **[⬆ voltar ao topo](#Índice)**
1428 | 
1429 | 
1430 | ### Use encadeamento de métodos
1431 | Este padrão é muito útil em JavaScript e você o vera em muitas bibliotecas como jQuery e Lodash. Ele permite que seu código seja expressivo e menos verboso. Por esse motivo, eu digo, use encadeamento de métodos e dê uma olhada em como o seu código ficará mais limpo. Em suas funções de classes, apenas retorne `this` no final de cada função, e você poderá encadear mais métodos de classe nele.
1432 | 
1433 | **Ruim:**
1434 | ```javascript
1435 | class Car {
1436 |   constructor() {
1437 |     this.make = 'Honda';
1438 |     this.model = 'Accord';
1439 |     this.color = 'white';
1440 |   }
1441 | 
1442 |   setMake(make) {
1443 |     this.make = make;
1444 |   }
1445 | 
1446 |   setModel(model) {
1447 |     this.model = model;
1448 |   }
1449 | 
1450 |   setColor(color) {
1451 |     this.color = color;
1452 |   }
1453 | 
1454 |   save() {
1455 |     console.log(this.make, this.model, this.color);
1456 |   }
1457 | }
1458 | 
1459 | const car = new Car();
1460 | car.setColor('pink');
1461 | car.setMake('Ford');
1462 | car.setModel('F-150');
1463 | car.save();
1464 | ```
1465 | 
1466 | **Bom:**
1467 | ```javascript
1468 | class Car {
1469 |   constructor() {
1470 |     this.make = 'Honda';
1471 |     this.model = 'Accord';
1472 |     this.color = 'white';
1473 |   }
1474 | 
1475 |   setMake(make) {
1476 |     this.make = make;
1477 |     // NOTA: Retorne this para encadear
1478 |     return this;
1479 |   }
1480 | 
1481 |   setModel(model) {
1482 |     this.model = model;
1483 |     // NOTA: Retorne this para encadear
1484 |     return this;
1485 |   }
1486 | 
1487 |   setColor(color) {
1488 |     this.color = color;
1489 |     // NOTA: Retorne this para encadear
1490 |     return this;
1491 |   }
1492 | 
1493 |   save() {
1494 |     console.log(this.make, this.model, this.color);
1495 |     // NOTA: Retorne this para encadear
1496 |     return this;
1497 |   }
1498 | }
1499 | 
1500 | const car = new Car()
1501 |   .setColor('pink')
1502 |   .setMake('Ford')
1503 |   .setModel('F-150')
1504 |   .save();
1505 | ```
1506 | **[⬆ voltar ao topo](#Índice)**
1507 | 
1508 | ### Prefira composição ao invés de herança
1509 | Como dito famosamente em  [*Padrão de projeto*](https://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software) pela Guangue dos Quatro, você deve preferir composição sobre herança onde você puder. Existem muitas boas razoes para usar herança e muitas boas razoes para se usar composição. O ponto principal para essa máxima é que se sua mente for instintivamente para a herança, tente pensar se composição poderia modelar melhor o seu problema. Em alguns casos pode.
1510 | 
1511 | Você deve estar pensando então, "quando eu deveria usar herança?" Isso depende especificamente do seu problema, mas essa é uma lista decente de quando herança faz mais sentido que composição:
1512 | 
1513 | 1. Sua herança representa uma relação de "isto-é" e não uma relação de "isto-tem" (Human→Animal vs. User->UserDetails)
1514 | 2. Você pode reutilizar código de classes de base (Humanos podem se mover como todos os animais).
1515 | 3. Você quer fazer mudanças globais para classes derivadas mudando apenas a classe base. (Mudar o custo calórico para todos os animais quando se movem).
1516 | 
1517 | **Ruim:**
1518 | ```javascript
1519 | class Employee {
1520 |   constructor(name, email) {
1521 |     this.name = name;
1522 |     this.email = email;
1523 |   }
1524 | 
1525 |   // ...
1526 | }
1527 | 
1528 | // Ruim porque Employees (Empregados) "tem" dados de impostos. EmployeeTaxData não é um tipo de Employee
1529 | class EmployeeTaxData extends Employee {
1530 |   constructor(ssn, salary) {
1531 |     super();
1532 |     this.ssn = ssn;
1533 |     this.salary = salary;
1534 |   }
1535 | 
1536 |   // ...
1537 | }
1538 | ```
1539 | 
1540 | **Bom:**
1541 | ```javascript
1542 | class EmployeeTaxData {
1543 |   constructor(ssn, salary) {
1544 |     this.ssn = ssn;
1545 |     this.salary = salary;
1546 |   }
1547 | 
1548 |   // ...
1549 | }
1550 | 
1551 | class Employee {
1552 |   constructor(name, email) {
1553 |     this.name = name;
1554 |     this.email = email;
1555 |   }
1556 | 
1557 |   setTaxData(ssn, salary) {
1558 |     this.taxData = new EmployeeTaxData(ssn, salary);
1559 |   }
1560 |   // ...
1561 | }
1562 | ```
1563 | **[⬆ voltar ao topo](#Índice)**
1564 | 
1565 | ## **Testes**
1566 | Testes são mais importantes que entregas. Se você não possui testes ou um quantidade inadequada, então toda vez que você entregar seu código você não tera certeza se você não quebrou alguma coisa. Decidir o que constitui uma quantidade adequada é responsabilidade do seu time, mas ter 100% de cobertura (todas as sentenças e branches) é a maneira que se alcança uma alta confiança e uma paz de espirito em desenvolvimento. Isso quer dizer que além de ter um ótimo framework de testes, você também precisa usar uma [noa ferramenta de cobertura](http://gotwarlost.github.io/istanbul/).
1567 | 
1568 | Não existe desculpa para não escrever testes. Existem [diversos frameworks de testes em JS ótimos](http://jstherightway.org/#testing-tools), então encontre um que seu time prefira. Quando você encontrar um que funciona para seu time, então tenha como objetivo sempre escrever testes para cada nova funcionalidade/módulo que você introduzir. Se seu método preferido for Desenvolvimento Orientado a Testes (TDD), isso é ótimo, mas o ponto principal é apenas ter certeza que você está alcançado suas metas de cobertura antes de lançar qualquer funcionalidade, ou refatorar uma já existente.
1569 | 
1570 | ### Um conceito por teste
1571 | 
1572 | **Ruim:**
1573 | ```javascript
1574 | const assert = require('assert');
1575 | 
1576 | describe('MakeMomentJSGreatAgain', () => {
1577 |   it('handles date boundaries', () => {
1578 |     let date;
1579 | 
1580 |     date = new MakeMomentJSGreatAgain('1/1/2015');
1581 |     date.addDays(30);
1582 |     date.shouldEqual('1/31/2015');
1583 | 
1584 |     date = new MakeMomentJSGreatAgain('2/1/2016');
1585 |     date.addDays(28);
1586 |     assert.equal('02/29/2016', date);
1587 | 
1588 |     date = new MakeMomentJSGreatAgain('2/1/2015');
1589 |     date.addDays(28);
1590 |     assert.equal('03/01/2015', date);
1591 |   });
1592 | });
1593 | ```
1594 | 
1595 | **Bom:**
1596 | ```javascript
1597 | const assert = require('assert');
1598 | 
1599 | describe('MakeMomentJSGreatAgain', () => {
1600 |   it('handles 30-day months', () => {
1601 |     const date = new MakeMomentJSGreatAgain('1/1/2015');
1602 |     date.addDays(30);
1603 |     date.shouldEqual('1/31/2015');
1604 |   });
1605 | 
1606 |   it('handles leap year', () => {
1607 |     const date = new MakeMomentJSGreatAgain('2/1/2016');
1608 |     date.addDays(28);
1609 |     assert.equal('02/29/2016', date);
1610 |   });
1611 | 
1612 |   it('handles non-leap year', () => {
1613 |     const date = new MakeMomentJSGreatAgain('2/1/2015');
1614 |     date.addDays(28);
1615 |     assert.equal('03/01/2015', date);
1616 |   });
1617 | });
1618 | ```
1619 | **[⬆ voltar ao topo](#Índice)**
1620 | 
1621 | ## **Concorrência**
1622 | ### Use Promessas, não callbacks
1623 | Callbacks não são limpos, e eles causam uma quantidade excessiva de aninhamentos. A partir de ES2015/ES6, Promessas são um tipo nativo global. Use-as!
1624 | 
1625 | **Ruim:**
1626 | ```javascript
1627 | require('request').get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin', (requestErr, response) => {
1628 |   if (requestErr) {
1629 |     console.error(requestErr);
1630 |   } else {
1631 |     require('fs').writeFile('article.html', response.body, (writeErr) => {
1632 |       if (writeErr) {
1633 |         console.error(writeErr);
1634 |       } else {
1635 |         console.log('File written');
1636 |       }
1637 |     });
1638 |   }
1639 | });
1640 | 
1641 | ```
1642 | 
1643 | **Bom:**
1644 | ```javascript
1645 | require('request-promise').get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin')
1646 |   .then((response) => {
1647 |     return require('fs-promise').writeFile('article.html', response);
1648 |   })
1649 |   .then(() => {
1650 |     console.log('File written');
1651 |   })
1652 |   .catch((err) => {
1653 |     console.error(err);
1654 |   });
1655 | 
1656 | ```
1657 | **[⬆ voltar ao topo](#Índice)**
1658 | 
1659 | ### Async/Await são ainda mais limpas que Promessas
1660 | Promessas são uma alternativa bem mais limpa que callbacks, mas o ES2017/ES8 traz `async` e `await` que oferecem uma solução ainda mais limpa. Tudo o que você precisa é uma função que tem como prefixo a palavra-chave `async`, e então você pode escrever sua logica imperativamente sem usar `then` para encadear suas funções. Use isto se você puder tirar vantagem das funcionalidades do  ES2017/ES8 hoje!
1661 | 
1662 | **Ruim:**
1663 | ```javascript
1664 | require('request-promise').get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin')
1665 |   .then((response) => {
1666 |     return require('fs-promise').writeFile('article.html', response);
1667 |   })
1668 |   .then(() => {
1669 |     console.log('File written');
1670 |   })
1671 |   .catch((err) => {
1672 |     console.error(err);
1673 |   });
1674 | 
1675 | ```
1676 | 
1677 | **Bom:**
1678 | ```javascript
1679 | async function getCleanCodeArticle() {
1680 |   try {
1681 |     const response = await require('request-promise').get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin');
1682 |     await require('fs-promise').writeFile('article.html', response);
1683 |     console.log('File written');
1684 |   } catch(err) {
1685 |     console.error(err);
1686 |   }
1687 | }
1688 | ```
1689 | **[⬆ voltar ao topo](#Índice)**
1690 | 
1691 | 
1692 | ## **Tratamento de Erros**
1693 | `throw error` é uma coisa boa! Eles significam que o programa identificou
1694 | com sucesso quando algo no deu errado e está permitindo que você saiba parando
1695 | a execução da função no processo atual, fechando o processo (em Node), e
1696 | notificando você no console com a pilha processos.
1697 | 
1698 | ### Não ignore erros capturados
1699 | No fazer nada com um erro capturado no te dá a habilidade de resolve-lo ou
1700 | reagir ao erro informado. Exibir um log no console(`console.log`) não é muito
1701 | melhor porque muitas vezes ele pode ficar perdido entre um monte de outras
1702 | coisas impressas no console. Se você envolver qualquer pedaço de código em um
1703 | `try/catch` isso significa que você acredita que um erro pode ocorrer lá e então
1704 | você deveria ter um plano, ou criar caminho de código para quando isso ocorrer.
1705 | 
1706 | **Ruim:**
1707 | ```javascript
1708 | try {
1709 |   functionThatMightThrow();
1710 | } catch (error) {
1711 |   console.log(error);
1712 | }
1713 | ```
1714 | 
1715 | **Bom:**
1716 | ```javascript
1717 | try {
1718 |   functionThatMightThrow();
1719 | } catch (error) {
1720 |   // Uma opção (mais chamativa que console.log):
1721 |   console.error(error);
1722 |   // Outra opção:
1723 |   notifyUserOfError(error);
1724 |   // Outra opção:
1725 |   reportErrorToService(error);
1726 |   // OU as três!
1727 | }
1728 | ```
1729 | 
1730 | ### Não ignore promessas rejeitadas
1731 | Pela mesma razão que você não deveria ignorar erros
1732 | caputados de `try/catch`
1733 | 
1734 | **Ruim:**
1735 | ```javascript
1736 | getdata()
1737 | .then((data) => {
1738 |   functionThatMightThrow(data);
1739 | })
1740 | .catch((error) => {
1741 |   console.log(error);
1742 | });
1743 | ```
1744 | 
1745 | **Bom:**
1746 | ```javascript
1747 | getdata()
1748 | .then((data) => {
1749 |   functionThatMightThrow(data);
1750 | })
1751 | .catch((error) => {
1752 |   // Uma opção (mais chamativa que console.log):
1753 |   console.error(error);
1754 |   // Outra opção:
1755 |   notifyUserOfError(error);
1756 |   // Outra opção:
1757 |   reportErrorToService(error);
1758 |   // OU as três!
1759 | });
1760 | ```
1761 | 
1762 | **[⬆ voltar ao topo](#Índice)**
1763 | 
1764 | 
1765 | ## **Formatação**
1766 | Formatação é subjetiva. Como muitas regras aqui, não há nenhuma regra fixa e
1767 | rápida que você precisa seguir. O ponto principal é NÃO DISCUTA sobre formatação.
1768 | Existem [muitas ferramentas](http://standardjs.com/rules.html) para automatizar isso.
1769 | Utilize uma! É um desperdicio de tempo e dinheiro para engenheiros discutirem sobre
1770 | formatação.
1771 | 
1772 | Para coisas que não possam utilizar formatação automática (identação, tabs vs. espaços,
1773 | aspas simples vs. duplas, etc.) olhe aqui para alguma orientação.
1774 | 
1775 | ### Utilize capitalização consistente
1776 | JavaScript não é uma linguagem tipada, então a capitalização diz muito sobre
1777 | suas variáveis, funções, etc. Estas regras são subjetivas, então sua equipe 
1778 | pode escolher o que quiserem. O ponto é, não importa o que vocês todos escolham,
1779 | apenas seja consistente.
1780 | 
1781 | **Ruim:**
1782 | ```javascript
1783 | const DAYS_IN_WEEK = 7;
1784 | const daysInMonth = 30;
1785 | 
1786 | const songs = ['Back In Black', 'Stairway to Heaven', 'Hey Jude'];
1787 | const Artists = ['ACDC', 'Led Zeppelin', 'The Beatles'];
1788 | 
1789 | function eraseDatabase() {}
1790 | function restore_database() {}
1791 | 
1792 | class animal {}
1793 | class Alpaca {}
1794 | ```
1795 | 
1796 | **Bom:**
1797 | ```javascript
1798 | const DAYS_IN_WEEK = 7;
1799 | const DAYS_IN_MONTH = 30;
1800 | 
1801 | const songs = ['Back In Black', 'Stairway to Heaven', 'Hey Jude'];
1802 | const artists = ['ACDC', 'Led Zeppelin', 'The Beatles'];
1803 | 
1804 | function eraseDatabase() {}
1805 | function restoreDatabase() {}
1806 | 
1807 | class Animal {}
1808 | class Alpaca {}
1809 | ```
1810 | **[⬆ voltar ao topo](#Índice)**
1811 | 
1812 | 
1813 | ### Funções e chamadas de funções devem estar próximas
1814 | Se uma função chamar outra, mantenha estas funções verticalmente próximas no arquivo
1815 | fonte. Em um cenário ideal, manter a chamada logo assima da função. Nós tendemos a
1816 | ler códigos de cima para baixo, como um jornal. Por causa disso, faça o seu código
1817 | desta maneira.
1818 | 
1819 | **Ruim:**
1820 | ```javascript
1821 | class PerformanceReview {
1822 |   constructor(employee) {
1823 |     this.employee = employee;
1824 |   }
1825 | 
1826 |   lookupPeers() {
1827 |     return db.lookup(this.employee, 'peers');
1828 |   }
1829 | 
1830 |   lookupManager() {
1831 |     return db.lookup(this.employee, 'manager');
1832 |   }
1833 | 
1834 |   getPeerReviews() {
1835 |     const peers = this.lookupPeers();
1836 |     // ...
1837 |   }
1838 | 
1839 |   perfReview() {
1840 |     this.getPeerReviews();
1841 |     this.getManagerReview();
1842 |     this.getSelfReview();
1843 |   }
1844 | 
1845 |   getManagerReview() {
1846 |     const manager = this.lookupManager();
1847 |   }
1848 | 
1849 |   getSelfReview() {
1850 |     // ...
1851 |   }
1852 | }
1853 | 
1854 | const review = new PerformanceReview(user);
1855 | review.perfReview();
1856 | ```
1857 | 
1858 | **Bom:**
1859 | ```javascript
1860 | class PerformanceReview {
1861 |   constructor(employee) {
1862 |     this.employee = employee;
1863 |   }
1864 | 
1865 |   perfReview() {
1866 |     this.getPeerReviews();
1867 |     this.getManagerReview();
1868 |     this.getSelfReview();
1869 |   }
1870 | 
1871 |   getPeerReviews() {
1872 |     const peers = this.lookupPeers();
1873 |     // ...
1874 |   }
1875 | 
1876 |   lookupPeers() {
1877 |     return db.lookup(this.employee, 'peers');
1878 |   }
1879 | 
1880 |   getManagerReview() {
1881 |     const manager = this.lookupManager();
1882 |   }
1883 | 
1884 |   lookupManager() {
1885 |     return db.lookup(this.employee, 'manager');
1886 |   }
1887 | 
1888 |   getSelfReview() {
1889 |     // ...
1890 |   }
1891 | }
1892 | 
1893 | const review = new PerformanceReview(employee);
1894 | review.perfReview();
1895 | ```
1896 | 
1897 | **[⬆ voltar ao topo](#Índice)**
1898 | 
1899 | ## **Comentários**
1900 | ### Apenas comente coisas que tenham complexidade de lógica de negócio.
1901 | Comentários são uma apologia, não um requisito. Um bom código documenta-se, *a maior parte*, por si só.
1902 | 
1903 | **Ruim:**
1904 | ```javascript
1905 | function hashIt(data) {
1906 |   // A hash
1907 |   let hash = 0;
1908 | 
1909 |   // Tamanho da string
1910 |   const length = data.length;
1911 | 
1912 |   // Loop em cada caracter da informação
1913 |   for (let i = 0; i < length; i++) {
1914 |     // Pega o código do caracter.
1915 |     const char = data.charCodeAt(i);
1916 |     // Cria a hash
1917 |     hash = ((hash << 5) - hash) + char;
1918 |     // Converte para um integer 32-bit
1919 |     hash &= hash;
1920 |   }
1921 | }
1922 | ```
1923 | 
1924 | **Bom:**
1925 | ```javascript
1926 | 
1927 | function hashIt(data) {
1928 |   let hash = 0;
1929 |   const length = data.length;
1930 | 
1931 |   for (let i = 0; i < length; i++) {
1932 |     const char = data.charCodeAt(i);
1933 |     hash = ((hash << 5) - hash) + char;
1934 | 
1935 |     // Converte para um integer 32-bit
1936 |     hash &= hash;
1937 |   }
1938 | }
1939 | 
1940 | ```
1941 | **[⬆ voltar ao topo](#Índice)**
1942 | 
1943 | ### Não deixe código comentado na sua base de código
1944 | Controle de versão existe por uma razão. Deixar códigos velhos no seu histórico.
1945 | 
1946 | **Ruim:**
1947 | ```javascript
1948 | doStuff();
1949 | // doOtherStuff();
1950 | // doSomeMoreStuff();
1951 | // doSoMuchStuff();
1952 | ```
1953 | 
1954 | **Bom:**
1955 | ```javascript
1956 | doStuff();
1957 | ```
1958 | **[⬆ voltar ao topo](#Índice)**
1959 | 
1960 | ### Não comente registro de alterações
1961 | Lembre-se, utilize controle de versão! Não tem necessidade em deixar códigos
1962 | inutlizados, códigos comentados e especialmente registros de alterações.
1963 | Utilize `git log` para pegar o histórico!
1964 | 
1965 | **Ruim:**
1966 | ```javascript
1967 | /**
1968 |  * 2016-12-20: Removidas monads, não entendia elas (RM)
1969 |  * 2016-10-01: Melhoria utilizando monads especiais (JP)
1970 |  * 2016-02-03: Removido checagem de tipos (LI)
1971 |  * 2015-03-14: Adicionada checagem de tipos (JR)
1972 |  */
1973 | function combine(a, b) {
1974 |   return a + b;
1975 | }
1976 | ```
1977 | 
1978 | **Bom:**
1979 | ```javascript
1980 | function combine(a, b) {
1981 |   return a + b;
1982 | }
1983 | ```
1984 | **[⬆ voltar ao topo](#Índice)**
1985 | 
1986 | ### Evite marcadores de posição
1987 | Eles geralmente criam ruídos. Deixe que as funções e nomes de variáveis em conjunto
1988 | com a devida identação e formatação dar a estrutura visual para o seu código.
1989 | 
1990 | **Ruim:**
1991 | ```javascript
1992 | ////////////////////////////////////////////////////////////////////////////////
1993 | // Intanciação do Scope Model
1994 | ////////////////////////////////////////////////////////////////////////////////
1995 | $scope.model = {
1996 |   menu: 'foo',
1997 |   nav: 'bar'
1998 | };
1999 | 
2000 | ////////////////////////////////////////////////////////////////////////////////
2001 | // Configuração da Action
2002 | ////////////////////////////////////////////////////////////////////////////////
2003 | const actions = function() {
2004 |   // ...
2005 | };
2006 | ```
2007 | 
2008 | **Bom:**
2009 | ```javascript
2010 | $scope.model = {
2011 |   menu: 'foo',
2012 |   nav: 'bar'
2013 | };
2014 | 
2015 | const actions = function() {
2016 |   // ...
2017 | };
2018 | ```
2019 | **[⬆ voltar ao topo](#Índice)**


--------------------------------------------------------------------------------