Existe um motivo válido para impor uma largura máxima de 80 caracteres em um arquivo de código hoje em dia? [fechadas]


159

Seriamente. Em um monitor de 22 ", ele cobre apenas talvez um quarto da tela. Preciso de munição para reduzir essa regra.


Não estou dizendo que não deveria haver um limite; Só estou dizendo, 80 caracteres é muito pequeno.


Todas as respostas indicam o que eu queria adicionar. Para dar um exemplo da vida real - eu tenho um x61s, a resolução é 1024x768. Quando estou na estrada, não tenho meu monitor sofisticado. Abrir código no meu IDE é uma dor quando excede essa regra.
Até

possível duplicação de stackoverflow.com/questions/95575/…

Mesmo se você tiver um conjunto de 3 monitores. Esta não é uma razão para balançar a cabeça da direita para a esquerda e para trás. Para sempre. Ah-ha-ha. Na verdade, o olho se move mais rápido que a cabeça. Você conhece colunas em jornais? A razão da largura é a conveniência do olho / cabeça / homem.
Ivan Black

Respostas:


257

Penso que a prática de manter o código em 80 (ou 79) colunas foi criada originalmente para apoiar as pessoas que editam código em terminais burros de 80 colunas ou em impressões de 80 colunas. Esses requisitos desapareceram agora, mas ainda existem razões válidas para manter a regra das 80 colunas:

  • Para evitar quebra ao copiar código em email, páginas da web e livros.
  • Para exibir várias janelas de origem lado a lado ou usando um visualizador de diferenças lado a lado.
  • Para melhorar a legibilidade. O código restrito pode ser lido rapidamente, sem a necessidade de escanear os olhos de um lado para o outro.

Eu acho que o último ponto é o mais importante. Embora as telas tenham crescido em tamanho e resolução nos últimos anos, os olhos não .


7
Eles podem ter "desaparecido em grande parte", mas não inteiramente. Costumo trabalhar com duas configurações diferentes: 1) em uma janela ssh conectada a uma máquina remota. que tem 80 caracteres de largura por padrão. e 2) No Visual Studio, com dois painéis lado a lado para que eu possa ver o cabeçalho e o arquivo cpp ao mesmo tempo.
Enno

10
@steffenj: Na verdade, os livros tendem a disparar para cerca de 66 caracteres por linha (embora isso varia um pouco dependendo de outros parâmetros) porque as linhas mais longas fazer leitura make mais difícil. O comprimento máximo da linha de código pode ser discutido, mas 80 é conveniente por razões históricas e práticas.
Steve S

68
O problema é, forçando as pessoas a manter comprimentos de linha curto eles tendem a usar nomes menos meaningfull ..
Ian Ringrose

4
Acho as observações sobre legibilidade bastante interessantes, porque o que eu realmente odeio nos artigos / livros de programação impressos é que as linhas curtas usadas para os exemplos de código são extremamente difíceis de ler. Pode fazer muito sentido mover algo para uma nova linha, mas o agrupamento deve ocorrer logicamente, dissecando a expressão recursivamente, não porque o dispositivo de saída acidentalmente tenha atingido sua limitação. Acho que dispositivos que impõem restrições tão estreitas não são adequados para exibir código.
precisa

4
Penso que o problema com os aplicadores de 80 colunas é que eles esquecem que o código cresce na direção vertical. Você tem o mesmo problema, mas na direção vertical AND da parte superior deste código moderno parece horrível quando você precisa quebrar instruções únicas em duas ou às vezes até quatro ou cinco linhas. NÃO é mais legível. Com código moderno, quero dizer nomes de variáveis ​​descritivas e herança qualificada, espaços para nome, classes etc. Por favor, pare a coluna 80 sem sentido, use o bom senso. 120 é melhor, mas também não deve ser uma regra.
Larswad

79

A origem da formatação de texto de 80 colunas é anterior aos terminais de 80 colunas - o cartão perfurado da IBM remonta a 1928 ! Isso lembra a história (apócrifa) de que o medidor ferroviário dos EUA foi determinado pela largura das rodas da carruagem na Grã-Bretanha romana.

Às vezes, acho isso um pouco constrangedor, mas faz sentido ter um limite padrão, então são 80 colunas.

Aqui está o mesmo tópico abordado pelo Slashdot .

E aqui está uma declaração Fortran da velha escola:

Cartão perfurado FORTRAN


60

Atualmente, 80 caracteres é um limite ridículo. Divida suas linhas de código onde for adequado, não de acordo com qualquer limite arbitrário de caracteres.


O limite de caracteres não lhe diz onde você tem que dividir uma linha de código, mas quando
gztomas

Não não é. Se você escrever uma linha com mais de 80 caracteres, provavelmente já terá um problema na complexidade da expressão ou na estratégia de nomenclatura. Como outros já mencionaram, a legibilidade é uma das principais preocupações e a velocidade de leitura começa a cair acima de 60 a 66 caracteres (tipografia, com base na fisiologia humana).
sola

@sola Seu comentário aparece aqui com 98 caracteres e é uma densa linguagem natural e não nativa (para mim) de entender. Completamente legível. Um código com até 3-4 recuos, marcadores de sintaxe etc. é ainda mais fácil.
viyps 03/06

Eu acidentalmente votei esta resposta como voto negativo e não posso mais votá-la. :(
Andy

35

Você deve fazê-lo apenas para quem não possui um monitor widescreen de 22 polegadas. Pessoalmente, trabalho em um monitor de 17 polegadas 4: 3 e acho que é mais do que suficiente. No entanto, eu também tenho três desses monitores, então ainda tenho muito espaço de tela utilizável.

Não apenas isso, mas o olho humano realmente tem problemas para ler o texto se as linhas forem muito longas. É muito fácil se perder em qual linha você está. Os jornais têm 17 polegadas de diâmetro (ou algo assim), mas você não os vê escrevendo por toda a página, o mesmo vale para revistas e outros itens impressos. Na verdade, é mais fácil ler se você mantiver as colunas estreitas.


14
Não quando você adiciona recuo na mistura. Se você usar 4 espaços por recuo e estiver em algo como, namespace-> classe-> método-> if->, isso representa 1/5 do seu espaço queimado.
TraumaPony

Você sempre pode definir a regra em 80 caracteres a partir do recuo. Dessa forma, o olho pode segui-lo facilmente.
Vincent McNabb

Às vezes (mas nem sempre) eu gostaria que o .Net tivesse um namespace automático para que você não precisasse definir o namespace no arquivo. Isso mexe seriamente com o alinhamento do seu código. se você quiser namespaces aninhados, terá grandes problemas.
Kibbee

13
No entanto, ler em prosa não é o mesmo que ler código.
Atario 17/11/08

3
+1 para jornais, ótimo exemplo. @ Ontario, a leitura do código BOM é muito parecida com a leitura da prosa.
Todd Chaffee

23

Quando você tem uma sequência de instruções que se repetem com pequenas variações, pode ser mais fácil ver as semelhanças e diferenças se elas estiverem agrupadas em linhas para que as diferenças se alinhem verticalmente.

Eu diria que o seguinte é muito mais legível do que teria sido se eu o dividisse em várias linhas:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Atualização: nos comentários, foi sugerido que essa seria uma maneira mais sucinta de fazer o acima:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

embora agora caiba em 80 colunas, acho que meu argumento ainda permanece e eu apenas peguei um mau exemplo. Ele ainda demonstra que colocar várias instruções em uma linha pode melhorar a legibilidade.


8
Ao dizer que existem apenas pequenas diferenças de linha para linha, você também diz que há muito código redundante. A remoção de parte disso pode diminuir significativamente o número de colunas e ainda estar alinhada verticalmente.
23/10/08

@ MXP: concordou. Se houver uma maneira mais concisa de escrever o texto acima, eu estaria interessado em ver.
Sam Hasler

Eu concordo com a idéia geral, mas com o exemplo ... Que tal isso: switch (...) {case ... BL: dxDir = - 1; dyDir = - 1; pausa; caso ... BR: dxDir = + 1; dyDir = - 1; pausa; ...} ... ["X"] = pt1.x + dxDir * Rad ... X; ... ["Y"] = pt1.y + dyDir * Rad ... Y;
Yarik 27/10/08

38
O fato de eu precisar rolar o primeiro dos dois exemplos horizontalmente prova que as linhas mais curtas são melhores :-)
Enno

1
Eu não entendo o ódio por rolagem? É uma opinião comum, e não estou dizendo que está errado, simplesmente não entendo. Especialmente se você estiver em um editor de código, você não precisa mesmo de mover suas mãos do teclado para chegar ao mouse - apenas (ctrl+)arrowmais ou baterend
Kogi

21

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


16

Eu uso a vantagem de telas maiores para ter vários pedaços de código próximos um do outro.

Você não receberá nenhuma munição de mim. Na verdade, eu detestaria vê-lo alterado, pois em emergências ainda vejo casos raros em que preciso alterar o código de um console de texto.


14

Linhas super longas são mais difíceis de ler. Só porque você pode obter 300 caracteres no monitor não significa que você deve fazer as linhas por muito tempo. 300 caracteres também é muito complexo para uma declaração, a menos que você não tenha escolha (uma chamada que precisa de vários parâmetros).

Eu uso 80 caracteres como regra geral, mas vou além disso, se aplicá-lo significaria colocar uma quebra de linha em um local indesejável.


Existem estudos que mostram que as pessoas podem ler e seguir x quantidade de caracteres / palavras antes de perderem o controle. Eu estou pensando que 80 está lá em algum lugar. Eu não tenho nenhuma fonte para apoiar isso.
Até

Sim, acho que realmente, não se trata de manter as linhas curtas, mas de manter as linhas limpas / concisas / legíveis / compreensíveis.
KOGI

Se você tiver uma (uma chamada que precisa de vários parâmetros), precisará refatorar de qualquer maneira.
Zarremgregarrok

@Zarremgregarrok Vi algumas listas de parâmetros muito longas nas APIs da Microsoft.
Loren Pechtel

@LorenPechtel Isso faz com que seja bem escrito?
Zarremgregarrok

8

A única coisa que importo para permanecer dentro de 80 caracteres é o meu comentário.

Pessoalmente ... estou dedicando todo o meu poder cerebral (o pouco que há) à codificação correta, é uma dor ter que voltar e quebrar tudo no limite de 80 caracteres quando eu poderia estar gastando meu tempo na próxima função . Sim, suponho que o Resharper possa fazer isso por mim, mas me assusta um pouco que um produto de terceiros esteja tomando decisões no layout do meu código e o mude ("Por favor, não quebre meu código em duas linhas HAL. HAL?" )

Dito isso, trabalho em uma equipe relativamente pequena e todos os nossos monitores são bastante grandes, portanto, me preocupar com o que incomoda meus colegas programadores não é uma grande preocupação.

Parece que algumas linguagens incentivam linhas de código mais longas em prol de mais retorno para o investimento (instruções abreviadas se então).


7

Tenho dois monitores de 20 "1600x1200 e uso 80 colunas, pois permite exibir várias janelas do editor de texto lado a lado. Usando a fonte '6x13' (fonte trad. Xterm), 80 colunas ocupam 480 pixels mais a barra de rolagem e bordas das janelas. Isso permite que você tenha três janelas desse tipo em um monitor de 1600 x 1200. Nas janelas, a fonte do Lucida Console não faz isso (o tamanho mínimo de uso é de 7 pixels de largura), mas um monitor de 1280x1024 exibirá duas colunas e um monitor 1920x1200, como um HP LP2465 , exibirá 3. Ele também deixará um pouco de espaço ao lado para os vários exploradores, propriedades e outras janelas do Visual Studio.

Além disso, linhas muito longas de texto são difíceis de ler. Para texto, o ideal é 66 caracteres. Há um ponto em que os identificadores excessivamente longos começam a ser contraproducentes porque dificultam a organização coerente do código. Um bom layout e indentação fornece pistas visuais sobre a estrutura do código e algumas linguagens (Python vem à mente) usam a indentação explicitamente para isso.

No entanto, as bibliotecas de classes padrão para Java e .Net tendem a ter uma preponderância de identificadores muito longos, de modo que não é possível garantir necessariamente a capacidade de fazer isso. Nesse caso, o layout de código com quebras de linha ainda ajuda a tornar a estrutura explícita.

Observe que você pode obter versões do Windows das fontes '6x13' aqui .


Obrigado por dizer isso! Os monitores grandes são mais uma razão para o limite de 80 linhas, para que você possa instalar mais janelas lado a lado. Sem mencionar que é bom poder imprimir código-fonte (em papel) algumas vezes. Ou cole trechos em outros documentos.
dreeves

7

As pessoas dizem que longas filas de código tendem a ser complexas. Considere uma classe Java simples:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Possui 94 caracteres e o nome da classe é bastante curto (para os padrões GWT). Seria difícil ler em 2 linhas e é muito legível em uma linha. Sendo pragmático e permitindo "compatibilidade com versões anteriores", eu diria que 100 caracteres têm a largura certa.


5
Eu não sou um fã de barras de rolagem horizontal
bryc

9
Estou surpreso que ninguém tenha dito isso, já que estou vários anos atrasado para essa discussão, mas acho que as novas linhas (talvez com um recuo para maior clareza) logo antes de "estender" e / ou "implementar" as palavras-chave ainda produziriam muito código legível.
Mtraceur

2
Eu amo o fato de que diz "é muito legível em uma linha", enquanto ao mesmo tempo não consigo ler o trecho de código inteiro, pois ele excede o espaço horizontal no navegador. Ponto refutado.
Oligofren #

6

As outras respostas já resumiram bem as coisas, mas também vale a pena considerar quando você pode copiar e colar algum código em um email, ou, se não o código, um diff.

É um momento em que ter uma "largura máxima" é útil.


6

Você não é a única pessoa que manterá seu código.

A próxima pessoa que tiver uma tela de 17 "ou precisar de fontes grandes para ler o texto. O limite deve estar em algum lugar e 80 caracteres é a convenção devido a limitações anteriores da tela. Você pode pensar em algum novo padrão (120) e por que é uma boa idéia usar essa outra opção que não seja "é isso que cabe no meu monitor na fonte Xpt?"

Lembre-se, sempre há exceções a todas as regras, para que você tenha uma linha ou bloco de código específico que faça mais do que 80 caracteres e seja um rebelde.

Mas reserve um tempo para pensar "esse código é realmente tão ruim que ele não pode viver dentro de 80 caracteres?"


1
Eu vou viver com 80 caracteres quando eu puder ter 2spc tabstops. Melhor ainda, na verdade, use guias para recuo, o requisito é quando tabsize = 2, cabe em 80 colunas, usa 4 na maioria das vezes para melhor legibilidade. Dessa forma, quando você realmente precisa reduzir para 80 colunas, pode, mas a um preço.
217 Joshua Joshua

5

No padrão de codificação Linux, eles não apenas mantêm o limite de 80 caracteres, mas também usam recuo de 8 espaços.

Parte do raciocínio é que, se você alcançar a margem certa, considere mover um nível de indentação para uma função separada.

Isso tornará o código mais claro, pois, independentemente do tamanho do recuo, é mais difícil ler o código com muitas estruturas de controle aninhadas.


3
Que tal ler código com muitas chamadas de função? Certamente há um compromisso entre estas duas abordagens ...
Zsolt Török

5

Ampliei meu código para 100 caracteres, o que cabe confortavelmente em menos da metade da minha tela no meu Macbook. 120 caracteres é provavelmente o limite antes que as linhas comecem a ficar muito longas e complexas. Você não quer se alargar demais, mas encoraja declarações compostas e estruturas de controle profundamente aninhadas.

A margem certa é a maneira da natureza de dizer para você executar uma refatoração de método extra .


5

Gostaria de saber se isso pode causar mais problemas nos dias de hoje. Lembre-se de que em C (e possivelmente em outros idiomas) existem regras para o tamanho de um nome de função. Portanto, você geralmente vê nomes muito difíceis de entender no código C. O bom é que eles não usam muito espaço. Mas toda vez que olho código em alguma linguagem como C # ou Java, os nomes dos métodos costumam ser muito longos, o que torna quase impossível manter seu código com 80 caracteres. Não acho que 80 caracteres sejam válidos hoje, a menos que você precise imprimir o código etc.


5

Como autor de diretrizes de codificação para meu empregador, subi o comprimento da linha de 80 para 132. Por que esse valor? Bem, como outros apontaram, 80 é o comprimento de muitos terminais de hardware antigos. E 132 também! É a largura da linha quando os terminais estão no modo amplo . Qualquer impressora também pode fazer cópias impressas no modo amplo com uma fonte condensada.

A razão para não ficar com 80 anos é que eu prefiro

  • prefira nomes mais longos com significado para identificadores
  • não se incomode com typedefs para estruturas e enumerações em C (são ruins, ocultam informações úteis! Pergunte a Peter van der Linden em "Deep C Secrets" se você não acredita nisso), para que o código tenha mais do struct FOO func(struct BAR *aWhatever, ...)que o código dos fanáticos por typedef .

e sob essas regras, apenas 80 caracteres / linha causam agrupamentos feios de linhas com mais frequência do que meus olhos consideram aceitáveis ​​(principalmente em protótipos e definições de funções).


4

Como já foi dito, acho melhor (1) imprimir e (2) exibir vários arquivos lado a lado na vertical.


4

Gosto de limitar minha largura a 100 caracteres ou mais, para permitir dois editores SxS em um monitor widescreen. Acho que não há mais uma boa razão para um limite de exatamente 80 caracteres.


4

Use fontes proporcionais.

Estou falando sério. Geralmente, consigo obter a equivalência de 100 a 120 caracteres em uma linha sem sacrificar a legibilidade ou a capacidade de impressão. De fato, é ainda mais fácil ler com uma boa fonte (por exemplo, Verdana) e coloração de sintaxe. Parece um pouco estranho por alguns dias, mas você se acostuma rapidamente.


É uma péssima idéia quando você deseja usar 'recuos' e fontes monoespaçadas.
Bersaelor 31/07

2
@Bersaelor Não, funciona bem quando você sempre recua usando apenas guias e define a largura da guia corretamente (a largura 4 monoespaçada é talvez igual a 7 proporcional). O recuo funciona, você simplesmente não pode fazer arte ASCII, mas não acho que a arte ASCII pertença ao código.
Maaartinus

Pessoalmente, estou do lado oposto ao programar. Acho o código proporcional realmente difícil de ler. Às vezes, até configuro o IDE para usar fontes monoespaçadas (sim, incluindo menus).
Sebastian Mach

2

Tento manter as coisas em torno de 80 caracteres por um motivo simples: muito mais do que isso significa que meu código está se tornando muito complicado. Nomes de propriedades / métodos excessivamente detalhados, nomes de classes, etc. causam tanto dano quanto nomes concisos.

Eu sou principalmente um codificador Python, então isso produz dois conjuntos de limitações:

  1. Não escreva longas linhas de código
  2. Não recue muito

Quando você começa a atingir dois ou três níveis de indentação, sua lógica fica confusa. Se você não pode manter um único bloco na mesma página, seu código está ficando muito complicado e complicado de lembrar. Se você não pode manter uma única linha com 80 caracteres, sua linha está ficando muito complicada.

É fácil no Python escrever código relativamente conciso (consulte codegolf) em detrimento da legibilidade, mas é ainda mais fácil escrever código detalhado em detrimento da legibilidade. Os métodos auxiliares não são uma coisa ruim, nem as classes auxiliares. Abstração excessiva pode ser um problema, mas esse é outro desafio da programação.

Em caso de dúvida, em um idioma como C, escreva funções auxiliares e incline-as se você não quiser a sobrecarga de chamar outra função e recuar. Na maioria dos casos, o compilador manipulará as coisas de maneira inteligente para você.


2

Já existem muitas boas respostas para isso, mas vale a pena mencionar que no seu IDE você pode ter uma lista de arquivos à esquerda e uma lista de funções à direita (ou qualquer outra configuração).

Seu código é apenas uma parte do ambiente.


2

Eu não aplicar 80 caracteres significa eventualmente quebra de linha.
Na IMO, qualquer comprimento escolhido para uma linha de largura máxima nem sempre é apropriado, e a quebra de linha deve ser uma resposta possível.
E isso não é tão fácil quanto parece.

É implementado no jedit (fonte: jedit.org ), que oferece quebra de linhatexto alternativo

Mas é muito perdida no eclipse de um tempo muito longo ! (desde 2003, de fato), principalmente porque um quebra de linha para o editor de texto envolve:

  • As informações da linha agrupada são para o visualizador de texto, a navegação por código e as réguas verticais.
  • Informações de linha desembrulhadas são necessárias para funcionalidades como linha de ir, coluna da régua de numeração de linha, destaque de linha atual, salvar arquivo.

1

Na verdade, sigo uma regra semelhante para o meu próprio código, mas apenas devido à impressão do código em uma página A4 - 80 colunas têm a largura certa para o tamanho da fonte desejada.

Mas essa é a preferência pessoal e provavelmente não é o que você buscava (já que você quer que a munição seja o contrário).

O que você não questiona sobre o raciocínio por trás do limite - sério, se ninguém pode apresentar uma boa razão para isso, você tem um bom argumento para removê-lo de seus padrões de codificação.


Tenho certeza que é dos dias em que as telas do modo de texto tinham 80 caracteres de largura.
TraumaPony

1

Estou me afastando lado a lado o dia todo e não tenho um monitor de 22 polegadas. Não sei se um dia vou. Isso, é claro, é de pouco interesse para programadores somente para gravação que apreciam linhas de codificação por flecha e 300 caracteres.


1

Sim, porque mesmo hoje em dia, alguns de nós estão codificando em terminais (ok, principalmente emuladores de terminal), onde a tela pode exibir apenas 80 caracteres. Então, pelo menos para a codificação que eu faço, eu realmente aprecio a regra dos 80 caracteres.


0

Eu ainda acho que o limite não é limitado na parte visual. Certamente, os monitores e as resoluções são grandes o suficiente para mostrar ainda mais caracteres em uma linha hoje em dia, mas isso aumenta a legibilidade?

Se o limite for realmente imposto, também é uma boa razão para repensar o código e não colocar tudo em uma linha. É o mesmo com o recuo - se você precisar de muitos níveis, seu código precisará ser repensado.


0

Quebrar 80 caracteres é algo que você faz enquanto codifica, não depois. Mesmo com comentários, é claro. A maioria dos editores pode ajudá-lo a ver onde está o limite de 80 caracteres.

(Pode ser um pouco OT, mas no Eclipse há uma opção que formata o código quando você o salva (de acordo com as regras que você deseja). Isso é um pouco estranho no começo, mas depois de um tempo você começa a aceitar que a formatação não está mais em suas mãos do que o código gerado.)


0

Se tivéssemos um desses , não teríamos essa discussão! ;-)

Mas seriamente as questões que as pessoas levantaram em suas respostas são bastante legítimas. No entanto, o pôster original não estava argumentando contra um limite, apenas que 80 colunas são muito poucas.

A questão dos trechos de código por email tem algum mérito. Mas, considerando as coisas ruins que a maioria dos clientes de email faz com o texto pré-formatado, acho que a quebra de linha é apenas um dos seus problemas.

Quanto à impressão, geralmente acho que 100 linhas de caracteres cabem muito confortavelmente em uma página impressa.


0

Eu tento manter minhas linhas abaixo de 80 colunas. O motivo mais forte é que muitas vezes me vejo usando grepe lessnavegando no meu código ao trabalhar na linha de comando. Eu realmente não gosto de como os terminais estão quebrando longas linhas de origem (afinal eles não são feitos para esse trabalho). Outra razão é que acho que parece melhor se tudo se encaixa na linha e não é quebrado pelo editor. Por exemplo, ter parâmetros de chamadas de função longas alinhados bem abaixo um do outro e coisas semelhantes.

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.