Estudos sobre largura ideal de código?


131

Se você habilitar a opção "Exibir margem direita" no seu IDE de sua escolha, é provável que o padrão seja 80 caracteres. Costumo alterá-lo para 120 por nenhuma outra razão que não fosse o padrão em uma empresa que eu estava há alguns anos atrás, e nenhuma outra empresa me disse para fazê-lo de maneira diferente.

Minha pergunta é: existem estudos que realmente mostrem 80 caracteres com a largura máxima ideal para a legibilidade do código ou esse valor é apenas "é assim que sempre foi" e ninguém sabe realmente por que é assim? E a largura de uma linha de código deve fazer parte do seu padrão de codificação?


1
Embora eu não conheça nenhum estudo, você encontrará muitas opiniões como respostas a esta pergunta: * Existe uma razão válida para impor uma largura máxima de 80 caracteres em um arquivo de código hoje em dia?
23117 Adam Bellaire

3
não há estudos que conheço, mas você pode achar interessante olhar para diferentes projetos de códigos de codificação. Por exemplo, o Google tem 80 caracteres. ( code.google.com/p/google-styleguide ) onde, como o WebKit (da Apple), não há limite AFAIK ( webkit.org/coding/coding-style.html ). O Mozilla parece ter 80 anos ( developer.mozilla.org/En/Mozilla_Coding_Style_Guide#Line_length )
gman

É o mesmo que a razão pela qual escrevemos "Burocrata" do jeito que fazemos. Porque há muito tempo alguém definiu um padrão por uma razão que pode ou não ter sentido na época. Para ortografia, era um fascínio duvidoso pelo latim, para códigos do tamanho de um cartão perfurado de papel. Então, um método foi rotulado como "correto". E pequenos burocratas vêm aplicando os padrões desde então.
Tuntable 12/08/19

Respostas:


116

Na verdade, a coisa de 80 colunas precede muito o DOS. Ele vem de cartões perfurados, que eram dispositivos de 80 colunas.

E para responder à pergunta do OP, um "estudo" está em andamento há cerca de 600 anos - o livro impresso. Eles evoluíram ao longo dos séculos, com a legibilidade em mente, para a posição em que estamos agora, onde o comprimento médio da linha do texto é de cerca de 60 caracteres. Portanto, para facilitar a leitura, procure margens mais estreitas.


85
Realmente não acredito que você possa comparar a leitura de linguagem natural com a leitura de uma linguagem de programação em termos de usabilidade.
Frug

25
@ Frug - na verdade, você provavelmente pode. A razão para a largura de 65 caracteres não é porque linhas maiores não podem ser lidas, mas é um arco muito apertado quando o olho se move para a próxima linha. Você pode contornar isso aumentando a altura da linha, mas isso dificulta o uso do espaçamento entre blocos para transmitir significado, portanto é provavelmente algo a ser evitado em um IDE.
Jimmy Breck-McKye

32
@ Jim - Minha linguagem natural não contém palavras com 30 caracteres (não que eu use de qualquer maneira) e analisa completamente diferente de uma linguagem de programação. Geralmente, você pode agrupar uma linha de código como separada do restante, seja uma condicional longa ou uma combinação de métodos e classes longos. Combine isso com recuo e a comparação entre as duas línguas se torna absurda. Não tenho dúvida de que alguém que estuda cientificamente a legibilidade e o comprimento da linha se oporia à sua lavagem diante das diferenças.
Frug

10
@ Frug - Eu realmente não vejo como suas objeções se envolvem com nenhuma das reivindicações que fiz, mas posso ver que o recuo quebra o modelo que estou propondo. Não me chame de 'Jim', no entanto.
Jimmy Breck-McKye

17
Normalmente, um livro é colocado muito mais próximo dos olhos do que um monitor, o que significa que menos caracteres por linha são permitidos para que o leitor possa ler o livro sem precisar esticar o pescoço. Uma tela geralmente não é colocada à distância de um livro, o que significa que mais caracteres por linha podem ser usados, mantendo-se dentro dos limites do ângulo máximo dos olhos. Além disso, o código não é lido tanto quanto é lido, tornando essa largura menos importante. I (YMMV) pode facilmente seguir linhas com 120 caracteres de código na tela do meu laptop, mas isso é muito ampla para 2 emacs buffers no meu 15" laptop, infelizmente.
Obscaenvs

104

Tenha piedade dos programadores que precisam manter seu software posteriormente e atenha-se a um limite de 80 caracteres.

Razões para preferir 80:

  • Legível com uma fonte maior em laptops

  • Deixa espaço para colocar duas versões lado a lado para comparação

  • Deixa espaço para visualizações de navegação no IDE

  • Imprime sem quebrar arbitrariamente as linhas (também se aplica a email, páginas da Web, ...)

  • Limita a complexidade em uma linha

  • Limita a indentação que, por sua vez, limita a complexidade de métodos / funções

Sim, deve fazer parte do padrão de codificação.


10
Esses são ótimos motivos para manter a largura da linha com 80 caracteres ou menos. Estou realmente surpreso (decepcionado) por sua resposta, que é claramente pensada e correta, não conseguiu mais pontos. A esta lista, acrescentaria: (1) a rolagem horizontal não é divertida. (2) Você pode aumentar bastante a densidade do código em que está trabalhando visualizando esse código em várias colunas. Uma grande quantidade de imóveis é desperdiçada quando você tem algumas linhas que se estendem para a direita quando a maioria das outras linhas não.
Donnie Cameron

4
ok, mas o que acontece quando há um bloco de código com poucos recuos? isso aconteceu comigo e 80 personagens não são divertidos.
EKanadily

14
Limits the complexity in one lineNão sei por que espalhar a complexidade por várias linhas é melhor. Apenas empurra mais para sua pilha mental.
9134 Jonathan

4
Este é um tópico muito antigo. mas você ainda concorda agora que muitos desenvolvedores usam monitores de 27 polegadas :-). Quero dizer, se a visão é um problema, uma tela maior pode ajudar. Há 8 anos, ainda estávamos trabalhando em monitores de 17 ou 20 polegadas e alguns em resoluções 4: 3.
Mathijs Segers

1
@MathijsSegers, independentemente do tamanho ou resolução do monitor, ainda é mais confortável manter o texto dentro dos 30 graus médios do seu campo de visão. Ao trabalhar com várias janelas abertas em monitores lado a lado, costumo virar a cabeça para olhar de um para o outro. Uma pessoa não deve ter que virar a cabeça ou girar os olhos até o fim para ler de um extremo a outro da linha. Uma rotação tão rápida dos olhos ou da cabeça provavelmente causaria vertigem se fosse feita o dia todo.
21318

41

Não tenho estudos, mas relatarei minha experiência.

Acho que a rolagem horizontal é entediante ao lidar com texto. Eu olho para o ambiente em que o código será usado e defino os padrões de largura com base nesse contexto.

Por exemplo, quando trabalhei no Emacs no XWindows, funcionou bem ter duas janelas do Emacs lado a lado o tempo todo. Isso os limitou a 80 caracteres, então esse era meu comprimento máximo de linha.

Em um ponto, trabalhei no Visual Studio em uma tela de 1920x1200. Eu o manteria maximizado, com todas as janelas de ferramentas ancoradas de um lado. Havia espaço suficiente para duas janelas do editor lado a lado com cerca de 100 caracteres.

Também acho que as linhas mais longas vêm de chamadas de método com longas listas de parâmetros . Às vezes, isso é um cheiro de código : talvez o método deva ser refatorado .

Se você e seus co-programadores têm telas de alta resolução e visão nítida, use uma fonte pequena e linhas longas. Por outro lado, você pode precisar de linhas curtas.


1
mais um para os "olhos afiados", porque realmente foi o que aconteceu comigo.
EKanadily

26

Eu normalmente uso 120-150, a menos que a empresa descreva o contrário. No entanto, depende também do tipo de código:

  • Eu (quase) nunca uso várias instruções em uma linha
  • Só uso linhas longas (> 12) apenas se as linhas que parecem semelhantes puderem ser alinhadas e não quebradas.
  • Eu sempre uso espaços / parênteses suficientes, etc.
  • Prefiro nomes de variáveis ​​mais longos do que nomes mais curtos

Até alguns anos atrás, eu me limitava a 100, mas agora os widescreens são normalmente usados ​​e os monitores de alta resolução 120 podem ser vistos em laptops (que eu mal uso).

Comparar uma tela a um livro não é muito bom porque um livro tem mais espaço vertical e uma tela tem mais espaço horizontal. Eu sempre tento manter uma função no máximo. uma tela visível por muito tempo.


6
Como 120-150 caracteres por linha funcionam com várias janelas abertas lado a lado? Você mantém muitas janelas do editor de código abertas lado a lado? - No meu monitor de 30 '', posso ter 3 janelas lado a lado, se limitar minhas linhas a 97 caracteres / linha.
KajMagnus

1
Eu codifico em uma tela grande e também gosto de quantidades maiores. Eu aponto para 110-130. Um dos meus principais objetivos é a legibilidade e dividir as declarações em duas ou três linhas é, às vezes, menos legível na minha opinião. Às vezes, também irei para 500-1000 para ocultar lixo eletrônico que não quero ver, como alguns comentários, código desabilitado e alguns valores codificados. Eu acho que depende do programador também. Se a maioria dos codificadores operar com 80, é melhor procurar isso ao trabalhar com código compartilhado.
Sunsetquest

10

Talvez os 80 caracteres também sejam um bom ponto para evitar essas cadeias de getter ruins:

object.getFoo().getBar().getFooBar().get ...

se você o limitar a 80 caracteres, talvez alguém localize essas variáveis ​​e faça uma verificação nula, etc., mas talvez a maioria dos programadores os deixe agrupar na próxima linha. Eu não sei

Além disso, 80 caracteres são ótimos como o azul estrelado mencionado. Isso deve definir definitivamente os padrões de codificação.


5
Para sua informação, encadeamento excessivo de métodos como esse é conhecido como anti-padrão de destruição de trem .
Dennis

4

Desconsiderando as restrições de hardware e quaisquer diferenças na forma como lemos código versus linguagem natural, vejo três razões principais para limitar as linhas a cerca de 80 caracteres.

  1. Os globos oculares humanos são redondos, não muito estreitos e largos, e a maior parte de sua resolução está no meio . Ao ler por horas seguidas, é muito mais confortável varrer os olhos em arcos curtos, usando uma barra de rolagem, conforme necessário. Não conheço um estudo formal específico para a legibilidade do código, mas, pelas minhas próprias observações, com o monitor a dois metros de distância, com texto dimensionado em uma fonte monoespaçada de 10 pontos, 100 caracteres ocupam cerca de 1/3 do meu campo horizontal de visão, ou em torno de 60 graus ( fora dos 30 graus ou mais, onde está a resolução de todos os nossos olhos ).
  2. A maioria das pessoas usa um monitor grande no trabalho para poder ver várias coisas sem clicar para frente e para trás, e não para ver uma coisa realmente grande.
  3. As linhas mais curtas contêm menos complexidade, o que, com sorte, força o desenvolvedor a dividir o código em unidades mais digeríveis.

3

Lembro-me claramente de ter lido em algum lugar (acho que estava na documentação do Agile ) que, para uma legibilidade ideal, a largura de um documento deve ter cerca de dois alfabetos ou 60 a 70 caracteres. Acho que a largura da linha dos terminais antigos veio em parte dessa antiga regra tipográfica.


3

A opção de margem direita tem como objetivo mostrar a largura da página, se você deseja imprimir o código, e postou anteriormente que estava definido como 80, porque é isso que historicamente era o comprimento da linha antes da GUI desde o início. cartões.

Recentemente, vi uma recomendação em algum blog (não lembro qual blog) para aumentar o tamanho da fonte do IDE para melhorar a qualidade do código, a lógica por trás disso é que, se houver menos código na tela, você escreverá linhas mais curtas e funções shouter.

Na minha opinião, linhas mais curtas facilitam a leitura do código e a depuração, por isso tento manter as linhas curtas, se você precisar definir um limite para escrever um código melhor e escolher o que funciona melhor para você - também se você for mais produtivo com linhas mais longas podem aumentar o tamanho e o código da página apenas em telas amplas.


1

Como algumas pessoas apontaram em outras respostas, o motivo do limite de 80 caracteres é parcialmente histórico (cartões perfurados, telas pequenas, impressoras etc.) e parcialmente biológico (para rastrear em que linha você está, geralmente é bom poder ver todo o texto. sem precisar virar a cabeça).

Dito isto, lembre-se de que ainda somos humanos e criamos ferramentas para resolver nossas próprias limitações. Proponho que você ignore todo o debate sobre a limitação de caracteres e apenas escreva coisas que façam sentido, independentemente do tamanho, e use um IDE ou editor de texto que possa ajudá-lo a acompanhar as linhas corretamente. Usando o mesmo argumento para indentação no debate de guias versus espaços, bem como a largura das indentações, proponho que você use um marcador de indentação (geralmente a guia) e faça com que as pessoas configurem seus próprios IDE ou editores de texto para exibi-los. como acharem mais confortável para eles.

Aderir a um número fixo de caracteres por linha sempre tornará as coisas piores para todos, exceto para o público-alvo. Dito isto, se você nunca compartilhará o código, jamais; então não há realmente nenhuma razão para começar essa discussão. Se você deseja compartilhar o código, provavelmente deve permitir que as pessoas decidam o que querem por conta própria, em vez de forçar seus ideais (ou alguém) sobre eles.


0

Que eu saiba, o caractere 80 é usado como um padrão de codificação para manter a compatibilidade com os editores de linha de comando (a largura padrão do terminal geralmente é de 80 caracteres). Com IDEs modernos e resoluções de tela grandes, 80 caracteres provavelmente não são "ideais", mas para muitos desenvolvedores é essencial manter a legibilidade no terminal. Por esse motivo, não é provável que a largura de 80 caracteres seja substituída como padrão de fato para a largura do código em breve. E para responder à sua pergunta final, sim, a largura do código, bem como qualquer outra característica que afete a legibilidade do seu código, deve ser abordada nos seus padrões de codificação.

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.