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.

Anúncios

Compartilhar prints com Django

Webprint

Algum tempo, desenvolvi um site com Django para compartilhar prints, motivado pela falta de praticidade do envio e visualização dos mesmo por email ou jabber. Seu código está disponível no meu GitHub. Não irei abordar como desenvolver um aplicativo Django neste post, porém vou deixar o link do tutorial da documentação oficial que é muito bom e da para se ter uma ideia inicial do seu potencial e praticidade, infelizmente apenas em inglês (https://docs.djangoproject.com/en/1.6/intro/tutorial01/, esse link é da versão 1.6, a mais atual na data de publicação deste post, porém é só procurar por tutorial na página principal da documentação de qualquer versão).

O meu objetivo aqui é mostrar o motivo de inicialmente ter gostado do Django, passado um tempo longe e posteriormente reconhecer o seu potencial. A primeira vez que tive contato com o desenvolvimento no mesmo foi maravilhoso e ver como as coisas eram práticas. Acesso ao banco de dados, formulários, templates, tudo era bem interessante e organizado.

Apesar das coisas serem práticas e ter um conhecimento razoável de Python na época, passava muito tempo pesquisando a documentação e sentindo que estava escrevendo uma coisa diferente de Python, apesar de ser a mesma linguagem. A falta de uma IDE com recursos avançados pode ter tido seu peso nisso. Porém não entender como era o seu fluxo com o HTTP e funcionamento com os middlewares do WSGI (que eu não tinha a menor ideia do que era na época) deixavam as coisas obscuras. Para quem veio de programação web com PHP e sem a utilização de um framework, acabei não gostando muito.

Tempo depois conheci o Bottle, por ser extremamente minimalista tive a impressão de voltar a programar da forma que tinha com o PHP. Como ele é extremamente simples (apenas um arquivo .py) e funcionar corretamente no Python 3 virou meu padrão de pensamento e tive a impressão de realmente programar para a web em Python.

Porém nem tudo é simples, utilizando-o diariamente no trabalho notei que passava muito tempo escrevendo código para acessar o banco, que logo foi adotado um ORM, porém para formulários continuava extremamente lendo e tedioso o trabalho, para minha surpresa não encontrei nenhum framework para resolver este problema. Voltei a olhar para o Django quando tive um tempo e lá estava uma solução para esse problema.

Ainda não desenvolvi nada grande com Django, porém hoje acho ele realmente completo para a tarefa, talvez não seja o melhor, mas é o que eu conheço (Python também tem mais frameworks web que palavras reservadas mesmo) e cumpre seu papel. Novamente fiquei surpreso ao perceber que o tempo que eu passava fazendo as coisas no Django e a forma como ele recomenda fazer as coisas era o que estava buscando hoje. Sim, ele também tem pilhas inclusas, ORM, formulários, autenticação e controle de permissão, tudo o que eu queria e iria precisar, ele já possuía.

O que aprendi com tudo isso é que sempre vale a pena aprender como um framework funciona e organiza o código de sua aplicação. Mesmo que não vai ser utilizado, essa ideia pode ser reaproveitada e se funciona é válido, mesmo que você odeie o resto dele, e quem sabe num futuro vir a ser adotado. Rails está na minha lista de coisas a aprender, embora ainda não conheça Ruby.