O limite de 80 caracteres ainda é relevante em tempos de monitores widescreen? [fechadas]

em um monitor widescreen, é possível ver facilmente mais de 80 caracteres por vez, sem barras de rolagem. até linus torvalds vê o limite de 80 caracteres como desatualizado .

então, o limite de 80 caracteres ainda é relevante em tempos de monitores widescreen?

Ainda existem vários motivos para aderir a um limite de 80 caracteres (ou, um limite de 74 caracteres é ainda melhor; ele permite que o código permaneça com menos de 80 colunas, mesmo quando marcadores diff e citações de email forem adicionadas, se você revisar o código em mailing lists).

Mesmo na era dos monitores widescreen, eu gosto de ter várias janelas abertas lado a lado, mostrando diferentes partes do código. Por exemplo, eu normalmente tenho um navegador da Web e e-mail abertos em uma tela e dois arquivos e um terminal abertos lado a lado em um segundo monitor. Se você possui linhas com mais de 80 colunas, é necessário lidar com o editor que as agrupa (o que é feio e dificulta a navegação pelo código) ou alarga as janelas para que não se encaixe na tela em uma vez.

Mesmo que você não edite normalmente dessa maneira, se alguma vez usar uma ferramenta de comparação lado a lado, apreciará arquivos com comprimentos de linha razoáveis, o que facilitará sua visualização.

Há também um problema de densidade de código. Eu gosto de ter muito contexto ao ler código. É muito, muito mais rápido olhar para cima e para baixo em uma janela do que para rolar. Se você possui linhas muito longas, também costuma ter linhas que variam muito em comprimento, levando a muito espaço desperdiçado na tela e podendo ajustar menos código na tela em um determinado momento geral.

E, finalmente, se você tiver linhas muito longas, isso geralmente significa que você tem linhas muito complicadas, indendações profundas ou que possui identificadores muito longos. Tudo isso pode ser um problema. Linhas complicadas provavelmente estão fazendo muito; se você pode dividi-lo em várias linhas mais simples, provavelmente deveria. Recuo profundo significa que você provavelmente está aninhando muitos loops e condicionais, o que pode tornar seu código confuso; considerando a refatoração em várias funções. E se seus identificadores forem muito longos, pode dificultar a leitura do seu código. As pessoas geralmente reconhecem as palavras como unidades individuais; eles não lêem todos os caracteres, um por um, mas observam a forma geral da palavra. Identificadores longos são mais difíceis de distinguir dessa maneira e, geralmente, se forem longos, contêm informações redundantes ou repetitivas.

Agora, embora ainda seja uma boa prática manter o código abaixo de 80 colunas, essa não é uma daquelas regras que precisam ser seguidas religiosamente, contorcendo-se para fazer com que algumas linhas se ajustem quando não o fazem. Sugiro que você tente manter todo o seu código em 80 colunas, mas quando ele simplesmente não se encaixar, não se preocupe muito.

Se eu mantiver minhas linhas com menos de 100 caracteres, posso ter duas janelas do editor lado a lado em um monitor widescreen. É muito útil ter o arquivo de cabeçalho da classe e a implementação visíveis ao mesmo tempo ou ter um código de um lado que chama o código do outro. E, se eu mantiver as linhas curtas, não preciso de uma barra de rolagem horizontal nas janelas do editor, o que me dará mais espaço vertical.

80 caracteres podem estar desatualizados, mas há algum mérito em manter as coisas dentro da razão.

Acho que o monitor não tem nada a ver com isso - pelo menos não mais.

Se você não pode codificar uma linha com 80 caracteres, provavelmente é um sinal de código incorreto. Expressões muito complexas. Recuo muito profundo. etc. Você deve parar e repensar o que está fazendo.

Mas se você tiver certeza de que o código exigiu mais de 80 linhas, vá em frente e faça-o. Eu acho que é melhor ter um código que ultrapasse os 80 caracteres do que adicionar alterações idiomáticas apenas para torná-lo menor.

Eu pessoalmente odeio esse tipo de coisa:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

Em vez de simplesmente:

ret = my_function(parameter1, parameter2, parameter3, parameter4);

Para codificação?

Certamente sim. Um ser humano normal não consegue ler muito bem. Com poucas colunas, você move menos os olhos, concentra-se melhor e atrasa o cansaço. É um ganho mínimo, mas importante.

Sim, existem razões para limitar o comprimento da linha de código:

1. Embora nossas telas tenham se ampliado, às vezes você precisa imprimir seu código. Se apenas por esse motivo .
2. Os espectadores com dificuldade exibem linhas com uma divisão vertical - isso se torna mais difícil se as linhas tiverem o tamanho que uma tela ampla permitir.

Dito isto, 80 é um pouco demais. Mas, ainda assim, algumas limitações provavelmente são uma boa idéia como princípio de design.

Eu diria que longas filas extras não devem ser proibidas, porque ocasionalmente são necessárias. Mas se a maioria das funções estiver visível apenas em uma tela de 30 ", o código terá alguns problemas.

É arbitrário, mas há um limite não arbitrário para o que é fácil de ler. Acho que colunas de texto super amplas são muito difíceis de digitalizar e ler, independentemente de serem códigos ou prosa. Além disso, como muitas outras respostas apontaram, não é como se esse código fosse a única coisa na tela. É ótimo ter duas ou mais janelas de código ativadas ao mesmo tempo e ajustá-las em um monitor de tela ampla.

Provavelmente não é relevante escolher exatamente um limite de 80 caracteres; o que mudaria se o limite fosse 85, por exemplo?

É verdade que os monitores usados ​​hoje em dia têm resoluções mais altas, mas em um editor de texto / IDE, nem todo o espaço é ocupado na exibição de texto; no editor eu uso mostra no lado esquerdo a lista dos arquivos incluídos no projeto.

A resolução usada em um netbook ou notebook não é a mesma usada em monitores; provavelmente faz sentido usar um limite de caracteres que não crie "problemas" para ninguém.

Realmente depende do ambiente de desenvolvimento.

Por exemplo, em uma grande corporação com milhares de desenvolvedores, provavelmente há centenas de pessoas que, ao longo da vida de um produto, terão que examinar uma parte de seu código. Com tantas pessoas, é provável que existam alguns que, por qualquer motivo (hardware mais antigo, netbooks, etc.) estão operando a 800x600 ou menos. Há algum valor em acomodá-los.

Na minha empresa de 25 pessoas, porém, eu digo que estrague tudo. Todos nós estamos usando monitores modernos duplos com a resolução máxima - 120-140 ou mais é a orientação informal.

Ter algum limite certamente faz sentido. Mas o limite de 80 caracteres é muito restritivo. Eu prefiro algo como limite de 96 caracteres. É largo o suficiente para a maior parte do código com o qual tenho de lidar e é estreito o suficiente para que dois arquivos possam ser colocados lado a lado para diferenciar (em uma tela ampla).

Acredito que a legibilidade do código supera todas as outras preocupações. E com 96 caracteres por código de linha pode ser muito mais legível do que com 80.

Não acredito que a maioria das pessoas defina seus terminais com 80 caracteres de largura, não que as impressoras tenham que quebrar linhas com mais de 80 caracteres. Não é um limite difícil, como costumava ser no passado (distante). Você pode definir facilmente o terminal e a largura da impressora para 100 caracteres.

Não, não é mais relevante:

• A maioria das fontes usadas em aplicativos e na Web não tem largura fixa. Em outras palavras, 80 caracteres! = 80 caracteres.
• Como você disse, as larguras da tela mudaram - 80 caracteres não são um limite sensato.

80 caracteres era realmente uma diretriz para fontes de largura fixa em um ambiente de console.

Claro, se você ainda estiver usando uma fonte de largura fixa em um ambiente de console ... então, com certeza, 80 caracteres são sensatos :)

Se você usar um editor em uma GUI, os 80 caracteres por linha são irrelevantes, pois a maioria dos editores decentes - por exemplo, o Notepad ++ - possui um botão para alternar a quebra de linha. Com isso, não deve ser um problema, mesmo ao visualizar o código em uma janela fina.