Recentemente alguém no Slack de Python em Berlim comentou que a empresa em que ele trabalha havia começado um projeto Python e ele precisava de ajuda. Ele postou a seguinte pergunta:

How do you deal with team members who write Python as if it was bash/idl/Fortran? How do you introduce pep 8 in a “soft” way (if such thing exist)?

Nesse post quero compartilhar com vocês algumas práticas que podem ajudar nesse problema! Os exemplos serão em Python mas os conceitos devem ser aplicáveis a outras linguagens. :)

Se vocês vissem meu repositório da minha pesquisa de mestrado, vocês ficariam enjoados. E eu teria me ajudado muito se eu tivesse utilizado pelo menos metade dessas coisas abaixo, especialmente porque um código mais limpo e mais fácil de ler e manter (o que não era o caso do meu naquela época).

pre-commit

Com fé na deusa vocês vão estar versionando seus códigos e tem uma grande chance que estejam usando o Git pra isso (e não o Dropbox 😂). O Git permite que você tenha scripts (bash ou Python, por exemplo) para serem executados antes do commit, do push, do rebase etc. Basta chegar na pasta hooks (dentro de .git) e alguns templates vão estar lá.

Você pode escrever o seu script bash/Python, tipo esse aqui. Mas talvez este framework para pre-commits torne sua vida mais fácil. Com ele você só precisa ter um arquivo como .pre-commit-config.yaml e tudo certo. Mas o que colocar dentro dele?

O Python tem a PEP8, um guia de estilo para código Python. Ficou na dúvida se quebra a linha antes ou depois de um operador? Lá tem. Não sabe se fica bom várias linhas em branco pelo código? Tem lá também. Dar uma olhada na PEP8 é essencial pra quem coda em Python.

Dito isso, gostaria de apresentar a vocês algumas bibliotecas que uso atualmente com o pre-commit. Para código Python, todas elas baseam-se na PEP8 e são configuráveis (pro caso de você querer usar 100 colunas ao invés de 80, por exemplo). 😉

pydocstyle: vai checar se os seus comentários estão de acordo com as convenções da docstring.

pycodestyle: checa se o seu código está de acordo com a PEP8 (antigamente a lib era chamada de pep8 mesmo).

isort: essa aqui é uma mão na roda. Ela indenta e organiza os seus imports em ordem alfabética. Você não precisa nem se preocupar - tentou commitar e os imports estão bagunçados? Basta adicionar os arquivos de novo e tudo certo.

pylint: um analisador de código, que ajuda a evitar os famigerados code smells.

msgcheck: se você está usando Django e os recursos de internacionalização dele, esse linter é bem útil. Ele vai checar coisas como pontuação e erros de escrita.

shellcheck: um analisador estático, pro Shell.

sqlformat: pra deixar suas queries SQL mais gatinhas.

relint: o relint faz uma análise estática baseada em expressões regulares. Por exemplo: decidimos que não queremos usar mommy_make e sim mommy.make_recipe. Todas as vezes que executarmos o relint, ele vai checar se as linhas de código alteradas usam determinadas regras, como em:

- name: model_mommy recipies
  pattern: "mommy\\.make\\("
  hint: Please use mommy.make_recipe instead of mommy.make.
  filename:
    - "**/test_*.py"
    - "conftest.py"
    - "**/conftest.py"

Além dessas que citem, tem algumas outros linters que dispensam uma descrição:

trailing-whitespace

end-of-file-fixer

debug-statements

check-added-large-files

Existem outras bibliotecas que não temos no pre-commit mas que me ajudam quando estou na dúvida sobre como formatar o meu código. As duas me ajudam a deixar meu código Python mais organizado!

yapf: o formatador de código Python criado pelo Google

black: o mais novo formatador de código na cidade

code style guide

Comentei acima que o Python tem seu próprio Style Guide e é interessante que todo projeto/empresa tenha um também. Assim, quando pessoas novas entrarem no time, elas vão saber exatamente o estilo utilizado e vão poder guiar-se por ele. Atualmente o style guide da empresa que trabalho (a Thermondo) está meio desatualizado mas já é um começo: thermondo.github.io/style-guide.

CI (continuous integration)

Além de usar bibliotecas no pre-commit você pode adicionar também como um gate no seu CI (ferramenta de integração contínua). Se tá por fora do que é isso, tudo bem. Dá uma olhada aqui.

Recentemente um colega de trabalho desenvolveu uma ferramenta super legal que permite que você adicione linters como os que eu citei acima nos seus repositórios no Github. A ferramenta vai executar os linters usando Lambdas da AWS. Dá uma olhada nela, é a Lambda Lint. Já tem vários linters disponíveis e todo o código é aberto (e a ferramenta é gratuita!).

code review

Por fim, queria falar sobre a coisa mais importante pro meu aprendizado quanto desenvolvedora e pra qualidade do código no geral: code review. Basicamente, o processo de code review consiste em pedir a alguém que revise o seu código, com o objetivo de compartilhar conhecimento e, principalmente, te dar feedbacks sobre design/arquitetura de código e eventuais coisas relacionadas (como regras de negócio que podem ter passado desapercebidas).

Usando as ferramentas acima, a pessoa que vai revisar o código vai ter mais espaço para focar em aspectos mais profundos do código e quem desenvolveu aquela funcionalidade terá mais feedbacks de qualidade.

Deixo aqui o texto How to Do Code Reviews Like a Human para quem quiser saber como revisar código de maneira bacana. Infelizmente frases como tá uma porcaria ou a organização desses imports me fazem chorar (sim, exemplos da vida real) não são úteis.

Bem, por hoje é só pessoal!