Recomendações para junção de linha implícita versus explícita


9

Gostaria de saber recomendações sobre junção de linha implícita versus junção de linha explícita em Python.

Em particular, você prefere um formulário ao outro? O que você recomenda como padrão geral? Que critérios você tem para escolher um sobre o outro e, se você prefere um, quando abre exceções?

Tenho uma resposta em mente para essa pergunta que reflete meus próprios vieses, mas antes de postar minha própria resposta, gostaria de saber o que os outros pensam ... e se você puder ter um conjunto de critérios melhor do que o que tenho em mente, então certamente aceitarei sua resposta sobre a minha.

Algumas das recomendações podem ser generalizadas para essa escolha em outras linguagens de programação, mas meu próprio viés é um pouco mais forte no Python devido a alguns recursos específicos da linguagem. Por isso, gostaria de saber o raciocínio geral e o centralizado em Python que você pode tem sobre este tópico.

Para alguns antecedentes, a discussão ocorreu em torno de uma pergunta específica sobre o stackoverflow , mas achei mais apropriado passar a discussão para aqui como uma questão para evitar sobrecarregar a resposta sobre SO com essa tangente, uma vez que ela se desviou do tópico. a pergunta original. Você pode olhar para essa pergunta e suas respostas para os exemplos de trechos de código que deram início à discussão.

Aqui está um exemplo simplificado:

join_type = "explicit"
a = "%s line joining" \
    % (join_type)
# versus
join_type = "implicit"
b = ("%s line joining"
     % (join_type))

As perguntas sobre melhores práticas estão fora do tópico para revisão de código. Migrei sua pergunta para um local melhor.
Winston Ewert

11
@WinstonEwert antes de postar, dei uma boa olhada nas Perguntas frequentes sobre CodeReview e Perguntas frequentes sobre programadores e escolhi o CodeReview porque explicitamente diz que os tipos de perguntas a serem feitas incluem "Melhores práticas e uso de padrões de design em seu código". Incluí uma versão simplificada do código em questão. Então, como é isso fora do tópico?
Aculich

@WinstonEwert Eu publiquei uma pergunta no Meta sobre como esclarecer as Perguntas frequentes do CodeReview se você quiser comentar sobre isso por lá.
Aculich

Respostas:


8

Existe um documento de estilo de codificação chamado PEP8. É contra o uso de \<NL>onde quer que parênteses possam ser usados.

A maneira preferida de quebrar linhas longas é usando a continuação implícita de linhas do Python entre parênteses, colchetes e chaves. As linhas longas podem ser divididas em várias linhas envolvendo expressões entre parênteses. Eles devem ser usados ​​preferencialmente ao usar uma barra invertida para a continuação da linha. Certifique-se de recuar a linha continuada adequadamente. O local preferido para contornar um operador binário é depois do operador, não antes dele.

Texto completo: http://www.python.org/dev/peps/pep-0008/ (seção Layout de código)

Não é obrigatório, mas define boas práticas aceitáveis ​​que são especialmente úteis se você tiver vários committers Python em sua equipe.


1

Costumo usar a junção implícita de linhas porque acho mais legível e o suporte dos editores geralmente é melhor em relação à indentação e destaque de toda a expressão graças à correspondência entre parênteses.


0

Atualmente, eu preferiria

join_type = "kiding"
a = "%s line joining" % (join_type)

B-))

.

Costumo preferir a junção de linhas explícitas porque não gosto da confusão de parênteses no final das expressões.
Mas eu gosto de Implicit Lines Joining para reduzir a largura ocupada pela escrita de uma string.
Então, em alguns casos, tenho vergonha de não misturar as duas maneiras


11
Brincadeiras à parte, eu não gosto de união explícita porque requer mais digitação e é difícil manter todas as barras invertidas alinhadas quando o código é editado.
22613 martineau

aparentemente @eyquem nunca escreveu qualquer LISP ...
cowbert
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.