Bom, PEP é uma sigla para Python Enhancement Proposals o que poderíamos definir como uma proposta de aprimoramento da linguagem Python como um todo, ou seja, tudo aquilo que está ligado ao Python;
- novas funcionalidades
- processos
- ambiente
- core
- e outros
Existem inúmeros PEPs, todos eles com seus devidos índices e autores que especificam a intenção do PEP.
Neste post vou falar especificamente do PEP 8, que vem a ser um guia para o estilo de layout dos códigos escritos em Python, foi proposto por Guido van Rossum e Barry Warsaw.
Para uma leitura mais detalhada você pode lê-lo em http://www.python.org/dev/peps/pep-0008/.
Todo o conteúdo é baseado na especificação original do PEP 8, mas neste post a minha intenção é criar exemplos detalhados a cada abordagem deste PEP e também explicar cada caso isoladamente, montando uma série de regras que podem ser facilmente retidas pelo leitor.
Muitos desenvolvedores dizem que as regras estabelecidas pelo PEP 8 são seguidas apenas para os códigos que estão no core do Python e módulos externos importantes. Mas não acho que seja bem assim, é muito importante que o desenvolvedor que esteja começando a escrever códigos em Python siga estas regras desde cedo.
Toda linguagem de programação respeitada tem uma padronização de layout do código, afinal essa é uma das boas práticas de programação mais importantes para um desenvolvedor, principalmente para desenvolvedores que ajudam no software livre.
"O meu código é o seu código."
O código de um desenvolvedor que ajuda a comunidade Software Livre sempre vai pertencer a milhares de outros desenvolvedores, nunca o código vai ficar retido à um programador, por isso que é muito importante que as regras se tornem um hábito.
A padronização do layout de código facilita a legiblidade, manutenabilidade e até mesmo a produtividade, porque essas regras seguem a mesma via do fluxo de documentação. Então você acaba gerando um código mais expansível aos olhos da comunidade.
1 - Code Layout
1.1 - Indentação
Sempre use 4 espaços por nível de indentação.
Dicas:
- nunca misture tabs com espaços. É bom você se adaptar com a indentação de 4 espaços, habituando-se com esse padrão você ganha produtividade e legibilidade. A indentação com 4 espaços evita várias dores de cabeça com editores de texto e ajuda no ciclo de manutenabilidade do código.
Fig 1.1.1
Fig 1.1.21.2 - Tamanho máximo das linhas
Sempre limite as linhas à um máximo de 79 caracteres.
Para blocos longos de texto (docstrings ou comentários), limite o tamanho para 72 caracteres.
Dicas:
- a melhor maneira de quebrar uma linha de instrução é atribuindo um par de parênteses "()" ao redor de uma expressão ou usando uma barra invertida "\" para indicar a quebra de linha.
- quando há uma quebra de linha em uma instrução a continuação da linha deve ser indentada com a linha mais acima.
- o melhor lugar para quebrar uma linha ao redor de um operador binário é após ele, e nunca antes dele.
- a estética de quebra de linha fica a critério do desenvolvedor, mas claro, seguindo as regras citadas acima.
Fig 1.2.1
1.3 - Linhas em Branco
Sempre separe o topo de funções e definições de classes com duas linhas em branco.
As definições de métodos dentro de uma classe são separadas por apenas uma linha em branco.
As definições de métodos dentro de uma classe são separadas por apenas uma linha em branco.
Dicas:
- linhas em brancos podem ser usadas para separar grupos de funções relacionadas.
- o uso de linhas em branco deve ser regrado para que o código não fique muito extenso, causando um cansaço e uma demora na leitura do código.
- as vezes para que um código não fique muito extenso a melhor maneira é reformular a modelagem do código em si para que seja possível a separação em mais de um arquivo.
- é sempre bom usar linhas em branco nas funções e métodos para separar seções lógicas.
1.4 - Encodificação
Para evitar problemas use sempre utf-8.
Em breve estarei postando a segunda parte do artigo.
Até mais!!!
Agradecimentos:
James Italiano - recorte das imagens
