Assegure a qualidade do seu código Python

Se você precisa de uma ferramenta mais poderosa que o pep8, talvez você precise do Pylint.

De forma (bem) resumida, o Pylint analisa de forma minuciosa o código do seu projeto Python, lhe retornando uma variedade de relatórios (as vezes, detalhistas até demais) sobre todo o tipo de problema que ele encontra. Indo de incoerências com a PEP 8, até nome de variáveis.

É sem dúvida, uma das melhores ferramentas feitas para o Python, e é essencial para você deixar o seu código mais próximo do “estado da arte”.

Mas o que eu achei mais legal sobre o Pylint, foi um comentário em sua documentação. O autor salienta muito bem que a ferramenta pode ser eficiente em certos contextos, mas não em todos. Então, antes de “pularmos de cabeça”, peço que você utilize o bom senso e saiba mensurar as suas necessidades em relação ao que a ferramenta tem a oferecer.

Na prática

Vamos testar as conformidades do arquivo site.py segundo o Pylint:

$ pylint /usr/lib/python2.7/dist-packages/site.py

O resultado pode parecer assustador. Então “vamos começar pelo começo”.

O resultado do Pylint é dividido em duas grandes seções: análise de código e relatório; O primeiro, como o nome sugere, apresenta uma análise de código bem semelhante a apresentada pelo pep8. Porém no seguinte formato:

MESSAGE_TYPE: LINE_NUM:[OBJECT:] MESSAGE

Vamos pegar a primeira linha gerada pelo Pylint para entender melhor:

C: 1: Missing docstring

C é o tipo da mensagem, 1 é o número da linha (no arquivo) onde o problema foi constatado,Missing docstring é a mensagem gerada. O Pylint poderá apresentar os seguintes tipos de mensagens:

[R]efactor for a "good practice" metric violation
[C]onvention for coding standard violation
[W]arning for stylistic problems, or minor programming issues
[E]rror for important programming issues (i.e. most probably bug)
[F]atal for errors which prevented further processing

Quase posso ver o brilho em seus olhos. A saída do Pylint deixou de ser enigmática, não?!

A segunda seção, a de relatório, apresentará alguns números interessantes sobre o seu projeto. Como o número de warnings e errors, uma nota para o seu projeto (e um comparativo com a execução anterior do Pylint), quantidade de código duplicado, quantidade de código documentado e “desenhará” uma árvore de dependências do seu projeto.

Diminuindo o ruído

Eu avisei que o Pylint era “barulhento”!

Vamos reduzir um pouco o nível de detalhes da ferramenta, passando alguns parâmetros:

$ pylint /usr/lib/python2.7/dist-packages/site.py --reports=n --include-ids=y --disable=W0232

Primeiro, com o parâmetro –-reports=n dizemos que não queremos aquele relatório gigantesco no final da análise. O –-include-ids=y exibe para gente os ids das mensagens de erros do Pylint. É útil, pois todas as mensagens que você julgar desnecessárias para a análise você adiciona no parâmetro -–disable (separadas por vírgula).

Para que não seja necessário passar todos esses parâmetros todas as vezes que executar o Pylintbasta gerar um arquivo .pylintrc:

$ pylint --reports=n --include-ids=y --disable=W0232 --generate-rcfile > ~/.pylintrc

É possível gerar este arquivo por projeto, podendo mudar a especificidade das métricas de acordo com a necessidade. Quer saber mais? Leia este tutorial muito bom, direto da documentação doPylint.

Para entender os códigos das mensagens, confira a listagem nesta wiki, ou utilize o parâmetro -–help-msg:

$ pylint --help-msg=R0904

:R0904: *Too many public methods (%s/%s)*
  Used when class has too many public methods, try to reduce this to get a more
  simple (and so easier to use) class. This message belongs to the design checker.