Por que o PEP-8 especifica um comprimento máximo de linha de 79 caracteres? [fechadas]

235

Por que neste milênio o Python PEP-8 deve especificar um comprimento máximo de linha de 79 caracteres?

Praticamente todo editor de código sob o sol pode lidar com linhas mais longas. O que fazer com o agrupamento deve ser a escolha do consumidor do conteúdo, não a responsabilidade do criador do conteúdo.

Existem (legitimamente) boas razões para aderir a 79 caracteres nesta era?

python pep8

— pcorcoran
fonte

73

A resposta para sua pergunta está no PEP-8.

— Cdcely

29

Comprimentos de linha mais curtos aumentam a produtividade aumentando seu KLOC. : p

— Alex

26

O limite de 79 caracteres está completamente desatualizado. Qualquer base de código modestamente complexa mostra como torna o código muito mais difícil de ler. Por exemplo, github.com/openstack/nova/blob/master/nova/network/manager.py

— Jonathan

6

@Jonathan: parece bom para mim ...

— nperson325681 /

9

Vocês não usam ferramentas de comparação lado a lado?

— endolith

129

Grande parte do valor do PEP-8 é impedir que as pessoas discutam sobre regras de formatação inconseqüentes e continuar escrevendo códigos bons e consistentemente formatados. Claro, ninguém realmente acha que 79 é o ideal, mas não há ganho óbvio em alterá-lo para 99 ou 119 ou seja qual for o comprimento de sua linha preferida. Acho que as opções são as seguintes: siga a regra e encontre uma causa que valha a pena lutar, ou forneça alguns dados que demonstrem como a legibilidade e a produtividade variam com o comprimento da linha. O último seria extremamente interessante, e eu teria uma boa chance de mudar a mente das pessoas.

28

A maioria dos estudos de leitura é feita em polegadas e não em caracteres por linha. A regra de 66 caracteres é baseada em estudos feitos para a leitura de jornais. Estudos recentes mostraram que, ao ler artigos on-line, a velocidade de leitura aumenta até cerca de 120 caracteres por linha (10 polegadas no tamanho 12), sem perda de compreensão.

— Pace

7

Na verdade, todo mundo que lê esse tópico pensa que 79 caracteres são ótimos. Por isso foi adicionado ao PEP8! Esta resposta está realmente errada. Este é o correto

— erikbwork

6

Eu pensei que a pergunta é sobre por que 79 é melhor que 80 ou 78

— n611x007

157

there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is Isso é tão errado de muitas maneiras. Enrole uma linha com 40 caracteres e me diga como é legível. Obviamente, menos empacotamento = mais legibilidade, desde que você tenha espaço na tela, o que em 2015, você tem. A embalagem afeta a legibilidade. A legibilidade afeta a capacidade de manutenção. A manutenção afeta a qualidade. E a qualidade é afetada se você optar por 80 caracteres. Ponto final.

— 9136 Jonathan

6

Discutir sobre legibilidade com qualquer coisa que não seja código é inútil, pois esses estudos assumem a execução de texto. O código parece completamente diferente com o comprimento da linha (caractere) diferente a cada linha. E mesmo se você escrever até o final da linha, o recuo altera a quantidade de caracteres por linha.

— Corvince #

111

Manter seu código legível por humanos e não apenas legível por máquina. Muitos dispositivos ainda podem mostrar apenas 80 caracteres por vez. Além disso, facilita a tarefa multitarefa de pessoas com telas maiores, pois é possível configurar várias janelas para ficar lado a lado.

A legibilidade também é um dos motivos para o recuo forçado da linha.

— Justin Bozonier
fonte

58

Sim, concedida. Mas por que 79? Por que não 100 ou 120? Manter as coisas legíveis funciona nos dois sentidos. Muita leitura de código de cima para baixo também é difícil de entender.

— pcorcoran 18/09/08

17

É verdade que muitos dispositivos podem mostrar apenas 80 caracteres. Quantos deles não podem realizar quebra automática?

— Jim Jim

39

Além disso, é preferível não ter quebra de código. Do ponto de vista da experiência do usuário, é inaceitável para a maioria.

— Justin Bozonier 18/09/08

8

Existem alguns sistemas operacionais como o MVS que não podem manipular linhas com mais de 72 caracteres. O PEP-8 não vai ajudar aqui. Definir um limite arbitrário de 79 caracteres não faz sentido, pois a qualidade dos caracteres por linha depende do editor, monitor, preferências pessoais do usuário e assim por diante.

— precisa saber é o seguinte

96

79 caracteres também fazem com que os programadores usem nomes mais curtos de variáveis e funções mais enigmáticas para ajustar tudo. Isso é ruim para a legibilidade.

— Gert Steyn

46

Eu sou um programador que precisa lidar com muito código diariamente. Código aberto e o que foi desenvolvido internamente.

Como programador, acho útil abrir muitos arquivos de origem de uma só vez e organizar frequentemente minha área de trabalho no monitor (widescreen) para que dois arquivos de origem estejam lado a lado. Eu posso estar programando em ambos, ou apenas lendo um e programando no outro.

Acho insatisfatório e frustrante quando um desses arquivos de origem tem mais de 120 caracteres de largura, porque significa que não consigo encaixar confortavelmente uma linha de código em uma linha da tela. Incomoda a formatação para quebra de linha.

Eu digo '120' porque esse é o nível em que eu ficaria irritado com o código ser maior do que. Depois de tantos caracteres, você deve dividir as linhas para facilitar a leitura, sem falar nos padrões de codificação.

Eu escrevo código com 80 colunas em mente. Isso é apenas para que, quando eu vazar sobre esse limite, não seja uma coisa tão ruim.

— Jerub
fonte

11

"Eu escrevo código com 80 colunas em mente. Isso é apenas para que quando eu vazar sobre esse limite, não seja uma coisa tão ruim." O mesmo para mim.

— precisa saber é o seguinte

4

10 anos depois: isso não depende apenas de como você configura a quebra de linha. A quebra de linha pode ser tão inteligente ou estúpida quanto você desejar. Se é desconfortável de ler, é apenas uma falha do seu editor.

— David Mulder

2

Eu codigo para 120 caracteres, mas ocasionalmente mais quando é adequado à legibilidade. Formatos pretos a 120 se você quiser. O PEP-8 também diz "não há problema em aumentar o limite de comprimento da linha em até 99 caracteres", mas as pessoas parecem suprimir essas informações a maior parte do tempo. Quase ninguém usa terminais com 80 metros de largura. As mensagens de log nunca têm 80 de largura.

— 28419 NeilG

37

Acredito que aqueles que estudam tipografia diriam que 66 caracteres por linha devem ter a largura mais legível para o comprimento. Mesmo assim, se você precisar depurar uma máquina remotamente em uma sessão ssh, a maioria dos terminais usará o padrão de 80 caracteres, 79 apenas se encaixa, tentar trabalhar com algo mais amplo se torna uma dor real nesse caso. Você também ficaria surpreso com o número de desenvolvedores que usam o vim + screen como um ambiente do dia a dia.

— Sean O Donnell
fonte

<flame> Emacs FTW! </flame> +1, no entanto. Eu acho que o limite de 79 vem dos primeiros dias do UNIX (e possivelmente do MULTICS) que tinha terminais de caracteres 80x25.

— Joe D

10

Meus ambientes ssh + screen + vim não têm problemas para exibir longas filas.

— precisa saber é o seguinte

54

"66 caracteres por linha devem ter a largura mais legível para o comprimento" Suponho que devemos escrever código em 2 ou 3 colunas, pois é assim que os jornais são organizados.

— precisa

23

@ mehaase: sua observação sarcástica está bem próxima da verdade: editores decentes podem dividir painéis e mostrar coisas diferentes lado a lado (a partir de arquivos iguais ou diferentes). Coincidentemente, este é geralmente só é viável quando o código tem um padrão de comprimento linha ...

— nperson325681

2

@ mehaase: Parece incrível, na verdade. Eu não estou brincando.

— Teekin

19

A impressão de uma fonte monoespaçada nos tamanhos padrão é (em papel A4) 80 colunas por 66 linhas.

— Josh
fonte

11

Eu aceito esse padrão; é válido. Mas quem imprime mais o código? Além disso, quem imprime o código de um ambiente que é intolerante ao dimensionamento ou a outras opções de formatação? Quando foi a última vez que alguém que você conhece ficou perplexo com a incapacidade de renderizar uma linha de 100 caracteres?

— pcorcoran 18/09/08

3

Por que as pessoas imprimem código em 2012? Isso me lembra de ir a uma conferência de tecnologia e receber uma bolsa e uma pasta impressa cheia de apresentações. São as pessoas do século XXI: envie-me os slides por e-mail, caso contrário a bolsa e a pasta vão direto para o aterro.

— precisa

2

então por que 80-1 é melhor que 80-0 ou 80-2?

— N611x007

11

"em tamanhos padrão" Você diz? Conte-me mais sobre esses tamanhos padrão universalmente aceitos.

— precisa saber é o seguinte

15

Sim, vamos priorizar a aparência do código no papel impresso acima de tudo.

— 9136 Jonathan

8

Eis por que gosto dos 80 caracteres: no trabalho, uso o Vim e trabalho em dois arquivos por vez em um monitor rodando em, penso eu, 1680x1040 (nunca me lembro). Se as linhas continuarem, eu tenho problemas para ler os arquivos, mesmo quando estou usando quebra de linha. Escusado será dizer que eu odeio lidar com o código de outras pessoas, pois elas adoram longas filas.

você não usa o vim para javascript / html também?

— Elad silver

2

@eladsilver Não consigo descobrir se é uma piada? :-D

— Steven Church

desculpe, não muito profundo com o vim, obviamente, se você trabalha na web, também o usa para html / js e esses tipos nunca vêm com um limite de 80 caracteres, pois os desenvolvedores de front-end não conhecem o pep8, tornando o python limite de 80 caracteres não resolverá seu problema se você usar mais do que somente python. Então, o que estou perguntando é como você lida com outras linguagens de codificação?

— elad silver

Eu trabalho no Vim com 120 linhas de caracteres. Eu uso: diffthis com divisão horizontal. Se você só pode caber 160 caracteres em 1680 pixels, deverá ter um tamanho de fonte grande.

— 28419 NeilG

4

Como o espaço em branco tem significado semântico no Python, alguns métodos de quebra de linha podem produzir resultados incorretos ou ambíguos; portanto, é necessário haver um limite para evitar essas situações. Um comprimento de linha de 80 caracteres é padrão desde que usamos teletipos, portanto 79 caracteres parecem ser uma escolha bastante segura.

— Chris Upchurch
fonte

4

Existem dois tipos diferentes de quebra de linha. Há quebra automática, onde as linhas são divididas com novas linhas, e quebra automática, onde são exibidas apenas com quebras, mas permanecem fisicamente uma única linha. Não vejo nenhum problema com o último.

— Jim Jim

4

A maioria dos editores de Python não faz quebra automática de linha porque produz código ambíguo e difícil de ler em uma linguagem em que espaço em branco e recuo são importantes.

— Chris Upchurch

4

Não produz código ambíguo ou de difícil leitura, desde que o empacotamento seja identificado visualmente de alguma forma. Kate faz isso e funciona bem. Se um editor não lidar com isso, é um motivo para registrar um bug no editor, não um motivo para impor um estilo de codificação que evite o erro.

— Jim Jim

5

Mesmo se indicado visualmente, ainda torna o código muito mais difícil de ler, e é por isso que os editores Python geralmente não o suportam.

— Chris Upchurch

Você realmente tentou por um longo período de tempo? Eu tenho. Não torna o código mais difícil de ler na minha experiência. Você pode fazer backup da alegação de que é por isso que os editores Python não incluem o recurso? Eu nunca ouvi essa afirmação antes.

— Jim Jim

1

Eu concordo com Justin. Para elaborar, linhas de código excessivamente longas são mais difíceis de serem lidas por humanos e algumas pessoas podem ter larguras de console que acomodam apenas 80 caracteres por linha.

A recomendação de estilo existe para garantir que o código que você escreve possa ser lido pelo maior número possível de pessoas em tantas plataformas quanto possível e o mais confortável possível.

— Somente leitura
fonte

10

Este é um argumento preguiçoso. Nem sempre é o caso de 80 linhas prejudicar a legibilidade. Uma rápida olhada em qualquer base de código Python modestamente complexa que envolva 80 linhas na verdade demonstra o oposto - que agrupar chamadas de função de linha única para várias linhas torna mais difícil seguir o WTF.

— Jonathan

0

porque se você empurrá-lo para além da coluna 80, significa que você está escrevendo uma linha de código muito longa e complexa que faz muito (e por isso deve refatorar) ou que você recuou muito (e por isso deve refatorar).

— Stefano Borini
fonte

90

-1, não acho que você possa dizer categoricamente que qualquer linha além do limite de 80 caracteres requer um refator. Os métodos de classe já são recuados duas vezes, adicione outro recuo para um "se" etc., e uma simples compreensão de lista, e é muito fácil cruzar o limite de 80 caracteres.

42

Sem mencionar que, se você nomear símbolos de forma que eles possam ser legíveis por humanos, por exemplo, "users_directed_graph" em vez de "usr_dir_gph", mesmo uma simples expressão irá consumir alguns caracteres por linha.

— Mark E. Haase

8

Eu sempre achei em Python que, se eu exceder 80 caracteres, é aconselhável parar e pensar no motivo disso. Geralmente, a má decisão do projeto é falha.

— Mike Vella

3

Essa também foi minha experiência. Ele também aborda nomes de variáveis mais longos, como o @mehaase aponta, mas acho que isso é um benefício. As combinações disponíveis de três palavras consecutivas (no caso de "users_directed_graph") diminuem o número de componentes que cabem razoavelmente em um único espaço para nome. Considero que o código mais antigo que escrevi, onde muitos nomes de variáveis longas semelhantes estão no mesmo espaço de nomes, é mais difícil de ler e geralmente melhor para refatorar.

— TimClifford

4

Em uma linguagem que exige recuos para cada mudança de escopo, dizer que 80 linhas de caracteres equivale a complexidade é um argumento excessivamente simplista. Às vezes, 80 caracteres é exatamente o que é necessário para chamar uma função. Os IDE / editores modernos de outros idiomas são inteligentes o suficiente para reconhecer isso e podem discernir quando quebrar, em vez de colocar restrições gerais sobre tudo que prejudica a legibilidade geral.

— Jonathan