Melhores práticas para desenvolvimento Python/Django
Bom dia, boa tarde, boa noite.
Dando continuidade ao blog irei tratar hoje das melhores práticas para desenvolvimento Python/Django, e quando falamos em melhores práticas os primeiros passos que devemos seguir são as famosas PEP’s, Pyhton Enhancement Proposal (Proposta de Melhoria do Python), do Python.
As PEP’s foram escritas por várias pessoas ligadas ao Python e a mais famosa delas, mas não a única, é a PEP8 escrita pelos autores: Guido van Rossum <guido em python.org>, Barry Warsaw <barry em python.org>.
Não pensem que as PEP’s são restritivas ou obrigatórias, são apenas melhores práticas e você pode ou não seguir, mas aviso logo que para tornar-se um bom programador Python/Django e desejar um emprego bom, é altamente aconselhável seguir ao máximo as “dicas” das PEP’s e como já falei sendo a PEP8 a mais “famosa” vamos discutir um pouco sobre algumas “dicas” que devem ser adotadas tanto no Python, como consequentemente no Django.
PEP 8 | http://www.python.org/dev/peps/pep-0008/
- Utilizar quatro espaçamentos no lugar de tab’s para a identação.
- Nunca misturar espaços com tab’s.
- Comprimento máximo de cada linha 80 caracteres, para a quebra de linha utilizamos \ ou agrupamos o trecho de código com (), essa regra em particular eu não uso muito, pois dificulta a minha leitura.
# Alinhados com a abertura delimitador foo = long_function_name (var_one, var_two, var_three, var_four)
- Utilizar duas linhas em branco entre a declaração das classes.
- Os imports devem ser feitos em linhas separadas.
import sys import os from subprocess import Popen, PIPE
- Quando importar uma classe de um módulo de mesmo nome, não há problemas em usar.
from MyClass import MyClass from foo.bar.YourClass import YourClass
- Evitar espaços em branco nos seguintes lugares:
- Antes e após parêntese, colchete ou chave.
Errado: spam( ham[ 1 ], { eggs: 2 } )
Certo: spam(ham[1], {eggs: 2}) - Logo antes de uma vírgula, ponto-e-vírgula ou dois-pontos.
Errado: if x == 4 : print x , y ; x , y = y , x
Certo: if x == 4: print x, y; x, y = y, x - Imediatamente antes da chave que abre um índice.
Errado: spam (1)
Certo: spam(1) - Logo antes do parêntese que abre a lista de argumentos de uma função.
Errado: dict [‘key’] = list [index]
Certo: dict[‘key’] = list[index]
- Antes e após parêntese, colchete ou chave.
- Nomes e identificadores.
- _underscore_no_inicio: costuma indicar que o atributo é de uso interno
- underscore_no_fim_: usado para evitar conflitos com palavras-chave
- __dois_underscores_no_início: atributo privado da classe
- __dois_underscores_no_início_e_no_fim__: atributos ou objetos especiais, como __init__ , __import__ ou __file__
- Módulos, devem ter as declarações TodaEmMaiusculas
- Nomes de classes, sempre devem ser declaradas TodaEmMaiuscula
- Nomes de funções, podem ser declaradas TodaEmMaiuscula ou toda_em_minuscula
Como falei antes, as “dicas” podem ou não ser seguidas, mas devemos sempre ter um mente que nosso código será lido em algum momento por outra pessoa, e mesmo nós quando passamos muito tempo ser lermos o código sentiremos dificuldade quando surgir a necessidade de darmos manutenção num determinado código, por isso para mim a principal dica é sobre o DocStrings que tratam sobre os comentário.
Devemos documentar os módulos, as funções, as classes e os métodos públicos, tais documentações devem vir logo abaixo das declarações, os DocStrings também são utilizados para testes no Python/Django devendo conter também declarações de testes, mas isso é assunto para o próximo post.
>>> print u’%s’ % (“Abraços”)