Te esfuerzas por escribir un código ordenado, pero no sabes por dónde empezar ... Lees las guías de estilo, como
esta de Airbnb, intenta seguir las recomendaciones prácticas de los principales expertos ... ¿Tienes que eliminar el código no utilizado? ¿Tienes que buscar variables innecesarias? ¿Estás tratando de identificar malos patrones utilizados en tus programas? Por ejemplo, desea comprender, leer las complejidades del código de una determinada función, si devolverá algo o no. ¿Te suena familiar? El problema es que es muy difícil para un programador hacer mucho y aprender mucho.
¿Quizás eres un líder de equipo bajo cuyo liderazgo está trabajando un equipo de desarrolladores de diferentes niveles? ¿Hay nuevas personas en tu equipo? ¿Te molesta que el código que escriben no cumpla con tus estándares? ¿Pasan sus días en las pruebas del código de otras personas, cuando estas verificaciones se refieren principalmente al cumplimiento de las normas y no a la lógica del programa?
El autor de este material dice que se enfrentó a todo a lo que se dedican las preguntas que acabamos de formular. A lo que se enfrenta es agotador y agotador. Aquí quiere hablar sobre herramientas, cuya aplicación correcta nos permite resolver los problemas anteriores.
A saber, aquí hablaremos sobre herramientas como Prettier, ESLint, Husky, Lint-Staged, EditorConfig, y sobre la automatización del formateo y el linting de código. Este material se centra principalmente en el desarrollo de React, pero los principios discutidos aquí se pueden aplicar en cualquier proyecto web.
Aquí hay un repositorio donde, entre otras cosas, se compila lo que se discute aquí.
Más bonita
Prettier es una herramienta de formato de código que tiene como objetivo utilizar reglas codificadas para diseñar programas. Formatea el código automáticamente. Así es como se ve.
Más bonito formatea el código siguiendo las reglas▍ Fortalezas de Prettier
Estas son las características y características de Prettier que nos permiten hablar sobre la utilidad de esta herramienta:
- Poner en orden la base de código existente. Con Prettier, puede hacer esto literalmente con un solo comando. El procesamiento manual de grandes cantidades de código llevará mucho más tiempo. Imagine, por ejemplo, la mano de obra requerida para formatear manualmente 20,000 líneas de código.
- Prettier es fácil de implementar. Prettier utiliza el enfoque de estilo "promedio" y menos controvertido al formatear el código. Dado que el proyecto es de código abierto, muchos han contribuido a él, mejorando y suavizando esquinas afiladas.
- Prettier le permite centrarse en escribir código, no formatearlo. Muchos simplemente no se dan cuenta de cuánto tiempo y esfuerzo se dedica a formatear el código. Usar Prettier le permite no pensar en formatear, sino programar en su lugar. En mi caso, por ejemplo, la eficiencia del trabajo, gracias a Prettier, aumentó en un 10%.
- Más bonita ayuda a los principiantes. Si eres un programador principiante que trabaja en el mismo equipo con profesionales serios, y quieres lucir digno en su contexto, Prettier te ayudará con esto.
▍Configuración más bonita
Aquí se explica cómo usar Prettier en un nuevo proyecto. Cree la carpeta de la
app y vaya a ella, ejecute el siguiente comando en la línea de comando:
npm init -y
Gracias a este comando,
npm inicializa un nuevo proyecto en la carpeta de la
app creando el archivo
package.json .
Yo, en este material,
npm yarn , pero aquí puedes usar
npm . Prettier también se puede conectar a un proyecto existente.
Instale el paquete
prettier como una dependencia de desarrollo de nuestro proyecto:
yarn add
Gracias a este comando, se agregará una entrada de dependencia de
package.json a
package.json que se verá así:
{ "name": "react-boiler-plate", "version": "1.0.0", "description": "A react boiler plate", "main": "src/index.js", "author": "Adeel Imran", "license": "MIT", "scripts": { "prettier": "prettier --write src/**/*.js" }, "devDependencies": { "prettier": "^1.14.3" } }
Hablaremos sobre lo que significa la línea
"prettier": "prettier — write src/**/*.js" poco más tarde. Mientras tanto, cree la carpeta
src en la carpeta de la
app . En esta carpeta, cree el archivo
index.js , aunque puede
index.js el nombre que desee.
Agregaremos el siguiente código a este archivo (en esta forma desagradable):
let person = { name: "Yoda", designation: 'Jedi Master ' }; function trainJedi (jediWarrion) { if (jediWarrion.name === 'Yoda') { console.log('No need! already trained'); } console.log(`Training ${jediWarrion.name} complete`) } trainJedi(person) trainJedi({ name: 'Adeel', designation: 'padawan' });
Entonces, en este momento tenemos el
src/app/index.js , que contiene un código bastante mal diseñado.
¿Cómo arreglarlo? Hay tres enfoques para trabajar con código mal formateado:
- Formatee manualmente este código.
- Utiliza una herramienta automatizada.
- Déjelo como está y trabaje (le pido que no elija este enfoque).
Voy a elegir la segunda opción. Ahora en nuestro proyecto hay una dependencia correspondiente, y además, en la sección de
scripts del archivo
package.json hay un registro sobre Prettier. Está claro que usaremos esta herramienta para formatear el código. Para hacer esto, cree el archivo
prettier.config.js en la carpeta de la
app y agregue las reglas para Prettier allí:
module.exports = { printWidth: 100, singleQuote: true, trailingComma: 'all', bracketSpacing: true, jsxBracketSameLine: false, tabWidth: 2, semi: true, };
Analicemos estas reglas:
printWidth: 100 : la longitud de la línea no debe superar los 100 caracteres.singleQuote: true : todas las comillas dobles se convertirán en comillas simples. Consulte la Guía de estilo de Airbnb para más detalles. Realmente me gusta esta guía, la uso para mejorar la calidad de mi código.trailingComma: 'all' : proporciona una coma después de la última propiedad del objeto. Aquí hay un buen artículo sobre este tema.bracketSpacing: true : responsable de insertar espacios entre el cuerpo del objeto y las llaves en los literales del objeto. Si esta propiedad se establece en true , los objetos declarados con literales de objeto se verán así: { foo: bar } . Si lo configura en false , entonces estas construcciones se verán así: {foo: bar} .jsxBracketSameLine: false : gracias a esta regla, el símbolo > en elementos JSX de varias líneas se colocará en la última línea. Así es como se ve el código si esta regla se establece en true :
<button className="prettier-class" id="prettier-id" onClick={this.handleClick}> Click Here </button>
Esto es lo que sucede si se establece en
false :
<button className="prettier-class" id="prettier-id" onClick={this.handleClick} > Click Here </button>
tabWidth: 2 : establece el número de espacios por nivel de alineación.semi: true : si esta regla se establece en true , se agrega un punto y coma al final de las expresiones.
Encuentra todas las reglas más bonitas aquí.
Ahora que las reglas están configuradas, hablemos de este script:
"prettier": "prettier — write src/**/*.js"
Gracias a este diseño, Prettier se inicia y encuentra todos los archivos
.js en la carpeta
src . El indicador
--write le dice que guarde los archivos formateados a medida que se procesan y corrige los errores de formato que se encuentran en ellos.
Ejecute el script desde la línea de comando:
yarn prettier
Esto es lo que sucedió después de eso con el código mal formateado que se muestra arriba.
Resultado de formatear código con PrettierSobre esto asumiremos que con Prettier descubrimos. Hablemos de linters.
ESLint
El linting es un tipo de análisis de código estático que a menudo se usa para encontrar patrones de diseño problemáticos o código que no sigue ciertas pautas de estilo.
Hay linters diseñados para la mayoría de los lenguajes de programación, a veces los compiladores incluyen linting en el proceso de compilación de código. Esta definición de linting se toma de la
página de información de código abierto para JavaScript JavaScript ESLint de código abierto, del que hablaremos.
▍ ¿Por qué necesito un linter para JavaScript?
Dado que
JavaScript es un lenguaje de programación dinámico con escritura débil, el código escrito en él es propenso a errores cometidos por los desarrolladores. JavaScript es un lenguaje interpretado, por lo que la sintaxis y otros errores en el código generalmente se detectan solo después de que se ejecuta este código.
Linters, como
ESLint , permiten a los desarrolladores encontrar problemas en el código sin iniciarlo.
▍ ¿Por qué ESLint es una herramienta especial?
Una buena pregunta se ha puesto en el título de esta sección. El punto aquí es que ESLint admite complementos. Por lo tanto, las reglas de verificación de código no deberían ser un paquete monolítico. Todo lo que necesita se puede conectar según sea necesario. Cada regla de pelusa agregada al sistema es autónoma, se puede activar o desactivar, independientemente de las demás. A cada regla se le puede asignar un nivel de alerta de acuerdo con el deseo del desarrollador; esto puede ser una advertencia (advertencia) o un error (error).
Cuando usa ESLint, trabaja con un sistema totalmente personalizable que puede reflejar su comprensión de cómo debería ser el código correcto y capturar qué conjunto de reglas sigue.
Entre las guías de estilo JavaScript existentes, las siguientes son muy populares:
Yo, como ya se mencionó, utilizo la guía de estilo de Airbnb. Este documento me aconsejó mi gerente de la compañía donde comenzó mi carrera profesional, y considero que esta guía de estilo es mi activo más valioso.
Esta guía se mantiene activamente: eche un vistazo a su
repositorio en GitHub. Aquí usaré un conjunto de reglas basadas en él.
Ahora trabajemos en el archivo
package.json , agreguemos algunas dependencias:
{ "name": "react-boiler-plate", "version": "1.0.0", "description": "A react boiler plate", "main": "src/index.js", "author": "Adeel Imran", "license": "MIT", "scripts": { "lint": "eslint --debug src/", "lint:write": "eslint --debug src/ --fix", "prettier": "prettier --write src/**/*.js" }, "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.(js|jsx)": ["npm run lint:write", "git add"] }, "devDependencies": { "babel-eslint": "^8.2.3", "eslint": "^4.19.1", "eslint-config-airbnb": "^17.0.0", "eslint-config-jest-enzyme": "^6.0.2", "eslint-plugin-babel": "^5.1.0", "eslint-plugin-import": "^2.12.0", "eslint-plugin-jest": "^21.18.0", "eslint-plugin-jsx-a11y": "^6.0.3", "eslint-plugin-prettier": "^2.6.0", "eslint-plugin-react": "^7.9.1", "husky": "^1.1.2", "lint-staged": "^7.3.0", "prettier": "^1.14.3" } }
Antes de hablar sobre cómo trabajar con esta configuración, quiero detenerme en las dependencias del proyecto que se agregan a
package.json . Creo que antes de usar algunas dependencias, debe saber qué papel juegan.
Por lo tanto, discutiremos el papel de los paquetes presentados aquí:
babel-eslint : le permite usar linting para aplicar a todo lo que Babel le da. No necesita este complemento si no está utilizando Flow o funciones experimentales que ESLint aún no admite.eslint es la herramienta principal utilizada para codificar el código.eslint-config-airbnb : proporciona las reglas de Airbnb como una configuración que se puede modificar.eslint-plugin-babel es un complemento de ESLint que complementa el complemento babel-eslint . Rediseñó las reglas que, al usar babel-eslint , causan problemas al procesar características experimentales.eslint-plugin-import : este paquete admite la vinculación de nuevas construcciones de sintaxis de import/export y ayuda a evitar problemas asociados con la ortografía incorrecta de rutas de archivos y nombres de módulos importados.eslint-plugin-jsx-a11y : proporciona reglas sobre la disponibilidad de elementos JSX para personas con discapacidades. La accesibilidad web es muy importante.eslint-plugin-prettier : ayuda a ESLint y Prettier a trabajar juntos. Se ve así: cuando Prettier formatea el código, lo hace teniendo en cuenta las reglas de ESLint.eslint-plugin-react : contiene las reglas de ESLint diseñadas para React.
En este artículo, no estamos hablando de pruebas de código, pero en el
package.json anterior, hay dependencias diseñadas para pruebas unitarias utilizando
Jest / Enzyme . Ahora, si decide utilizar estas herramientas para realizar pruebas, una descripción de los paquetes relevantes.
eslint-config-jest-enzyme : este paquete está diseñado para aquellos casos en que utiliza jest-environment-enzyme , lo que lleva al hecho de que las variables React y Enzyme son globales. Gracias a ello, ESLint no emitirá advertencias sobre tales variables.eslint-plugin-jest — complemento de ESlint para Jest.
Hay un par de paquetes más en el archivo que discutiremos más adelante, discutiendo problemas de automatización. Esto es
husky y con
lint-staged .
Ahora que hemos discutido, en términos generales, nuestras herramientas, continuaremos trabajando.
Cree el archivo
.eslintrc.js en la carpeta de la
app :
module.exports = { env: { es6: true, browser: true, node: true, }, extends: ['airbnb', 'plugin:jest/recommended', 'jest-enzyme'], plugins: [ 'babel', 'import', 'jsx-a11y', 'react', 'prettier', ], parser: 'babel-eslint', parserOptions: { ecmaVersion: 6, sourceType: 'module', ecmaFeatures: { jsx: true } }, rules: { 'linebreak-style': 'off', // Windows. 'arrow-parens': 'off', // prettier 'object-curly-newline': 'off', // prettier 'no-mixed-operators': 'off', // prettier 'arrow-body-style': 'off', // - ? 'function-paren-newline': 'off', // prettier 'no-plusplus': 'off', 'space-before-function-paren': 0, // prettier 'max-len': ['error', 100, 2, { ignoreUrls: true, }], // airbnb 'no-console': 'error', // airbnb 'no-alert': 'error', // airbnb 'no-param-reassign': 'off', // - ? "radix": "off", // parseInt, parseFloat radix . . 'react/require-default-props': 'off', // airbnb 'react/forbid-prop-types': 'off', // airbnb 'react/jsx-filename-extension': ['error', { extensions: ['.js'] }], // airbnb .jsx 'prefer-destructuring': 'off', 'react/no-find-dom-node': 'off', // 'react/no-did-mount-set-state': 'off', 'react/no-unused-prop-types': 'off', // 'react/jsx-one-expression-per-line': 'off', "jsx-a11y/anchor-is-valid": ["error", { "components": ["Link"], "specialLink": ["to"] }], "jsx-a11y/label-has-for": [2, { "required": { "every": ["id"] } }], // htmlFor label 'prettier/prettier': ['error'], }, };
Ahora agregue el archivo
.eslintignore a la carpeta de la
app :
/.git /.vscode node_modules
Ahora hablemos sobre cómo está
.eslintrc.js archivo
.eslintrc.js y sobre el significado de las construcciones presentadas en él.
Este archivo tiene la siguiente estructura:
module.exports = { env:{}, extends: {}, plugin: {}, parser: {}, parserOptions: {}, rules: {}, };
Considere los bloques de este archivo representados por objetos con los nombres correspondientes:
env : le permite especificar una lista de entornos para los que planea verificar el código. En nuestro caso, hay es6 , browser y node establecidas en true . El parámetro es6 incluye características de ES6, con la excepción de los módulos (esta característica establece automáticamente, en el bloque parserOptions , el parámetro ecmaVersion en 6 ). El parámetro del browser variables globales del navegador como Windows . El parámetro del node agrega variables de entorno y ámbitos globales de Node.js, por ejemplo, global . Los detalles sobre los entornos se pueden encontrar aquí .extends : es una matriz de líneas con configuraciones, con cada configuración adicional se extiende la anterior. airbnb se usan las reglas de airbnb Airbnb, que se expanden a jest y luego se expanden a jest-enzyme .plugins : aquí están las reglas de conexión que queremos usar. Aplicamos las reglas babel , import , jsx-a11y , react , prettier , del que ya hablamos.parser : ESLint usa el parser Espree de forma predeterminada, pero como trabajamos con Babel, necesitamos usar Babel-ESLint .parserOptions : dado que cambiamos el analizador estándar a babel-eslint , también debemos establecer las propiedades en este bloque. La propiedad ecmaVersion establecida en 6 indica a ESLint que se comprobará el código ES6. Como estamos escribiendo código en los módulos EcmaScript , la propiedad sourceType establece en module . Y finalmente, dado que usamos React, lo que significa usar JSX, un objeto con la clave jsx establecida en true escribe en la propiedad ecmaFeatures .rules : me gusta más esta parte del archivo .eslintrc.js ya que le permite configurar las reglas de ESLint. Todas las reglas que hemos expandido o agregado usando complementos se pueden cambiar o redefinir, y esto se hace en el bloque de rules . El texto del archivo contiene comentarios sobre las reglas.
Ahora hablemos del archivo
.eslintignore . Este archivo acepta una lista de rutas que representan carpetas cuyo contenido no debe procesarse con ESLint.
Aquí se definen tres carpetas:
/.git : no necesito ESLint para verificar archivos relacionados con Git./.vscode : el proyecto tiene esta carpeta debido al hecho de que uso VS Code. Aquí el editor almacena información de configuración que se puede configurar para cada proyecto. Estos datos tampoco deben ser procesados por el linter.node-modules : los archivos de dependencia tampoco necesitan verificarse con un linter.
Ahora veamos un par de nuevos scripts que aparecieron en
package.json . Aquí están:
"lint": "eslint --debug src/" "lint:write": "eslint --debug src/ --fix"
Si ejecuta el primero de ellos, utilizando el comando
yarn lint o
npm run lint , esto hará que el linter vea todos los archivos en el directorio
src y muestre un informe detallado sobre los archivos en los que encontró errores. Con este informe, puede corregir estos errores.
Ejecutar script de pelusaSi ejecuta el segundo script (
yarn lint:write ), ESLint realizará la misma verificación que se realizó anteriormente. La única diferencia es que en este modo, el sistema intentará corregir los errores detectados, tratará de llevar el código de la forma más decente posible.
Extensión de ESLint para el código VS
Ya tenemos configurado Prettier y ESLint, pero para usar las capacidades de estas herramientas, tenemos que ejecutar scripts. Esto no es muy conveniente, así que intenta solucionarlo. Es decir, queremos asegurarnos de que el comando realice el formateo y la alineación del código para guardar el archivo en el editor. Además, queremos realizar el linting y el formateo del código antes de confirmar.
Nosotros, como ejemplo, utilizamos el editor VS Code. Necesitaremos
la extensión ESLint para VS Code. Para instalarlo, puede abrir el panel de extensión VS Code (
ctrl+shift+x ). Aquí, en el campo de búsqueda, ingrese
eslint . Aparece una lista de extensiones. Lo que nos interesa es aquel cuya información de desarrollador es Dirk Baeumer. Después de instalar esta extensión, reinicie el editor.
Ahora, en la carpeta raíz del proyecto (
app ), cree la carpeta
.vscode (preste atención al punto al comienzo del nombre; esto es importante). En esta carpeta, cree un archivo
settings.json con el siguiente contenido:
{ "editor.formatOnSave": false, "eslint.autoFixOnSave": true, }
Considera su contenido.
- La propiedad
editor.formatOnSave establecida en false indica que no necesitamos la configuración estándar para aplicar el formato de archivo, ya que esto puede causar un conflicto con ESLint y Prettier. - La propiedad
eslint.autoFixOnSave establece en true , porque es necesario que el complemento instalado eslint.autoFixOnSave active cada vez que se guarda un archivo. Dado que ESLint y Prettier trabajan juntos en un proyecto, guardar el archivo lleva a formatear y codificar.
Es importante tener en cuenta que ahora, cuando se ejecuta el script
lint:write , realizará tanto el linting como el formateo del código.
Imagina tus sentimientos si obtuvieras un código de proyecto de 20,000 líneas que necesitarías verificar y mejorar. Ahora imagine que tendría que hacer esto manualmente. Tal trabajo probablemente tomaría un mes. Y con la ayuda de las herramientas de automatización anteriores, todo esto se realiza en unos treinta segundos.
Ahora, después de configurar todo lo que necesita, cada vez que guarde el archivo con el código, el editor se encargará de verificar y formatear el texto del programa. Sin embargo, aquí estamos hablando del editor VS Code. Es posible que alguien en su equipo prefiera algún otro editor. No hay nada de malo en eso, pero para que sea conveniente para todos trabajar, tendremos que encontrar otra cosa para automatizar.
Husky
El paquete Husky te permite usar ganchos Git. Esto significa que tiene la oportunidad de realizar ciertas acciones antes de comprometerse o antes de enviar el código del repositorio.
Para aprovechar las características de Husky, primero instale este paquete:
yarn add
Después de eso, agregue lo siguiente a
package.json :
"husky": { "hooks": { "pre-commit": "YOUR_COMMAND_HERE", "pre-push": "YOUR_COMMAND_HERE" } },
Esto conducirá al hecho de que antes de ejecutar el comando
commit o
push , se llamará a un determinado script, que, por ejemplo, realiza pruebas de código o formateo.
Los detalles sobre Husky se pueden encontrar
aquí .
Con pelusa
El paquete
Lint-staged le permite verificar los archivos indexados utilizando el linter, lo que ayuda a evitar que se envíen errores al repositorio.
Linting tiene sentido antes de cometer código. Gracias a esto, puede asegurarse de que los errores no penetren en el repositorio y proporcionar un estilo unificado del código que llega allí. Sin embargo, la selección para verificar todo el proyecto puede ser una tarea demasiado larga y los resultados de dicha verificación pueden no tener sentido. En última instancia, el linting puede necesitar exponer archivos que planea comprometer.
Lint-staged le permite realizar un conjunto de tareas arbitrarias en archivos indexados filtrados por un patrón de búsqueda. Los detalles sobre esto se pueden encontrar
aquí .
Instale el paquete de pelusas:
yarn add
Luego, en el archivo
package.json , agregue lo siguiente:
"lint-staged": { "*.(js|jsx)": ["npm run lint:write", "git add"] },
Gracias a esta construcción, el comando
lint:write se ejecutará primero, verificando el contenido del archivo y corrigiendo errores, después de lo cual los archivos se agregarán al índice con el comando
git add . Ahora este comando está dirigido a archivos
.js y
.jsx , pero lo mismo se puede hacer con archivos de otros tipos.
Compartir con Husky y pelusa
Considere un diagrama de acción que le permita organizar el siguiente flujo de trabajo. Cada vez que confirma archivos con código, antes de realizar esta operación, el sistema ejecuta el script de
lint-staged , que, a su vez, ejecuta el script
lint:write , que realiza el linting y el formateo del código. Después de eso, los archivos se agregan al índice y luego se confirman. Me parece que es muy conveniente. De hecho, en el código presentado anteriormente del archivo
package.json , esto ya está implementado, simplemente no hablamos de esto antes.
Aquí está el contenido de nuestro
package.json nuevamente:
{ "name": "react-boiler-plate", "version": "1.0.0", "description": "A react boiler plate", "main": "src/index.js", "author": "Adeel Imran", "license": "MIT", "scripts": { "lint": "eslint --debug src/", "lint:write": "eslint --debug src/ --fix", "prettier": "prettier --write src/**/*.js" }, "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.(js|jsx)": ["npm run lint:write", "git add"] }, "devDependencies": { "babel-eslint": "^8.2.3", "eslint": "^4.19.1", "eslint-config-airbnb": "^17.0.0", "eslint-config-jest-enzyme": "^6.0.2", "eslint-plugin-babel": "^5.1.0", "eslint-plugin-import": "^2.12.0", "eslint-plugin-jest": "^21.18.0", "eslint-plugin-jsx-a11y": "^6.0.3", "eslint-plugin-prettier": "^2.6.0", "eslint-plugin-react": "^7.9.1", "husky": "^1.1.2", "lint-staged": "^7.3.0", "prettier": "^1.14.3" } }
Ahora que sabe sobre las etapas de Husky y Lint, puede evaluar su impacto al trabajar con Git. A saber, supongamos que se ejecutaron los siguientes comandos:
$ git add . $ git commit -m "some descriptive message here"
Está claro que antes de comprometerse, se comprobará que el código cumple con las reglas especificadas en
.eslintrc.js y, si es necesario, se
.eslintrc.js . Gracias a esto, los errores nunca entrarán en el repositorio de un proyecto en funcionamiento.
Ahora ya sabe cómo integrar Prettier, ESLint, Husky y Lint-staged en su proyecto.
Permítame recordarle que dijimos anteriormente que no todos los miembros de su equipo usan mi código VS favorito. Para que todos ellos funcionen convenientemente, debemos tratar con el archivo
.editorconfig .
.Editorconfig archivo
Diferentes miembros de su equipo pueden usar diferentes editores. Obligándolos a usar cualquier editor para cualquier cosa. Sin embargo, para que todos usen la misma configuración, por ejemplo, con sangría o saltos de línea, utilizamos el archivo.
editorconfig . .
, . , , WebStorm, AppCode, Atom, Eclipse, Emacs, BBEdit .
app .editorconfig :
# EditorConfig - : http://EditorConfig.org # EditorConfig root = true [*.md] trim_trailing_whitespace = false [*.js] trim_trailing_whitespace = true # Unix [*] indent_style = space indent_size = 2 end_of_line = lf charset = utf-8 insert_final_newline = true max_line_length = 100
, :
trim_trailing_whitespace = false — .md - . .js - false .indent_style = space — .indent_size = 2 — .end_of_line = lf — lf . , , . .insert_final_newline = true — .max_line_length = 100 — 100 .
Resumen
, , , . , , .
Estimados lectores! ? ?