corregido

Author: EzequielCaste

1-js/03-code-quality/02-coding-style/article.md

@@ -1,12 +1,12 @@
-# Estilo de codificacion
+# Estilo de codificación
 
-Nuestro codigo debe ser lo mas limpio y facil de leer como sea posible
+Nuestro código debe ser lo más limpio y fácil de leer como sea posible.
 
-Eso es actualmente el arte de programar -- tomar una tarea compleja y codificarla de una manera que sea correcta y legible por otros.
+Ese es en realidad el arte de la programación: tomar una tarea compleja y codificarla de manera correcta y legible para los humanos. Un buen estilo de código ayuda mucho en eso.
 
 ## Sintaxis
 
-Aqui hay un cheatsheet con algunas reglas sugeridas(ver abajo para mas detalles):
+Aqui hay un cheatsheet con algunas reglas sugeridas (ver abajo para más detalles):
 
 ![](code-style.svg)
 <!--
@@ -34,14 +34,16 @@ if (n < 0) {
 
 -->
 
-Ahora vamos a discutir las reglas y razones de ellos en detalle.
-```warn header="Irony Detected"
+Ahora discutamos en detalle las reglas y las razones para ellas.
+
+```warn header="No existen reglas \"usted debe\""
 Nada está escrito en piedra aqui. Estos son preferencias de estilos, no dogmas religiosos.
 ```
 
 ### Llaves
 
 En la mayoria de proyectos de Javascript las llaves estan escritas en estilo "Egipcio" con la llave de apertura en la misma linea como la correspondiente palabra clave -- no en una nueva linea. Debe haber tambien un espacio despues de la llave de apertura, como esto: 
+
 ```js
 if (condition) {
   // hacer esto
@@ -50,45 +52,71 @@ if (condition) {
 }
 ```
 
-En una construccion de una sola linea es un caso extremo importante. ¿Debemos usar llaves? Si si, entonces ¿donde? 
+Una construcción de una sola línea, como `if (condition) doSomething()`, es un caso límite importante. ¿Deberíamos usar llaves?
 
 Aqui estan las variantes anotadas para que puedas juzgar la legibilidad por ti mismo. 
-<!--
-```js no-beautify
-if (n < 0) {alert(`Power ${n} is not supported`);}
 
-if (n < 0) alert(`Power ${n} is not supported`);
+1. 😠 Los principiantes a veces hacen eso. ¡Malo! Las llaves no son necesarias:
+    ```js
+    if (n < 0) *!*{*/!*alert(`Power ${n} is not supported`);*!*}*/!*
+    ```
+2. 😠 Dividir en una línea separada sin llaves. Nunca haga eso, es fácil cometer un error al agregar nuevas líneas:
+    ```js
+    if (n < 0)
+      alert(`Power ${n} is not supported`);
+    ```
+3. 😏 Una línea sin llaves: aceptable, si es corta:
+    ```js
+    if (n < 0) alert(`Power ${n} is not supported`);
+    ```
+4. 😃 La mejor variante:
+    ```js
+    if (n < 0) {
+      alert(`Power ${n} is not supported`);
+    }
+    ```
 
-if (n < 0)
-  alert(`Power ${n} is not supported`);
+Para un código muy breve, se permite una línea, p. `if (cond) return null`. Pero un bloque de código (la última variante) suele ser más legible.
 
-if (n < 0) {
-  alert(`Power ${n} is not supported`);
-}
+### Tamaño de línea
+
+A nadie le gusta leer una larga línea horizontal de código. Es una buena práctica dividirlos.
+
+Por ejemplo:
+```js
+// acento grave ` permite dividir la cadena de caracteres en múltiples líneas
+let str = `
+  ECMA International's TC39 is a group of JavaScript developers,
+  implementers, academics, and more, collaborating with the community
+  to maintain and evolve the definition of JavaScript.
+`;
 ```
--->
-![](figure-bracket-style.png)
 
-En resumen:
-- Para codigo muy corto, una linea es aceptable. Por ejemplo: `if (cond) return null`
-- Pero en una linea separada por cada sentencia en llaves es usualmente mas facil de leer.
+Y para sentencias `if`:
 
-### Tamaño de linea
+```js
+if (
+  id === 123 &&
+  moonPhase === 'Waning Gibbous' &&
+  zodiacSign === 'Libra'
+) {
+  letTheSorceryBegin();
+}
+```
 
-Nadie le gusta leer una linea horizontal larga de codigo. Es una mejor practica dividirlas y limitar el tamaño de tus lineas.
+La longitud máxima de la línea debe acordarse a nivel de equipo. Suele tener 80 o 120 caracteres.
 
-El maximo tamaño de linea deberia ser acordado en el livel de equipo. Es usualmente 80 o 120 caracteres.
 ### Identaciones
 
 Hay dos tipo de identaciones:
 
 - **Identacion horizontal: 2 o 4 espacios.**
 
-    Una identacion horizontal es hecha usando 2 o 4 espacios o el simbolo "Tab". ¿Cual elegir? es una vieja guerra santa. Espacios son mas comunes en estos dias.
+    Se realiza una sangría horizontal utilizando 2 o 4 espacios o el símbolo de tabulación horizontal (key `key:Tabulador`). Cuál elegir es una vieja guerra santa. Los espacios son más comunes hoy en día.
 
-    Una ventaja de los espacios sobre las tabulaciones es que los espacios permiten mas configuraciones flexibles de identaciones en lugar del simbolo "Tab".
+    Una ventaja de los espacios sobre las tabulaciones es que los espacios permiten configuraciones de sangría más flexibles que el símbolo del tabulador.
 
-    Por instancia, nosotros podemos alinear los argumentos con la llave de apertura, como esto:
+    Por ejemplo, podemos alinear los argumentos con el paréntesis de apertura, así:
 
     ```js no-beautify
     show(parameters,
@@ -101,9 +129,9 @@ Hay dos tipo de identaciones:
     }
     ```
 
-- **Identacion vertical: lineas vacias para dividir codigo en bloques logicos.**
+- **Identación vertical: líneas vacias para dividir código en bloques lógicos.**
 
-    Aun una simple funcion puede a menudo ser dividida en bloques logicos. En el ejemplo abajo, la inicializacion de variables, el bucle principal y el retorno del resultado son divididos verticalmente:
+    Incluso una sola función a menudo se puede dividir en bloques lógicos. En el siguiente ejemplo, la inicialización de variables, el bucle principal y la devolución del resultado se dividen verticalmente:
 
     ```js
     function pow(x, n) {
@@ -117,19 +145,19 @@ Hay dos tipo de identaciones:
     }
     ```
 
-    Insertar una nueva linea extra donde ayude a hacer el codigo mas legible. No debe de haber mas de nueve lineas de codigo sin una identacion vertical.
+    Insertar una nueva línea extra donde ayude a hacer el código mas legible. No debe de haber más de nueve líneas de código sin una identación vertical.
 
 ### Punto y coma
 
-Un punto y coma debe estar presente despues de cada sentencia, aun si podria posiblemente ser omitido.
+Debe haber un punto y coma después de cada declaración, incluso si se puede omitir.
 
-Hay lenguajes donde un punto y coma es verdaderamente opcional y es raramente usado. En Javascript, hay casos donde un salto de linea no es interpretado como un punto y coma, dejando el codigo vulnerable a errores.
+Hay idiomas en los que un punto y coma es realmente opcional y rara vez se usa. Sin embargo, en JavaScript, hay casos en los que un salto de línea no se interpreta como un punto y coma, lo que deja el código vulnerable a errores. Vea más sobre eso en el capítulo <info:structure#semicolon>.
 
-A medida tu te conviertas en un programador mas maduro, podrias escoger un estilo no-semicolon como [StandardJS](https://standardjs.com/). Hasta entonces, es mejor usar puntos y comas para evitar posibles dificultades.
+Si eres un programador de JavaScript experimentado, puedes elegir un estilo de código sin punto y coma como [StandardJS](https://standardjs.com/). De lo contrario, es mejor usar punto y coma para evitar posibles escollos. La mayoría de los desarrolladores ponen punto y coma.
 
 ### Niveles anidados
 
-Intenta evitar anidar el codigo en demasiados niveles de profuncidad.
+Intenta evitar anidar el código en demasiados niveles de profundidad.
 
 Algunas veces es buena idea usar la directiva ["continue"](info:while-for#continue) en un bucle para evitar anidamiento extra.
 
@@ -138,7 +166,7 @@ Por ejemplo, en lugar de añadir un `if` anidado como este:
 ```js
 for (let i = 0; i < 10; i++) {
   if (cond) {
-    ... // <- un nivel mas de anidamiento
+    ... // <- un nivel más de anidamiento
   }
 }
 ```
@@ -152,11 +180,11 @@ for (let i = 0; i < 10; i++) {
 }
 ```
 
-Una similar cosa puede ser hecho con `if/else` y `return`.
+Algo similar se puede hacer con `if/else` y `return`.
 
-Por ejemplo, dos construcciones abajo son identicas.
+Por ejemplo, las dos construcciones siguientes son idénticas.
 
-Opcion 1:
+Opción 1:
 
 ```js
 function pow(x, n) {
@@ -174,7 +202,7 @@ function pow(x, n) {
 }
 ```
 
-Opcion 2:
+Opción 2:
 
 ```js
 function pow(x, n) {
@@ -193,16 +221,16 @@ function pow(x, n) {
 }
 ```
 
-El segundo es mas legible porque el "caso extremo" de `n < 0` se maneja desde el principio. Una vez el chequeo es terminado nosotros nos podemos mover a el codigo "main" el codigo fluye sin necesidad de anidamientos adicionales.
+El segundo es más legible porque el "caso especial" de `n < 0` se maneja desde el principio. Una vez que se realiza la verificación, podemos pasar al flujo de código "principal" sin la necesidad de anidamiento adicional.
 
-## Colocacion de funciones
+## Colocación de funciones
 
-Si estas escribiendo varias funciones "auxiliares" y el codigo que las usan, hay tres maneras de organizar funciones.
+Si está escribiendo varias funciones "auxiliares" y el código que las usa, hay tres formas de organizar las funciones.
 
-1. Funciones declaradas sobre el codigo que las usan:
+1. Declare las funciones *anteriores* al código que las usa:
 
     ```js
-    // *!*declaracion de funciones*/!*
+    // *!*declaración de funciones*/!*
     function createElement() {
       ...
     }
@@ -215,15 +243,15 @@ Si estas escribiendo varias funciones "auxiliares" y el codigo que las usan, hay
       ...
     }
 
-    // *!*el codigo que las usan*/!*
+    // *!*el código que las usan*/!*
     let elem = createElement();
     setHandler(elem);
     walkAround();
     ```
-2. Codigo primero, despues funciones
+2. Código primero, después funciones
 
     ```js
-    // *!*El codigo que usa a las funciones*/!*
+    // *!*El código que usa a las funciones*/!*
     let elem = createElement();
     setHandler(elem);
     walkAround();
@@ -241,19 +269,19 @@ Si estas escribiendo varias funciones "auxiliares" y el codigo que las usan, hay
       ...
     }
     ```
-3. Mixto: una funcion es declarada donde se usa por primera vez.
+3. Mixto: una función es declarada donde se usa por primera vez.
 
 La mayoria del tiempo, la segunda variante es preferida.
 
-Eso es por que cuando leemos codigo, nosotros primero queremos saber *Que hace*. Si el codigo va primero, entonces provee esa informacion. entonces, quizas nosotros no necesitaremos leer las funciones, especialmente si sus nombres son descriptivos de lo que realmente hacen.
+Eso es porque al leer el código, primero queremos saber *qué hace*. Si el código va primero, entonces queda claro desde el principio. Entonces, tal vez no necesitemos leer las funciones, especialmente si sus nombres son descriptivos de lo que realmente hacen.
 
-## Guias de estilo
+## Guías de estilo
 
-Una guia de estilo contine reglas generales acerca de "Como escribir codigo", por ejemplo. Que comillas usar, cuantos espacios de identacion, donde poner los saltos de linea, etc. Muchas cosas pequeñas.
+Una guía de estilo contiene reglas generales sobre "cómo escribir" el código, cúales comillas usar, cuántos espacios para endentar, la longitud máxima de la línea, etc. Muchas cosas menores.
 
-Cuando todos los mienbros de un equipo usan la misma guia de estilos, el codigo se ve uniforme, sin importar de cual mienbro del equipo lo escriba.
+Cuando todos los miembros de un equipo usan la misma guía de estilo, el código se ve uniforme, independientemente de qué miembro del equipo lo haya escrito.
 
-Por supuesto, un equipo puede siempre escribir su propia guia de estilos. Aunque la mayoria del tiempo, no es necesario. Hay varios otros existentes probados y verdaderas opciones para escoger, asi adoptando una de estas es usualmente tu mejor opcion.
+Por supuesto, un equipo siempre puede escribir su propia guía de estilo, pero generalmente no es necesario. Hay muchas guías existentes para elegir.
 
 Algunas opciones populares:
 
@@ -263,32 +291,32 @@ Algunas opciones populares:
 - [StandardJS](https://standardjs.com/)
 - (y mucho mas)
 
-Si tu eres un desarrollador novato, empieza con la cheatsheet al inicio de este capitulo. Una vez tu hayas dominado eso, puedes explorar otras guias de estilos para coger principios comunes y decidir cual te gusta mas.
+Si eres un desarrollador novato, puedes comenzar con la cheet sheet al comienzo de este capítulo. Luego, puedes buscar otras guías de estilo para recoger más ideas y decidir cuál te gusta más.
 
 ## Linters automatizados
 
-Linters son herramientas que pueden automaticamente verificar el estilo de tu codigo y hacer sugerencias y refactorizacion.
+Linters son herramientas que pueden verificar automáticamente el estilo de su código y hacer sugerencias de mejora.
 
-Lo grandioso de ellos es que la comprobacion de estilo tambien puede encontrar algunos bugs, como errores gramaticales en variables o nombres de funciones. Debido a estas caracteristicas, Instalar un linter es comendado aun si tu no quieres apegarte a un "estilo de codigo" en particular.
+Lo mejor de ellos es que la comprobación de estilo también puede encontrar algunos errores, como errores tipográficos en nombres de variables o funciones. Debido a esta característica, se recomienda usar un linter incluso si no desea apegarse a un "estilo de código" en particular.
 
-Estas son las herramientas de linting mas conocidas:
+Aquí hay algunas herramientas de linting conocidas:
 
 - [JSLint](http://www.jslint.com/) -- uno de los primeros linters.
 - [JSHint](http://www.jshint.com/) -- mas ajustes que JSLint.
 - [ESLint](http://eslint.org/) -- probablemente el mas reciente.
 
-Todos ellos pueden hacer el trabajo. El author usa [ESLint](http://eslint.org/).
+Todos ellos pueden hacer el trabajo. El autor usa [ESLint](http://eslint.org/).
 
-Muchos linters son integrados con varios editores populares: solo habilite el plugin en el editor y configure el estilo.
+La mayoría de las linters están integradas con muchos editores populares: solo habilite el complemento en el editor y configure el estilo.
 
-Por ejemplo, para ESLint tu puedes hacer lo siguiente:
+Por ejemplo, para ESLint debe hacer lo siguiente:
 
 1. Instala [Node.JS](https://nodejs.org/).
 2. Instala ESLint con el comando `npm install -g eslint` (npm es un instalador de paquetes de Javascript).
-3. Crea un archivo de configuracion llamado `.eslintrc` en la raiz de tu proyecto de javascript (en el folder que contiene todos tus archivos).
+3. Crea un archivo de configuracion llamado `.eslintrc` en la raiz de tu proyecto de javascript (en la carpeta que contiene todos tus archivos).
 4. Instala/Habilita el plugin para que tu editor se integre con ESLint. La mayoria de editores tienen uno.
 
-Aqui un ejemplo de un archivo `.eslintrc`:
+Aquí un ejemplo de un archivo `.eslintrc`:
 
 ```js
 {
@@ -305,16 +333,16 @@ Aqui un ejemplo de un archivo `.eslintrc`:
 }
 ```
 
-Aqui la directiva `"extends"` denota que la confifuracion es basada en el conjunto de ajustes "eslint:recommended". Despues de eso, especificamos el nuestro.
+Aquí la directiva `"extends"` denota que la configuración se basa en el conjunto de configuraciones "eslint: recomendado". Después de eso, especificamos el nuestro.
 
-Es tambien posible descargar el conjunto de reglas de la web y extenderlos en su lugar. Ver <http://eslint.org/docs/user-guide/getting-started> para mas detalles de su instalacion.
+También es posible descargar conjuntos de reglas de estilo de la web y extenderlos en su lugar. Consulte <http://eslint.org/docs/user-guide/getting-started> para obtener más detalles sobre la instalación.
 
-Tambien ciertos IDEs tiene linting incorporado, lo cual es conveniente pero no como un ESLint personalizable.
+También algunos IDE tienen linting incorporado, lo cual es conveniente pero no tan personalizable como ESLint.
 
 ## Resumen
 
-Todas las reglas de sintaxis descritas en este capitulo (y en las guias de estilos referenciados) tienen como objetivo incrementar la legibilidad de tu codigo, pero todos ellos son debatibles.
+Todas las reglas de sintaxis descritas en este capítulo (y en las guías de estilo mencionadas) tienen como objetivo aumentar la legibilidad de su código. Todos ellos son discutibles.
 
-Cuando nosotros pensamos acerca de escribir "mejor" codigo, las sugerencias que nosotros debemos preguntar son, "¿Que hace que el codigo sea mas legible y facil de entender?" y "¿Que puede ayudarnos a evitar errores?" Estos son las principales cosas a tener en cuenta cuando escogemos y debatimos estilos de codigo.
+Cuando pensamos en escribir un código "mejor", las preguntas que debemos hacernos son: "¿Qué hace que el código sea más legible y fácil de entender?" y "¿Qué puede ayudarnos a evitar errores?" Estas son las principales cosas a tener en cuenta al elegir y debatir estilos de código.
 
-Leer guias de estilos populares te permitiran mantenerte al dia con las ultimas ideas acerca de tendencias estilos de codigo y mejores practicas.
+La lectura de guías de estilo populares le permitirá mantenerse al día con las últimas ideas sobre las tendencias de estilo de código y las mejores prácticas.