Existe uma razão válida para impor uma largura máxima de 80 caracteres em um arquivo de código, neste dia e idade? [fechadas]

https://stackoverflow.com/questions/110928

02-07-2019
|

Pergunta

A sério. Em um monitor de 22" , ele só cobre talvez um quarto da tela. Preciso de um pouco de munição para machado para baixo esta regra.

Eu não estou dizendo que não deve haver um limite; Só estou dizendo, 80 caracteres é muito pequena.

Solução

Eu acho que a prática de manter o código para 80 (ou 79) colunas foi originalmente criado para pessoas de apoio edição de código em 80 colunas terminais burros ou em folhas impressas 80 colunas. Aqueles exigência, na sua maioria foi embora agora, mas ainda há razões válidas para manter a regra dos 80 coluna:

Para evitar embrulho ao copiar código em e-mail, páginas da Web e livros.
Para visualizar múltiplas janelas de origem lado-a-lado ou usando um visualizador de comparação lado-a-lado.
Para melhorar a legibilidade. código estreita pode ser lido rapidamente, sem ter que varrer os seus olhos de um lado para outro.

Eu acho que o último ponto é o mais importante. Embora monitores têm crescido em tamanho e resolução nos últimos anos, olhos têm não .

Outras dicas

A origem do texto de 80 colunas formatação é mais cedo do que os terminais 80 colunas - as datas de cartão de IBM soco novamente para 1928 ! Esta é uma reminiscência do (apócrifo) história que a bitola dos EUA foi determinada pela a largura das rodas dos carros na Grã-Bretanha romana.

Às vezes eu achar que é uma constrição pouco, mas faz sentido ter alguns limite padrão, então 80 colunas que é.

Aqui está o mesmo tema abordado por Slashdot .

E aqui está uma declaração Fortran old-school:

80 caracteres é um limite ridículo estes dias. Dividir suas linhas de código em que faz sentido, não de acordo com qualquer limite de caracteres arbitrária.

Você deve fazê-lo apenas por causa de todo aquele que não tem um de 22 polegadas widescreen monitor. Pessoalmente, eu trabalho em um 17 polegadas monitor 4: 3, e acho que mais do que suficientemente ampla. No entanto, eu também tenho 3 desses monitores, por isso ainda tenho muito espaço de tela utilizável.

Não só isso, mas o olho humano realmente tem problemas de leitura de texto se as linhas são muito longos. É muito fácil se perder em qual linha você está. Os jornais são 17 polegadas de diâmetro (ou somethign parecido), mas você não vê-los escrever todo o caminho em toda a página, mesmo vale para revistas e outros artigos impressos. Na verdade, é mais fácil de ler se você manter as colunas estreitas.

Impressão de uma fonte com espaçamento uniforme em tamanhos padrão é (em A4) 80 colunas por 66 linhas.

Quando você tem uma seqüência de instruções que se repetem com pequenas variações ele pode ser mais fácil de ver as semelhanças e diferenças, se o que eles estão agrupados em linhas de modo que as diferenças alinhar verticalmente.

Eu diria que o seguinte é muito mais legível do que teria sido se eu dividi-lo 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;
}

Update: No comentário está tem sido sugerido que esta seria uma forma 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 se encaixa em 80 colunas Acho que o meu ponto ainda está de pé e eu só peguei um mau exemplo. Ele ainda demonstrar que a colocação de várias instruções em uma linha pode melhorar a legibilidade.

Eu uso o a vantagem de telas maiores para ter vários pedaços de código lado uns dos outros.

Você não terá qualquer munição de mim. Na verdade, eu odiaria ver isso mudou desde que em situações de emergência ainda vejo raros casos onde eu preciso alterar o código a partir de um console de texto.

linhas Super-longas são mais difíceis de ler. Só porque você pode obter 300 caracteres através do seu monitor não significa que você deve fazer as linhas tanto tempo. 300 caracteres também é muito complexo para uma declaração, a menos que você não tem escolha (uma chamada que precisa de um monte de parâmetros.)

Eu uso 80 caracteres, como regra geral, mas eu vou ir além do que se impor, isso significaria colocar uma quebra de linha em um local indesejável.

A única coisa que eu valer a estadia dentro de 80 caracteres é o meu comentando.

Pessoalmente ... Eu estou dedicando todo o poder do meu cérebro (o pouco que há) para codificação de direito, é uma dor de ter de voltar e quebrar tudo até ao limite de 80 de char quando eu poderia estar gastando meu tempo com a próxima função. Sim, ReSharper poderia fazê-lo para mim, eu suponho, mas então ele me assusta um pouco que um produto 3o partido está tomando decisões sobre o meu layout de código e muda-lo ( "Por favor, não quebre meu código em duas linhas HAL. HAL?" ).

Dito isso, eu faço o trabalho em um relativamente pequeno equipe e todos os nossos monitores são bastante grande, então se preocupar com o que incomoda os meus colegas programadores não é uma grande preocupação, tanto quanto isso vai.

Parece que algumas línguas incentivar mais longas linhas de código para o bem de mais para bater a bola (short lado, se as declarações depois).

Eu tenho dois 20" 1600x1200 monitores e eu ficar com 80 colunas, porque me permite exibir várias janelas do editor de texto lado a lado. Usando o '6x13' font (a trad. Xterm fonte) 80 colunas levar até 480 pixels mais a barra de rolagem e janelas fronteiras. Isto permite que se tem três janelas deste tipo em um monitor de 1600x1200. no windows a fonte Lucida Console não muito fazer isso (o tamanho utilizável minima é de 7 pixels de largura), mas um monitor de 1280x1024 irá exibir duas colunas e um monitor de 1920x1200, como um HP LP2465 irá exibir 3. Ele também vai deixar um pouco de espaço ao lado para os vários explorador, propriedades e outras janelas do Visual Studio.

Além disso muito longas linhas de texto são difíceis de ler. Para o texto do ideal é 66 caracteres. Há um ponto onde excessivamente longos identificadores começam a ser contraproducente, porque eles tornam difícil colocar para fora o código de forma coerente. Boa disposição e recuo fornece indicações visuais quanto à estrutura do código e algumas línguas (Python vem à mente) uso recuo explicitamente para isso.

No entanto, as bibliotecas de classe padrão para Java e .Net tendem a ter uma preponderância de muito longas identificadores de modo que não pode garante necessariamente que ser capaz de fazer isso. Neste caso, estabelecendo código com quebras de linha ainda ajuda a tornar a estrutura explícita.

Note que você pode obter o Windows versões de '6x13' fontes Aqui .

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

Isso é um tempo em que ter uma "largura máxima" é útil.

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

A próxima pessoa que não pode ter uma tela de 17" ou pode precisar de fontes grandes para ler o texto. O limite tem que estar em algum lugar e 80 caracteres é a convenção devido a limitações tela anterior. Você pode pensar em qualquer novo padrão ( 120) e por isso é uma boa idéia usar o outro, em seguida, "isso é o que se encaixa no meu monitor na fonte XPT?"

Lembre-se, há sempre exceções para cada regra por isso você tem uma determinada linha ou bloco de código que faz sentido ter mais que 80 caracteres, em seguida, ser um rebelde.

Mas tomar o tempo primeiro a pensar "é este código realmente tão ruim que não pode viver dentro de 80 caracteres?"

No padrão de codificação Linux, não só eles manter o limite de 80 caracteres, mas eles também usam 8 espaço de recuo.

Parte do raciocínio é que, se você nunca chegar à margem direita, você deve considerar mover um nível de recuo em uma função separada.

Isso vai tornar o código mais claro porque, independentemente de comprimentos de recuo, é mais difícil de ler o código com muitos estruturas de controle aninhado.

Gostaria de saber se isso pode causar mais problemas neste dia e idade. Lembre-se que em C (e possivelmente outras línguas) existem regras para quanto tempo um nome de função pode ser. Portanto, você vê frequentemente muito difíceis de compreender nomes em código C. A coisa boa é que eles não usam muito espaço. Mas cada vez que eu olhar para o código em uma linguagem como C # ou Java os nomes dos métodos são muitas vezes muito longo, o que torna quase impossível para manter o seu código em um comprimento de 80 caracteres. Eu não acho que 80 caracteres são válidos hoje, a menos que você precisa para ser capaz de imprimir o código, etc.

Como já foi dito, eu acho que é melhor para (1) Impressão e (2) exibindo vários arquivos lado a lado verticalmente.

Eu gosto de limitar a minha largura de 100 caracteres ou menos para permitir que duas SxS editores em um monitor widescreen. Eu não acho que há qualquer boa razão para um limite de exatamente 80 caracteres mais.

Eu alargou o meu código para 100 caracteres que se encaixa confortavelmente em menos de metade da minha tela no meu Macbook. 120 caracteres é provavelmente o limite antes de linhas começam a ficar muito longo e complexo. Você não quer ficar muito ampla mais você incentivar instruções compostas e estruturas de controle profundamente aninhadas.

A margem direita é a maneira da natureza de dizer-lhe para realizar uma método extra de refatoração .

Usar fontes proporcionais.

Estou falando sério. Eu normalmente pode obter a equivalência entre 100-120 caracteres em uma linha sem sacrificar a legibilidade ou impressão. Na verdade, é ainda mais fácil de ler, com uma boa fonte (por exemplo, Verdana) e coloração de sintaxe. Parece um pouco estranho para alguns dias, mas você rapidamente se acostumar com isso.

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Esta é de 94 caracteres e o nome da classe é bastante curta (por padrões GWT). Seria difícil de ler em 2 linhas e é muito legível em uma linha. Ser pragmático sobre isso e permitindo assim "retrocompatibilidade", eu diria que 100 caracteres é a largura direita.

Como o autor da codificação diretrizes para o meu patrão me elevaram 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 em Modo de largura . Qualquer impressora também pode fazer cópias impressas em modo panorâmico com uma fonte condensada.

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

preferem nomes mais longos com um significado para identificadores
não se preocupar com typedefs para estruturas e enums em C (eles são ruins, eles se escondem informações úteis! Pergunte a Peter van der Linden em "Deep C Secrets" se você não acreditar), para que o código tem mais do que struct FOO func(struct BAR *aWhatever, ...) código de typedef fanáticos.

e sob essas regras apenas 80 caracteres / linha causa wraps linha feias mais frequentemente do que os meus olhos consideram aceitáveis ??(principalmente em protótipos e definições de função).

Eu tento manter as coisas perto de 80 caracteres por uma razão simples: muito mais do que esse significa que meu código está ficando muito complicado. Excessivamente detalhado nomes de propriedade / método, nomes de classe, etc. causa tanto mal quanto os concisas.

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

Não escreva longas linhas de código
Não travessão demasiado

Quando você começa a chegar a dois ou três níveis de recuo, a sua lógica fica confuso. Se você não pode manter um bloco único na mesma página, o código está ficando muito complicado e difícil de lembrar. Se você não pode manter uma única linha dentro de 80 personagens, sua linha está ficando muito complicado.

É fácil em Python para escrever o código relativamente concisa (veja codegolf) à custa da legibilidade, mas é ainda mais fácil de escrever detalhado código em detrimento da legibilidade. métodos auxiliares não são uma coisa ruim, nem são classes auxiliares. abstração excessiva pode ser um problema, mas isso é outro desafio de programação.

Quando estiver em dúvida em uma linguagem como C funções de gravação auxiliares e linha-los se você não quer que a sobrecarga de chamar para outra função e saltar para trás. Na maioria dos casos, o compilador irá lidar com as coisas de forma inteligente para você.

Já existe um monte de boas respostas para isso, mas vale a pena mencionar que em seu IDE você pode ter uma lista de arquivos à esquerda, e uma lista de funções do lado direito (ou qualquer outra configuração).

Você está código é apenas uma parte do ambiente.

I coisa não impor 80 caracteres meios, eventualmente, quebra de linha.
IMO, qualquer comprimento escolhido para uma linha max-width nem sempre é apropriado e quebra de linha deve ser uma resposta possível.
E isso não é tão fácil como parece.

Ele é implementado em jedit
_{(fonte: jedit.org )} que envolvem ofertas palavra

Mas é amargamente perdido no eclipse de um muuuito tempo ! (Desde 2003, na verdade), principalmente porque um envoltório palavra para editor de texto envolve:

informações de linha Envolvido é para o visualizador de texto, navegação de código, réguas verticais.
informações de linha Unwrapped é necessário para funcionalidades como Goto linha, arquivo linha coluna numeração governante, atual destaque linha, salvando.

Eu realmente seguir uma regra semelhante para o meu próprio código, mas só por causa da impressão do código a uma página A4 -. 80 colunas é sobre a largura certa para o meu tamanho da fonte desejado

Mas isso é preferência pessoal e provavelmente não o que você estava atrás (desde que você quer munição para ir para o outro lado).

O que você não questionar o raciocínio por trás do limite - a sério, se ninguém pode vir até com uma boa razão por que é assim, você tem um bom caso para tê-lo removido de seus padrões de codificação

Estou diffing side-by-side todo o dia e eu não tenho um maldito monitor de 22 polegadas. Eu não sei se eu vou. Isto, naturalmente, é de pouco interesse para os programadores somente para gravação desfrutando de linhas de codificação de seta e 300 de caracteres.

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

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

Se o limite for realmente executada é também uma boa razão para re-pensar o código e não para colocar tudo em uma linha. É o mesmo com o recuo -. Se você precisa de níveis muito suas necessidades código a ser re-pensamento

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

(Isto pode ser um pouco OT, mas em Eclipse, existe uma opção que formata o código quando você salvá-lo (de acordo com quaisquer regras que você quiser). Isto é um pouco estranho no início, mas depois de um tempo você começa a aceitar que a formatação não mais em suas mãos do que o código gerado é é.)

Se tivéssemos uma das estes , não teríamos ter essa discussão! ; -)

Mas a sério as questões que as pessoas têm levantado em suas respostas são bastante legítimo. No entanto o cartaz original não estava argumentando contra um limite, mas apenas que 80 colunas é muito poucos.

A questão da enviando trechos de código tem algum mérito. Mas, considerando as coisas más que a maioria dos clientes de email fazer a pré-formatado texto Eu acho que quebra de linha é apenas um dos seus problemas.

Como para a impressão Eu costumo achar que 100 linhas personagem irá muito confortavelmente caber em uma página impressa.

Eu tento manter as minhas linhas abaixo de 80 colunas. A razão mais forte é que muitas vezes eu me encontrar com grep e less para navegar meu código quando se trabalha na linha de comando. Eu realmente não gosto de como terminais estão quebrando as linhas de código longas (que, afinal, não são feitas para esse trabalho). Outra razão é que eu acho que fica melhor se tudo se encaixa na linha e não é quebrado pelo editor. Por exemplo, os que tem os parâmetros de chamadas de função longos bem alinhada abaixo do outro e semelhantes material.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow