Como seguir as melhores práticas de limite de 80 caracteres ao escrever o código-fonte?

Então, como você sabe, há uma prática recomendada dizendo

Limite uma linha do código-fonte em 80 caracteres.

Aqui estão 2 links:

Por que 80 caracteres é o limite 'padrão' para a largura do código?

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

E tenho certeza de que você pode se multar mais se procurar essa prática recomendada.

Mas acho isso extremamente difícil, aqui está um exemplo de exemplo:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference

Então você recua cada classe e cada método e cada instrução.

E eu já estou na coluna 60 até o final do último 'e' que tenho em 'myReference'.

Eu tenho 20 espaços restantes, na verdade, chame o construtor e atribua o objeto à referência que tenho.

Quero dizer, isso realmente parece melhor:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference 
                = new HashMap<String, List<MyInterfaceHere>>(); 

Qual é a melhor prática aqui?

A melhor prática deve ser "limitar o comprimento de uma linha para que você, todos os seus colegas e todas as ferramentas que você está usando estejam felizes com ela", além de algum senso comum. 80 caracteres parecem muito baixos e tendem a reduzir a legibilidade. Eu já fui totalmente enganado por uma linha como esta:

/* Very long comment to the end of the line */ realCode ();

onde a chamada de função não estava visível na tela (nem na tela de nenhum colega) sem indicação.

Defino meu editor para exibir uma margem de 100 colunas, além de reorganizar o código na tela, para que tudo fique sempre visível durante a edição, e linhas muito longas tendem a ser divididas manualmente em duas ou às vezes mais linhas. Ore para que o seu editor formate bem as instruções de divisão se executar a formatação automática. Use um estilo de codificação que não leve a instruções profundamente aninhadas. (Algumas pessoas criam um ninho de vinte declarações if, seguidas de uma cauda de vinte outras, o que leva a um recuo profundo de 200 caracteres, e ninguém pode descobrir qual outro pertence a qual if).

No seu caso particular, Swift inventou uma maneira de evitar isso: Uma variável "let" (que é quase a mesma que "final" em outros idiomas) deve receber um valor exatamente uma vez antes de ser usada, mas não necessariamente na declaração , para que você possa dividir sua linha problemática em duas declarações independentes.

PS. Encontrei linhas, em códigos reais escritos por humanos, com mais de 400 caracteres. Em outras palavras, você teria que rolar por séculos para ler o restante da linha, mesmo em um monitor de 24 polegadas. Eu não estava divertido :-(

Sim, parece melhor. É por isso que o "Não use linhas longas!" A máxima é muito forte.

Quanto às melhores práticas, nunca, nunca uso essas expressões construtoras horrivelmente longas. Eu sempre usaria

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> yReference = newMap();

para algum valor importado estaticamente adequadamente definido de newMap(). Considero um grave defeito em Java que ele não possui uma versão interna.

O objetivo não é "manter linhas com 80 caracteres". O objetivo é "tornar seu código fácil de ler e compreender". O limite artificial de 80 caracteres ajuda na legibilidade, mas não é uma regra rígida, a menos que sua equipe decida que é.

Você solicitou a melhor prática, e a melhor prática é "concentrar-se em tornar o código o mais legível possível". Se isso requer mais de 80 caracteres, que assim seja.

Não tenha medo de pressionar a tecla Return. A maioria das linguagens modernas (incluindo Java, como no seu exemplo) estão bastante satisfeitas com as declarações que se estendem por várias linhas.

Basta pensar um pouco sobre onde você quebra as linhas e pode obter algo que se encaixa em um limite de 80 colunas e ainda permanece perfeitamente legível. As convenções oficiais de codificação Java até especificam locais preferenciais para quebrar linhas.

Feito corretamente, uma linha bem ordenada é muito mais legível do que aquela que desaparece do lado da tela.

Se você aplicar o comprimento / largura da linha do código, use uma ferramenta.

• Re-afiador
• Visual Assist
• etc.

Os desenvolvedores decidem o que é um comprimento razoável (80, 120, 200 etc.), defina essa opção na ferramenta.

Depois disso, basta escrever o código como faria normalmente, sem considerar a largura ou a extensão da linha. Quando estiver funcional e finalizado, clique com o botão direito do mouse e escolha Limpar código ou opção semelhante. A ferramenta formatará o código como você disse e dividirá as linhas longas, conforme indicado.

Sem sentido e fácil e todos os arquivos de origem serão formatados da mesma maneira.

Atualmente, o limite de 80 caracteres pode ser um pouco curto demais, mas ajuda. Eu concordo com todas essas opiniões de que o código também deve ser bem formatado. por exemplo, código

/ * Comentário muito longo até o final da linha * / realCode ();

pode estar dentro de 80 chr, mas cria confusão, pois as observações e as opções de código estão na mesma linha.

Aderir ou não ao limite de 80 chr é a escolha dos indivíduos, mas se as coisas são visíveis em uma única cena, sempre proporcionará uma visão e um sentimento confortáveis ​​aos programadores e outros revisores também.