Oi pessoal, desta vez eu vou pular as ‘desculpas’ por ter demorado tanto para postar aqui no blog e vamos direto ao assunto.
Recentemente eu tenho trabalhado bastante com Python (dã!) desenvolvendo projetos de diversos tipos e resolvi escrever aqui sobre algumas coisas que pratico enquanto desenvolvo.
Esse artigo é uma espécie resumo com boas práticas de programação Python que utilizo no meu dia-a-dia.
Código mais robusto
Deu certo ou errado?
O que você faz quando acontece algo errado na execução do seu método? O que você responde à requisição que lhe foi feita?
Eu tenho visto em muito código por aí os desenvolvedores retornando valores sentinela (None, null, 0, -1, etc.) para avisar que algo incorreto aconteceu na execução do método.
def f(arg):
if not arg:
return None
return ["resultado", "de", "um", "processamento"]
Algumas linguagens de programação não possuem estruturas de tratamento de exceção e, neste caso, o uso de sentinelas é válido. Mas quando a linguagem de programação te disponibiliza essa funcionalidade é bom usá-la.
def f(arg):
if not arg:
raise ValueError("Argumento Invalido")
return ["resultado", "de", "um", "processamento"]
Deixem as exceções fluirem.
Isso mesmo. A menos que você saiba exatamente o que você deve fazer quando uma exceção aparece deixe-a exceção “subir”. Pode ser que “lá em cima” alguém saiba cuidar dela adequadamente.
Quando não fazemos isso estamos ocultando informação importante para os usuários do nosso código (sejam eles usuários, outros desenvolvedores ou nós mesmos).
def f():
try:
return conecta()
except ExcecaoQueDeveriaSerErro:
return None
Quando eu implemento esse tipo de método/função eu faço assim (na verdade eu não implementaria f() e chamaria conecta()):
def f():
return conecta()
O que seu método/função retorna?
Código que eu encontrei recentemente:
def get_fulanos():
q = Q("select * from patuleia where alcunha like 'fulano%'")
ret = [str(fulano['nome']) for fulano in q]
if len(ret) == 1:
return ret[0]
return ret
Perceberam o que está errado? O seu método retorna uma lista de Fulanos ou retorna Fulano?
Isso está conceitualmente errado e pode fazer você perder horas preciosas do seu dia tentando achar um bug causado por esse tipo de código.
Aconteceu comigo. Note que str() implementa uma interface de sequence da mesma forma que list(). Então o erro passa silenciosamente no caso abaixo:
old_fulanos = ["Ze Ruela", "Ze Mane"]
old_fulanos.extend(get_fulanos())
print(old_fulanos)
Rodando esse código você vai obter ['Ze Ruela', 'Ze Mane', 'q', 'u', 'a', 'c', 'k'] sendo que, em mais de 90% dos casos, o que você gostaria de ter seria: ['Ze Ruela', 'Ze Mane', 'quack'].
“Nada” é diferente de “alguma coisa”.
Essa dica é só uma complementação da primeira e da segunda dica.
Quando o seu método/função retorna uma collection (seqüência, conjunto, hash, etc) vazia você deve retorná-la vazia e não um valor sentinela (como None). Isso facilita a vida de quem vai usar o seu método/função:
def vazio():
return []
for elemento in vazio():
pass #... faz algo se o conjunto contiver dados ...
Se você retorna um valor sentinela:
def vazio():
return None
elementos = vazio()
if elementos:
for elemento in elementos:
pass # ...
Notou que tivemos que criar uma variável com o resultado da operação (para não precisar chamá-la duas vezes) e tratar a sentinela com um “if“? Se eu esqueço de tratar a sentinela meu programa vai quebrar.
Lembre-se sempre que uma collection vazia tem valor booleano “False“.
Todo ‘elif‘ tem um irmão ‘else‘.
Sempre que você precisar usar uma construção if/elif coloque uma cláusula ‘else‘.
Além de usar a cláusula ‘else‘ eu geralmente faço com que ela gere uma exceção. Desta forma eu sou obrigado a trabalhar todas as possibilidades nos ‘if/elif‘ evitando ocultar uma situação que pode ser inválida.
class InvalidCommand(Exception):
pass
def minihelp(comando):
if comando == "print":
return ("Imprime dados na tela. "
"Deixará de ser comando "
"no Python 3.0")
elif comando == "assert":
return ("Certifica se uma condição é "
"verdadeira e gera uma excessão "
"em caso contrário")
elif comando == "...":
pass # ...
else:
raise InvalidCommand(f"Comando {comando} inválido.")
Eu gosto dessa prática mas isso não significa que você deva seguí-la sempre. Existem situações onde ter um “valor default” é necessário e nestes casos o uso do else sem levantar exceção se faz necessário.
if comando == "if":
print("Vai usar elif?")
elif comando == "elif":
print("Muito bem. Agora falta o else")
else:
print("Pronto. Agora está bom.")
“Pythonismos”
Use mais atributos públicos do que atributos protegidos (“_“).
Programadores acostumados com Java utilizam muito as cláusulas ‘private‘ e ‘protected‘ para encapsular os atributos de um objeto para logo depois implementarem os getters e setters para acessar esses atributos.
Essa prática é aconselhada em Java porque em algum momento do futuro você, talvez, precise validar esses dados ou retornar valores calculados. Nestes casos os programadores apenas implementam essa lógica nos métodos que acessam o atributo privado.
Mas em Python isso não é necessário. Em Python você pode transformar seu atributo público em uma “property” que não muda a forma de se acessar o atributo e permite o acrescimo de lógica ao acesso do mesmo.
Evite usar “__“.
Por convenção, em Python, todo método ou atributo iniciado com um “_” é considerado privado (equivalente ao protected em Java) e não deve ser acessado de fora da classe mesmo sendo possível fazê-lo.
Dito isso parece meio óbvio que não precisamos usar “__” para dificultar ainda mais o acesso à esse atributo/método. Além disso o uso do “__” traz alguns incoveninentes para quem quer derivar a sua classe e acessar este método/atributo já que o Python o renomeia acrescentando o nome da classe ao seu nome (__attr vira _Classe__attr).
Não sobrescreva builtins.
Python disponibiliza várias funções e classes builtins que facilitam muito o uso da linguagem e economizam digitação. Mas esses builtins tem nomes muito “comuns” e frequentemente a gente usa os nomes dos builtins como nomes de identificadores. Eu mesmo vivo (vivia) fazendo isso.
O problema é que em certos momentos alguns problemas podem acontecer quando você tenta chamar um buitin que já não é mais um builtin. Na maioria das vezes o problema “explode” logo e você rapidamente conserta mas em alguns casos você pode perder muitas horas tentando achá-lo.
Algumas pessoas usam um “_” no fim do nome do identificador (ex. “id” vira “id_”) mas eu acho isso um pouco feio então uso só quando não encontro uma alternativa melhor.
Vou colocar aqui uma tabela de equivalências que eu costumo usar para substituir o nome dos builtins mais comumente sobrescritos:
- id – ident, key
- type – kind, format
- object – obj
- list – plural (lista de element vira elements)
- file – fd, file_handler
- dict – dic, hashmap
- str – text, msg
Análise estática economiza seu tempo.
Eu uso o pylint, mas conheço algumas pessoas que preferem o pyflakes ou o PyChecker.
UPDATE (2023-08-08): utilizo o utilitário ruff com muito sucesso nos meus projetos mais novos. O ruff agrega todos os utilitários acima e mais vários outros.
A dica é essa: usar um programinha de análise estática como esses pode diminuir consideravelmente aqueles errinhos chatos de sintaxe, ou de digitação. Pode limpar os ‘import’ desnecessários do seu software, etc, etc.
É lógico que esse tipo de ferramenta não substitui uma boa política de testes mas é um bom complemento para ela.
Challenge yourself
Máximo de 3 níveis de indentação. (ou 4 se estiver dentro de uma classe)
Ao se esforçar para que seu código não fique muito aninhado você está trabalhando melhor a implementação dos seus métodos e funções. Nem sempre é possível (ou aconselhável) restringir tanto o nível de identação do seu código mas muitas vezes isso melhora a sua implementação.
Máximo de 2 indireções.
Recebeu um objeto como parâmetro? Chame apenas métodos dele e evite ao máximo chamar métodos do retorno desses objetos:
def f(obj):
obj.metodo() # legal!
obj.metodo().outro_metodo() # ruim!
Quando você chama um método pra um objeto retornado por outro método você está aumentando o acoplamento entre as classes envolvidas impedindo que uma delas seja substituída (ou reimplementada) ‘impunemente’.
Essa regrinha é uma das regrinhas da Lei de Demeter.
Máximo de 0 ‘if/elif/else‘s.
Polimorfismo é isso. No mundo OO ideal, perfeito e utópico praticamente não precisaríamos do comando “if” e usaríamos somente polimorfismo. Mas… como não conseguimos isso tão facilmente* devemos, ao menos, usar o “if” com moderação.
Conclusão
Esta é uma lista incompleta de dicas para programadores Python. Se futuramente eu lembrar ou aprender algo novo eu volto aqui para falar sobre o assunto.
Alguns desenvolvedores podem não concordar com as dicas. Neste caso eles podem enriquecer ainda mais esse texto argumentando sobre o as suas restrições no espaço para comentários.
Se você tiver alguma dica para compartilhar com a gente coloque nos comentários. Se ela for boa mesmo eu coloco ela no corpo principal do blog.
* eu mesmo só consegui fazer uma aplicação OO funcional sem usar um único if. Era uma implementação do joguinho de adivinhação de animais (aquele que pergunta “Vive na água? (s/n)”) em Smalltalk.
Update: pequena correção sugerida pelo Francisco nos comentários: s/Classe/_Classe/.
