Estrutura interna do Git – Parte 2

Não exatamente uma sequencia, porém ainda ficaram alguns pontos que eu acho muito interessante do Git que levarei em conta quando precisar desenvolver algo.

Além dos comandos normalmente utilizados, que para quem utiliza o bash completion possui autocompletamento, existem vários comandos “ocultos”, porém documentados. O comando git cat-file do texto anterior é um exemplo. Isso ocorre pela forma que os comandos do Git foram feitos, existe um conjunto de comandos básicos para executar pequenas tarefas, assim como a filosofia UNIX (uma única coisa, porém bem feita). Ou seja, comandos para adicionar arquivos na estrutura do Git, recuperá-los, calcular diferenças, aplicá-las, lidar com braches e outros.

No capítulo 9 do Pro Git temos um exemplo melhor desses comandos, e até como fazer um commit sem utilizar o git commit. Isso mostra que até mesmos comandos internos são implementados utilizando outros comandos, dividindo o problema em partes menores.

Agora imagina que você está desenvolvendo um sistema que utiliza alguma parte do Git, como o GitHub para visualizar o código, ou o OpenShift para receber o código e fazer deploy da aplicação. Como existem várias operações você não precisa desenvolver algo para ler a estrutura do Git, pode simplesmente reutilizar esses comandos, ou seja, a API já está pronta, basta adaptá-la para a sua linguagem.

Porém não precisamos ir muito longe para tirarmos proveito disso. No meu texto Verificador de estilo de código no VIM, comentei sobre os verificadores de estilo e podemos utilizá-las em conjunto com o Git. Imagine que seu projeto tem um estilo que todo o código deve ser seguido, porém as vezes alguém acaba deixando passar um espaço a mais, troca espaço por tab. No Git podemos fazer a validação do código é permitir o commit apenas caso ele esteja de acordo com o estilo.

Para fazer essa verificação precisamos utilizar outro recurso chamado de Hook, que são scripts executados em determinados momentos (consulte o capítulo 7.3 do Pro Git). Inicialmente fiz a verificação apenas local para lembrar caso tenha alguma coisa fora do padrão, mas ainda possível forçar o commit se assim for desejado. Como os projetos tinham vários arquivos fora do estilo, queria verificar apenas os alertas referentes as minhas mudanças, até por questão de performance, se eu não alterei o arquivo não preciso ser lembrado que ele tem algum erro, deixando a saída até menos poluída e posso verificar todos os arquivos caso esteja atrás de erros.

Primeira coisa, preciso saber quais os arquivos que foram alterados no commit, para tanto utilizei o comando git diff –raw –cached, uma informação um pouco mais bruta dos arquivos selecionados com git add. Porém eu posso ter executado o git add e alterar o arquivo novamente antes de fazer o commit, então não posso simplesmente fazer a validação do código do arquivo no diretório, para isso utilizei a hash do git diff para pegar o arquivo que será commitado com git show e fazer a validação em cima dele.

Quem quiser ver como tudo ficou, tenho esse código no meu GitHub (https://github.com/eduardoklosowski/codelint), está escrito em Python, porém tenho que trabalhar melhor a documentação e ter decidido fazer tudo em inglês não ajudou, porém assim que estudar melhor as formas de documentação e opções que tenho para compartilhá-la irei fazer isso, mas se alguém for usar e tiver alguma dúvida deixe nos comentários, até ficarei feliz em saber que alguém está utilizando (testando). Report de bugs, melhorias no código ou funcionalidades novas são bem vindas. Pode ser utilizado com outras ferramentas de controle de versão, só não tenho conhecimento e necessidade para isso agora, mas pode ser facilmente desenvolvido já que o Git foi feito a parte também.

Depois de criar os arquivos de configuração em ~/.config/codelint, preparo tudo para o commit e executo git codelint, isso iniciará os validadores. Um detalhe que todos os comandos no PATH que começam com git-, exemplo git-codelint podem ser executados como comandos do git dessa forma e com autocompletamento.

Agora só falta colocar no Hook executado antes do commit, o pre-commit, seu conteúdo é simples.

#!/usr/bin/env bash
git-codelint

Caso queira verificar os arquivos antes de commitar posso executar git codelint e quando der o git commit será verificado, se tiver algum erro o commit será interrompido para correção, ou posso forçar com git commit -n.

Anúncios

Verificador de estilo de código no VIM

Exemplo pep8

Como mencionado no texto anterior sobre o VIM, existem algumas ferramentas para análise de sintaxe e estilo de código. A principal vantagem dessas ferramentas é a possibilidade de validar o código independente da IDE, uma vez que nem todos gostam e se acostuma com as mesmas ferramentas, o maior exemplo é a “flame war” VIM e Emacs, mesmo assim é possível ter um nível de padrão no código.

As ferramentas e alertas variam conforme a linguagem desejada, porém basta uma pesquisa para encontrá-las. Para Python temos o pep8 e o Pylint, o primeiro faz a verificação segundo as regras da PEP8, o segundo vai além e mostrar variáveis que não são utilizadas, algumas boas práticas, erro nos imports e assim por diante.

Para JavaScript temos o JSLint e o JSHint, ambos efetuam a mesma tarefa, porém possuem diferenças de configuração e o estilo do código correto também será levemente diferente, basta ver o que melhor se adapta a situação.

Integrar esses verificadores no VIM exige que primeiro tenhamos eles instalados e funcionando corretamente no sistema. O pep8 instalei via pip (pip install pep8), caso o faça dentro de um virtualenv não se esqueça que o executável deve estar no PATH para que seja encontrado. O JSLint foi instalado com o Node.js. Para utilizá-los basta chamar o executável, pep8 ou jslint, e o nome do arquivo, agora é possível configurar dentro do VIM.

Como já mencionado no texto anterior, simplesmente configurei o validador como se fosse o compilador, o que pode ser feito com o parâmetro “makeprg”, porém para que os erros aparecem integrados ao VIM é necessário informar como ele deve interpretar a saída dos programas com o parâmetro “errorformat” (digite :help errorformat dentro do vim para mais informações).

Minha configuração ficou:

autocmd Filetype python set makeprg=pep8\ %
autocmd Filetype python set errorformat=%f:%l:%c:\ %t%n\ %m
autocmd Filetype javascript set makeprg=jslint\ %
autocmd Filetype javascript set errorformat=%-P%f,
                                           \%E%>\ #%n\ %m,%Z%.%#Line\ %l\\,\ Pos\ %c,
                                           \%-G%f\ is\ OK.,%-Q

Para validar o código basta salvar o código, e executar :make. Porém se você quiser pode criar um atalho para essa tarefa, no meu caso coloquei no F4:

map <F4> :w<CR>:cw<CR>

Lembrando que esses comandos devem ficar dentro do .vimrc no seu home.