Bom dia, boa tarde, boa noite.

Dando continuidade ao assunto que falei no último artigo, 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 PEPs – Pyhton Enhancement Proposal (Proposta de Melhoria do Python).

As PEPs 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/

1. Utilizar quatro espaçamentos no lugar de tab’s para a identação.

2. Nunca misturar espaços com tabs.

3. 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)

4. Utilizar duas linhas em branco entre a declaração das classes.

5. Os imports devem ser feitos em linhas separadas.

import sys 
import os 
from subprocess import Popen, PIPE

6. 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

7. 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]

8. 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”)