Você se esforça para escrever um código legal, mas não sabe por onde começar ... Você lê os guias de estilo, como
este no Airbnb, tenta seguir as recomendações práticas dos principais especialistas ... Você precisa excluir o código não utilizado? Precisa procurar variáveis desnecessárias? Você está tentando identificar padrões ruins usados em seus programas? Por exemplo - você quer entender, lendo os meandros do código de uma determinada função, se ele retornará algo ou não. Parece familiar? O problema é que é muito difícil para um programador fazer muito e aprender muito.
Talvez você seja um líder de equipe sob cuja liderança uma equipe de desenvolvedores de diferentes níveis está trabalhando? Existem novas pessoas na sua equipe? Incomoda-lhe que o código que eles escrevem não atenda aos seus padrões? Seus dias passam nos testes do código de outras pessoas, quando essas verificações dizem respeito principalmente à conformidade com os padrões, e não à lógica do programa?
O autor deste material diz que se deparou com tudo o que as perguntas que acabamos de fazer são dedicadas. O que ele enfrenta é cansativo e desgastante. Aqui ele quer falar sobre ferramentas, cuja aplicação correta nos permite resolver os problemas acima.
Nomeadamente, aqui falaremos sobre ferramentas como Prettier, ESLint, Husky, Lint-Staged, EditorConfig e sobre automação de formatação e revestimento de código. Este material é focado principalmente no desenvolvimento do React, mas os princípios discutidos aqui podem ser aplicados em qualquer projeto da web.
Aqui está um repositório onde, entre outras coisas, o que é discutido aqui é compilado.
Mais bonito
Prettier é uma ferramenta de formatação de código que tem como objetivo usar regras codificadas para projetar programas. Ele formata o código automaticamente. Aqui está como fica.
Prettier formata o código seguindo as regras▍ Forças mais bonitas
Aqui estão os recursos do Prettier que podem falar sobre a utilidade dessa ferramenta:
- Arrumando a base de código existente. Usando o Prettier, você pode fazer isso literalmente com apenas um comando. O processamento manual de grandes quantidades de código levará muito mais tempo. Imagine, por exemplo, o trabalho necessário para formatar manualmente 20.000 linhas de código.
- Mais bonito é fácil de implementar. Prettier usa a abordagem "média" e menos controversa de estilo ao formatar o código. Como o projeto é de código aberto, muitos contribuíram para ele, melhorando-o e suavizando cantos afiados.
- O Prettier permite que você se concentre na escrita do código, não na formatação. Muitos simplesmente não percebem quanto tempo e esforço são gastos na formatação do código. O uso do Prettier permite que você não pense em formatação, mas em programação. No meu caso, por exemplo, a eficiência do trabalho, graças a Prettier, aumentou 10%.
- Mais bonito ajuda iniciantes. Se você é um programador iniciante que trabalha na mesma equipe com profissionais sérios e deseja parecer digno no contexto deles, o Prettier o ajudará com isso.
PrConfigurando o Prettier
Veja como usar o Prettier em um novo projeto. Crie a pasta do
app e, para ela, execute o seguinte comando na linha de comando:
npm init -y
Graças a este comando, o
npm inicializa um novo projeto na pasta do
app criando o arquivo
package.json .
Eu, neste material, usarei
yarn , mas aqui você pode usar
npm . O Prettier também pode ser conectado a um projeto existente.
Instale o pacote
prettier como uma dependência de desenvolvimento do nosso projeto:
yarn add
Graças a este comando, uma entrada de dependência de
package.json será adicionada ao
package.json seguinte aparência:
{ "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" } }
Falaremos sobre o que a linha
"prettier": "prettier — write src/**/*.js" significa
"prettier": "prettier — write src/**/*.js" pouco mais tarde. Enquanto isso, crie a pasta
src na pasta do
app . Nesta pasta, crie o arquivo
index.js , embora você possa nomeá-lo como quiser.
Adicionaremos o seguinte código a este arquivo (neste formato desagradável):
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' });
Portanto, no momento, temos o
src/app/index.js , que contém um código mal projetado.
Como consertar isso? Existem três abordagens para trabalhar com código mal formatado:
- Formate manualmente este código.
- Use uma ferramenta automatizada.
- Deixe como está e continue trabalhando (peço que você não escolha essa abordagem).
Eu vou escolher a segunda opção. Agora, em nosso projeto, existe uma dependência correspondente e, além disso, na seção de
scripts do arquivo
package.json há um registro sobre o Prettier. É claro que usaremos essa ferramenta para formatar o código. Para fazer isso, crie o arquivo
prettier.config.js na pasta do
app e adicione as regras para o Prettier:
module.exports = { printWidth: 100, singleQuote: true, trailingComma: 'all', bracketSpacing: true, jsxBracketSameLine: false, tabWidth: 2, semi: true, };
Vamos analisar estas regras:
printWidth: 100 - o comprimento da linha não deve exceder 100 caracteres.singleQuote: true - todas as aspas duplas serão convertidas em aspas simples. Consulte o Guia de Estilo do Airbnb para mais detalhes. Eu realmente gosto deste guia, eu o uso para melhorar a qualidade do meu código.trailingComma: 'all' - fornece uma vírgula após a última propriedade do objeto. Aqui está um bom artigo sobre este tópico.bracketSpacing: true - responsável por inserir espaços entre o corpo do objeto e chaves nos literais do objeto. Se essa propriedade estiver configurada como true , os objetos declarados usando literais de objetos terão a seguinte aparência: { foo: bar } . Se você configurá-lo como false , essas construções terão a seguinte aparência: {foo: bar} .jsxBracketSameLine: false - graças a essa regra, o símbolo > nos elementos JSX de várias linhas será colocado na última linha. Aqui está a aparência do código se esta regra estiver definida como true :
<button className="prettier-class" id="prettier-id" onClick={this.handleClick}> Click Here </button>
Aqui está o que acontece se estiver definido como
false :
<button className="prettier-class" id="prettier-id" onClick={this.handleClick} > Click Here </button>
tabWidth: 2 - define o número de espaços por nível de alinhamento.semi: true - se essa regra estiver configurada como true , um ponto-e-vírgula será adicionado no final das expressões.
Encontre todas as regras do Prettier aqui.
Agora que as regras estão configuradas, vamos falar sobre este script:
"prettier": "prettier — write src/**/*.js"
Graças a esse design, o Prettier inicia e localiza todos os arquivos
.js na pasta
src . O sinalizador
--write diz para ele salvar os arquivos formatados à medida que são processados e corrige os erros de formatação encontrados neles.
Execute o script na linha de comando:
yarn prettier
Foi o que aconteceu depois disso com o código mal formatado mostrado acima.
Resultado da formatação do código com o PrettierSobre isso, assumiremos que com Prettier descobrimos. Vamos falar sobre linters.
ESLint
Linting é um tipo de análise de código estático que é freqüentemente usada para encontrar padrões de design problemáticos ou código que não segue determinadas diretrizes de estilo.
Existem linters projetados para a maioria das linguagens de programação, às vezes os compiladores incluem linting no processo de compilação de código. Essa definição de linting é obtida da
página de informações de código aberto do JavaScript JavaScript ESLint de código aberto, sobre o qual falaremos em breve.
HyPor que preciso de um linter para JavaScript?
Como o
JavaScript é uma linguagem de programação dinâmica com digitação fraca, o código escrito é propenso a erros cometidos pelos desenvolvedores. O JavaScript é uma linguagem interpretada, portanto, sintaxe e outros erros no código geralmente são detectados somente após a execução desse código.
Linters, como
ESLint , permitem que os desenvolvedores encontrem problemas no código sem iniciá-lo.
HyPor que o ESLint é uma ferramenta especial?
Uma boa pergunta foi colocada no título desta seção. O ponto aqui é que o ESLint suporta plugins. Portanto, as regras de verificação de código não devem ser um pacote monolítico. Tudo o que você precisa pode ser conectado conforme necessário. Cada regra de cotão adicionada ao sistema é autônoma, pode ser ativada ou desativada, independentemente das demais. Cada regra pode receber um nível de alerta de acordo com o desejo do desenvolvedor - pode ser um aviso (aviso) ou erro (erro).
Ao usar o ESLint, você está trabalhando com um sistema totalmente personalizável que pode refletir sua compreensão de como deve ser o código correto e capturar qual conjunto de regras você segue.
Entre os guias de estilo JavaScript existentes, os seguintes são muito populares:
Como já mencionado, eu uso o guia de estilo do Airbnb. Fui orientado por este documento pelo meu gerente da empresa onde minha carreira profissional começou e considero este guia de estilo o meu bem mais valioso.
Este guia é mantido ativamente - dê uma olhada no seu
repositório no GitHub. Aqui vou usar um conjunto de regras baseadas nele.
Agora vamos trabalhar no arquivo
package.json , adicionar algumas dependências a ele:
{ "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 falar sobre como trabalhar com essa configuração, quero me debruçar sobre as dependências do projeto que são adicionadas ao
package.json . Acredito que antes de usar algumas dependências, você deve saber qual papel elas desempenham.
Portanto, discutiremos o papel dos pacotes apresentados aqui:
babel-eslint - permite que você use o linting para aplicar a tudo o que Babel fornece. Você não precisa deste plug-in se não estiver usando o Flow ou recursos experimentais que o ESLint ainda não suporta.eslint é a principal ferramenta usada para codificar o código.eslint-config-airbnb - fornece regras do Airbnb como uma configuração que pode ser modificada.eslint-plugin-babel é um plug-in ESLint que complementa o babel-eslint . Ele redesenhou as regras que, ao usar o babel-eslint , causam problemas ao processar recursos experimentais.eslint-plugin-import - este pacote suporta a vinculação de novas construções de sintaxe de import/export e ajuda a evitar problemas associados à ortografia incorreta dos caminhos dos arquivos e nomes dos módulos importados.eslint-plugin-jsx-a11y - fornece regras relacionadas à disponibilidade de elementos JSX para pessoas com deficiências. Acessibilidade na Web é muito importante.eslint-plugin-prettier - Ajuda o ESLint e o Prettier a trabalharem juntos. É assim: quando o Prettier formata o código, ele o leva em consideração as regras do ESLint.eslint-plugin-react react - contém regras ESLint criadas para o React.
Neste artigo, não estamos falando sobre teste de código, mas no
package.json acima, existem dependências projetadas para teste de unidade usando
Jest / Enzyme . Agora, se você decidir usar essas ferramentas para teste, faça uma descrição dos pacotes relevantes.
eslint-config-jest-enzyme - este pacote destina-se aos casos em que você usa jest-environment-enzyme , o que leva ao fato de que as variáveis React e Enzyme são globais. Graças a isso, o ESLint não emitirá avisos sobre essas variáveis.eslint-plugin-jest — plugin ESlint para Jest.
Existem mais alguns pacotes no arquivo que discutiremos mais adiante, discutindo questões de automação. Isso é
husky e
lint-staged .
Agora que discutimos nossas ferramentas em termos gerais, continuaremos trabalhando.
Crie o arquivo
.eslintrc.js na pasta do
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'], }, };
Agora adicione o arquivo
.eslintignore à pasta do
app :
/.git /.vscode node_modules
Agora vamos falar sobre como o arquivo
.eslintrc.js está
.eslintrc.js e sobre o significado das construções apresentadas nele.
Este arquivo tem a seguinte estrutura:
module.exports = { env:{}, extends: {}, plugin: {}, parser: {}, parserOptions: {}, rules: {}, };
Considere os blocos deste arquivo representados por objetos com os nomes correspondentes:
env - permite especificar uma lista de ambientes para os quais você planeja verificar o código. No nosso caso, existem es6 , browser e propriedades do node definidas como true . O parâmetro es6 inclui recursos do ES6, com exceção dos módulos (esse recurso define automaticamente, no bloco parserOptions , o parâmetro ecmaVersion para 6 ). O parâmetro browser variáveis globais do navegador, como Windows . O parâmetro node adiciona variáveis e escopos globais do ambiente Node.js., por exemplo, global . Detalhes sobre os ambientes podem ser encontrados aqui .extends - é uma matriz de linhas com configurações, com cada configuração adicional estende a anterior. As regras de airbnb Airbnb são usadas airbnb , que são expandidas para jest e depois expandidas para jest-enzyme .plugins - aqui estão as regras de cotação que queremos usar. Aplicamos as regras babel , import , jsx-a11y , jsx-a11y , jsx-a11y , sobre as quais já falamos.parser - o ESLint usa o parser Espree por padrão, mas como trabalhamos com Babel, precisamos usar o Babel-ESLint .parserOptions - desde que alteramos o analisador padrão para babel-eslint , também precisamos definir as propriedades nesse bloco. A propriedade ecmaVersion definida como 6 indica ao ESLint que o código ES6 será verificado. Como estamos escrevendo código nos módulos EcmaScript , a propriedade sourceType definida como module . E, finalmente, como usamos React, o que significa usar JSX, um objeto com a chave jsx definida como true gravado na propriedade ecmaFeatures .rules - Eu gosto mais desta parte do arquivo .eslintrc.js pois permite configurar as regras ESLint. Todas as regras que expandimos ou adicionamos usando plug-ins podem ser alteradas ou redefinidas, e isso é feito no bloco de rules . O texto do arquivo contém comentários sobre as regras.
Agora vamos falar sobre o arquivo
.eslintignore . Este arquivo aceita uma lista de caminhos que representam pastas cujo conteúdo não deve ser processado usando o ESLint.
Três pastas são definidas aqui:
/.git - não preciso do ESLint para verificar arquivos relacionados ao Git./.vscode - o projeto tem essa pasta devido ao fato de eu usar o VS Code. Aqui, o editor armazena informações de configuração que podem ser definidas para cada projeto. Esses dados também não devem ser processados pelo linter.node-modules - os arquivos de dependência também não precisam ser verificados com um linter.
Agora, vamos ver alguns scripts novos que apareceram no
package.json . Aqui estão elas:
"lint": "eslint --debug src/" "lint:write": "eslint --debug src/ --fix"
Se você executar o primeiro deles, usando o comando
yarn lint ou
npm run lint , isso fará com que o linter
npm run lint todos os arquivos no diretório
src e exiba um relatório detalhado dos arquivos nos quais encontrou erros. Usando este relatório, você pode corrigir esses erros.
Executando script lintSe você executar o segundo script (
yarn lint:write ), o ESLint executará a mesma verificação que foi executada anteriormente. A única diferença é que, nesse modo, o sistema tentará corrigir os erros detectados, tentará trazer o código da forma mais decente possível.
Extensão ESLint para código VS
Já temos o Prettier e o ESLint configurados, mas para usar os recursos dessas ferramentas, precisamos executar scripts. Isso não é muito conveniente, então tente corrigi-lo. Ou seja, queremos garantir que a formatação e a limpeza do código sejam executadas pelo comando para salvar o arquivo no editor. Além disso, queremos executar o linting e a formatação do código antes de confirmar.
Como exemplo, usamos o editor de código VS. Vamos precisar
da extensão ESLint para o VS Code. Para instalá-lo, você pode abrir o painel de extensão do Código VS (
ctrl+shift+x ). Aqui, no campo de pesquisa, digite
eslint . Uma lista de extensões é exibida. O que nos interessa é aquele cujas informações do desenvolvedor são Dirk Baeumer. Depois de instalar esta extensão, reinicie o editor.
Agora, na pasta raiz do projeto (
app ), crie a pasta
.vscode (preste atenção ao ponto no início do nome - isso é importante). Nesta pasta, crie um arquivo
settings.json com o seguinte conteúdo:
{ "editor.formatOnSave": false, "eslint.autoFixOnSave": true, }
Considere o seu conteúdo.
- A propriedade
editor.formatOnSave configurada como false indica que não precisamos da configuração padrão para aplicar à formatação do arquivo, pois isso pode causar um conflito com o ESLint e o Prettier. - A propriedade
eslint.autoFixOnSave configurada como true , porque é necessário que o plug-in instalado eslint.autoFixOnSave toda vez que um arquivo for salvo. Como o ESLint e o Prettier trabalham juntos em um projeto, salvar o arquivo leva à formatação e à codificação.
É importante observar que agora, quando o script
lint:write for executado, ele executará a formatação do código e do
lint:write .
Imagine seus sentimentos se obtivesse um código de projeto de 20.000 linhas que você precisaria verificar e melhorar. Agora imagine que você precisaria fazer isso manualmente. Esse trabalho provavelmente levaria um mês. E com a ajuda das ferramentas de automação acima, tudo isso é feito em cerca de trinta segundos.
Agora, depois de configurar tudo o que você precisa, toda vez que você salvar um arquivo com um código, o editor se encarregará de verificar e formatar o texto do programa. No entanto, aqui estamos falando sobre o editor de código VS. É possível que alguém da sua equipe prefira outro editor. Não há nada de errado nisso, mas, para tornar conveniente o trabalho de todos, teremos que descobrir outra coisa para automatizar.
Husky
O pacote Husky permite que você use os ganchos Git. Isso significa que você tem a oportunidade de executar determinadas ações antes de confirmar ou antes de enviar o código do repositório.
Para tirar proveito dos recursos do Husky, primeiro instale este pacote:
yarn add
Depois disso, adicione o seguinte ao
package.json :
"husky": { "hooks": { "pre-commit": "YOUR_COMMAND_HERE", "pre-push": "YOUR_COMMAND_HERE" } },
Isso levará ao fato de que antes de executar o comando
commit ou
push , um determinado script será chamado, que, por exemplo, executa teste ou formatação de código.
Detalhes sobre o Husky podem ser encontrados
aqui .
Encenado por fiapos
O pacote
preparado pelo Lint permite verificar os arquivos indexados usando o linter, o que ajuda a impedir que erros sejam enviados ao repositório.
O linting faz sentido antes de confirmar o código. Graças a isso, você pode garantir que os erros não penetrem no repositório e fornecer um estilo unificado do código que chega lá. No entanto, aprender a verificar todo o projeto pode ser uma tarefa muito longa e os resultados dessa verificação podem não ter sentido. Por fim, o linting pode precisar expor os arquivos que você planeja confirmar.
Preparado por fiapos permite executar um conjunto de tarefas arbitrárias em arquivos indexados filtrados por um padrão de pesquisa. Detalhes sobre isso podem ser encontrados
aqui .
Instale o pacote preparado pelo Lint:
yarn add
Em seguida, no arquivo
package.json , adicione o seguinte:
"lint-staged": { "*.(js|jsx)": ["npm run lint:write", "git add"] },
Graças a essa construção, o comando
lint:write será executado primeiro, verificando o conteúdo do arquivo e corrigindo erros, após o qual os arquivos serão adicionados ao índice com o comando
git add . Agora, este comando é direcionado aos arquivos
.js e
.jsx , mas o mesmo pode ser feito com arquivos de outros tipos.
Compartilhamento com husky e fiapos
Considere um diagrama de ação que permita organizar o próximo fluxo de trabalho. Cada vez que você confirma arquivos com código, antes de executar esta operação, o sistema executa o script
lint-staged pelo
lint-staged , que, por sua vez, executa o script
lint:write , que executa o linting e a formatação do código. Depois disso, os arquivos são adicionados ao índice e confirmados. Parece-me que é muito conveniente. De fato, no código apresentado anteriormente do arquivo
package.json , isso já está implementado, apenas não falamos sobre isso antes.
Aqui está o conteúdo do nosso
package.json novamente:
{ "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" } }
Agora que você conhece os estágios Husky e Lint, pode avaliar o impacto deles no trabalho com o Git. Ou seja, suponha que os seguintes comandos foram executados:
$ git add . $ git commit -m "some descriptive message here"
É claro que, antes da confirmação, o código será verificado quanto à conformidade com as regras especificadas em
.eslintrc.js e, se necessário, corrigido. Graças a isso, os erros nunca entrarão no repositório de um projeto em funcionamento.
Agora você sabe como integrar o Prettier, ESLint, Husky e Lint em seu projeto.
Deixe-me lembrá-lo de que dissemos acima que nem todos os membros de sua equipe usam meu código VS favorito. Para que todos eles funcionem convenientemente, precisamos lidar com o arquivo
.editorconfig .
Arquivo .Editorconfig
Diferentes membros da sua equipe podem usar editores diferentes. Forçando-os a usar qualquer editor para qualquer coisa. No entanto, para que todos possam usar as mesmas configurações, por exemplo, recuos ou feeds de linha, usamos o arquivo
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 .
Sumário
, , , . , , .
Caros leitores! ? ?