Logo quando comecei a trabalhar no projeto Compufácil, há mais ou menos dois anos atrás, uma das coisas que me incomodava no Frontend era a inconsistência na escrita de código. O Backend já estava bem resolvido quanto a isso. Feito em PHP, todo o Backend já estava com as regras do PSR-2 e algumas docs sobre padrões de criação de arquivos e novos módulos. No post Code Style At Compufácil o Jean Carlo Machado fala sobre esse processo.
\nNo Frontend, não tínhamos padrão nenhum, nós usávamos espaços, ponto e vírgula e declarávamos variáveis onde bem entendêssemos. Quando a equipe é pequena, isso não afeta tanto, mas quando a mesma começa a crescer, a necessidade de criar e utilizar um padrão se mostra necessária.
\nLeve em consideração o código abaixo:
\nfunction create(entity, otherParam){\n…\n}
\nfunction update (entity,otherParam)\n{\n…\n}
\nfunction delete(id,otherParam) {\n…\n}
\nComo podemos observar, não há padrão nenhum. É estranho você encontrar num mesmo arquivo, funções que são definidas com chave de abertura na mesma linha e outra função que tem a chave de abertura na outra linha. Em um lugar é utilizado espaço depois do nome da função, em outros não. Espaços para separar os parâmetros em um lugar e em outro não.
\nPode ser que você olhe para aquela chave de abertura na outra linha e diga: — Que coisa bizarra, ninguém vai fazer aquilo em javascript.
\nImagine que alguém do backend, que esteja acostumado à um determinado padrão, venha editar um arquivo Javascript para incluir apenas uma função. Sim, isso acontece, não pense que não.
\nAcredite, quando você não tem um linter no projeto com um padrão combinado pela equipe, você facilmente chega no cenário acima, porque inúmeras pessoas vão editar o arquivo ao longo do projeto e cada uma vai escrever o código da maneira que bem entender.
\nO maior motivo de todos é que a nossa mente se dá bem com padrões. Uma vez que ela se adapta a um padrão, seu esforço cognitivo no momento de leitura diminuí. Considerando que grande parte do tempo que estamos programando, nós passamos lendo o código, isso impacta diretamente em nossa produtividade.
\nUm código bem organizado e bem escrito é muito mais fácil de entender, dar manutenção e até de refatorar. Você economiza tempo e esforço e todo mundo sai ganhando.
\nVocê e sua equipe devem começar pela escolha de um padrão, existem vários, mas alguns são mais conhecidos:
\n\n\n\nNessa hora não comece um bikeshedding, mais importante do que determinar se o padrão será X ou Y, é ter um padrão estabelecido. Dê preferência para os mais utilizados em projetos open source, eles já foram validados por inúmeras pessoas.
\nApós a escolha do padrão, você pode utilizar o ESLint para verificar se o seu código está de acordo com o padrão. O ESLint pode ser colocado junto ao seu processo de build, que pode estar no npm script, gulp, grunt ou em um bash script.
\nÉ possível também incluir o ESLint no hook de pre-commit do git, não deixando nem ser feito commit das alterações caso o arquivo não esteja dentro do padrão. Essa abordagem funcionou bem para nós, uma vez que no pre-commit nós rodávamos o linter apenas nos arquivos alterados, o que permitiu que fizéssemos as correções gradualmente, mas que mesmo gradualmente, todo programador era educado a escrever o novo código dentro do padrão.
\nUtilizando o npm, o ESLint pode ser instalado tanto globalmente quanto localmente. Dê preferência por instalá-lo localmente e incluí-lo como uma dependência do projeto. Dessa forma, assim que o dev instala o projeto, o linter já está incluso, não sendo necessário nenhuma instalação adicional para o uso do mesmo.
\nnpm i —save-dev eslint
\nApós instalarmos o ESLint, precisamos instalar o módulo contendo as regras do padrão que foi escolhido:
\nPara fins de exemplo, vamos levar em consideração que escolhemos o padrão do airbnb. Nesse caso, o processo de instalação seria o seguinte:
\nnpm i —save-dev eslint-config-airbnb
\nApós a instalação é só criar um novo arquivo com o nome .eslintrc, na raiz do projeto, com o seguinte conteúdo:
\n{\n“extends”: “airbnb”\n}
\nVocê também pode colocar sua regras customizadas nesse arquivo, como no exemplo abaixo:
\n{\n“extends”: “airbnb”,\n“rules”: {\n“no-use-before-define”: 0\n}\n}
\nAcesse o eslint.org para ver as regras disponíveis.
\nApós a criação do arquivo, vamos incluir o comando no npm scripts:
\n“scripts”: {\n“lint”: “eslint path/to/js”,\n“lint:fix”: “npm run lint — —fix”\n},
\nPara a utilização do mesmo, basta executar:
\nnpm run lint
\nO comando acima executa apenas o lint e imprime os erros. O ESLint ainda conta com um autofix, para corrigir os erros mais simples. Como já incluímos ele no npm script, basta executar:
\nnpm run lint:fix
\nO autofix deve ser executado com muita atenção! Caso utilizá-lo, verifique os diffs nos seus arquivos.
\nComo mencionado acima, é possível incluir um script no hook do pre-commit do git. Dessa forma, toda vez que alguém for fazer commit, o lint será executado nos arquivos alterados, fazendo com que os desenvolvedores coloquem dentro do padrão os arquivos que editarem.
\nPara isso, a partir da pasta raiz do seu repositório git, edite o arquivo: .git/hooks/pre-commit
\nInserindo o conteúdo abaixo:
\nSFILES=” JS_STAGED_FILES_CMD=`git diff —cached —name-only —diff-filter=ACMR HEAD | egrep ’\\.(js)$’`\nSFILES=${SFILES:-$JS_STAGED_FILES_CMD}
\nfor FILE in $SFILES; do\nnode path/to/node_modules/eslint/bin/eslint.js > /dev/null 2>&1
\nif \\[ $? != 0 \\]; then\n echo "Fix file: $FILE"\n exit 1\nfidone
\nexit $?
\nBasicamente, o que o script acima irá fazer, é pegar todos os arquivos com a extensão .js que estão no estado staged do git e executar o lint em todos. Se houver algum erro, o script corta a execução retornando 1, o que não permitirá que seja feito commit dos arquivos alterados.
\nPadrões de escrita de código não se limitam apenas a espaçamentos ou onde colocar ponto e vírgula ou não. Também existem style guides que definem a organização e arquitetura do projeto, além de possuir orientação sobre como escrever um novo service, factory, classe e etc…
\nEssas práticas ajudam a manter um padrão dentro do projeto, o tornando mais intuitivo. Isso auxilia desde a curva de aprendizado de novos desenvolvedores no time, até a produtividade de desenvolvedores experientes.
\nGostou do post e achou útil? Dê um like ❤️ abaixo para ajudar na divulgação e para que mais pessoas tenham acesso :)
","fields":{"slug":"/blog/2016/10/10/sobre-padroes-de-escrita-de-codigo"},"frontmatter":{"title":"Sobre padrões de escrita de código","date":"10 de Outubro de 2016","datetime":"2016-10-10 13:49:35","description":"Logo quando comecei a trabalhar no projeto Compufácil, há mais ou menos dois anos atrás, uma das coisas que me incomodava no Frontend era a…","language":"pt-br","keywords":[],"imageBy":null,"image":{"id":"3e9fbdbd-21e5-50a1-badd-a8b703c8c0a8","publicURL":"/static/1__fDCDg________xV7Zx6zeLgXMQ-24f8070ac3dcbe93934fac1babc32b8d.jpeg","childImageSharp":{"fluid":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAHABQDASIAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAT/xAAWAQEBAQAAAAAAAAAAAAAAAAADAAH/2gAMAwEAAhADEAAAAYRbWBf/xAAaEAACAgMAAAAAAAAAAAAAAAABAgADERIT/9oACAEBAAEFArDlq02HGf/EABcRAAMBAAAAAAAAAAAAAAAAAAABAxH/2gAIAQMBAT8BmjEf/8QAFxEBAAMAAAAAAAAAAAAAAAAAAAECEf/aAAgBAgEBPwG8tf/EABkQAAMAAwAAAAAAAAAAAAAAAAABETFBUf/aAAgBAQAGPwK7g+GWf//EABkQAAIDAQAAAAAAAAAAAAAAAAARASFBUf/aAAgBAQABPyFFpaBUfSE2A//aAAwDAQACAAMAAAAQf8//xAAXEQEAAwAAAAAAAAAAAAAAAAAAARFh/9oACAEDAQE/EILYP//EABYRAQEBAAAAAAAAAAAAAAAAAAABEf/aAAgBAgEBPxCjT//EABoQAQACAwEAAAAAAAAAAAAAAAEAESExQYH/2gAIAQEAAT8QM5MarsawFih2nkvDRYBJ/9k=","aspectRatio":2.67,"src":"/static/24f8070ac3dcbe93934fac1babc32b8d/7c190/1__fDCDg________xV7Zx6zeLgXMQ.jpg","srcSet":"/static/24f8070ac3dcbe93934fac1babc32b8d/e66c2/1__fDCDg________xV7Zx6zeLgXMQ.jpg 480w,\n/static/24f8070ac3dcbe93934fac1babc32b8d/7c190/1__fDCDg________xV7Zx6zeLgXMQ.jpg 801w","sizes":"(max-width: 801px) 100vw, 801px"}}}}}},"pageContext":{"slug":"/blog/2016/10/10/sobre-padroes-de-escrita-de-codigo","language":"pt-br","dateFormat":"DD [de] MMMM [de] YYYY","previous":{"fields":{"slug":"/blog/2016/09/15/o-sentimento-de-propriedade-do-codigo","identifier":"/2016/o-sentimento-de-propriedade-do-codigo/"},"frontmatter":{"title":"O sentimento de propriedade do código","date":"Sep 15, 2016"}},"next":{"fields":{"slug":"/blog/2016/10/19/como-react-e-redux-me-fizeram-um-programador-melhor","identifier":"/2016/como-react-e-redux-me-fizeram-um-programador-melhor/"},"frontmatter":{"title":"Como React e Redux me fizeram um programador melhor","date":"Oct 19, 2016"}}}}}