Java Code Conventions e seus 70 caracteres por linha! Encara?

Oi Pedro,

Talvez você não esteja entendendo porque não sabe o motivo.
Você já percebeu que a maioria dos terminais (modo texto) dos SOs (Linux, Windows, etc.) tem 80 colunas?
Agora imagina que você precisa, por alguma razão, dar manutenção em um código que está armazenado em uma máquina que não tem interface gráfica.
Você abre o código em um editor de textos (vi, vim, nano, jed, edit, etc.) e nesse código existem diversas linhas com mais de 80 caracteres. Para você conseguir enxergar o código, você precisa ir na linha e ir avançando, sumindo o que está à esquerda. Percebe a inconveniência? Já tive que dar manutenção em código PHP e shell script em um servidor Linux onde o código escrito estava fora desse padrão e posso te dizer que é uma dor de cabeça enorme. Sendo assim, a convenção de 80 colunas deve ser seguida não só para Java, mas para qualquer outra linguagem de programação. Não sei se vc já percebeu, mas tem algumas IDEs (NetBeans por exemplo) que tem uma linha vertical bem clara na coluna 80 do editor, justamente para te lembrar isso. O problema então não é resolução de monitor, mas sim falta de interface gráfica.

Leia com atenção o que é dito na convenção:

[]'s

Ah, é claro. O mundo não vai acabar se você ultrapassar as 80 colunas. O ideal é evitar, mas se poucas linhas passarem o limite em poucos caracteres, digamos 10, eu não vejo problema.

[]'s

Legal David, não havia pensado nessa hipótese. Pior é que também já escrevi código pelo EDIT e nunca havia percebido tal dificuldade, de fato, em terminais sem a interface gráfica, complica e muito! :roll:

Porém, essa constante quebra de linha vai aumentando o código em número de linhas. Tudo bem que a convenção diz para manter um código em até aprox. duas mil linhas que significam linhas que não acabam mais… Mas veja: pega uma classe qualquer do pacote swing, por exemplo, uma JComponent… tem mais de cinco mil e quinhentas linhas! :shock: E boa parte das linhas com +/- uns cem caracteres, ou seja, o próprio Hans Muller e Arnaud Weber esqueceram das convenções. :lol:

Por isso levantei essa questão mas com certeza e sem sombras de dúvidas, como disse, em terminais sem interface gráfica a coisa é mais complicada e a convenção cai como uma luva!
Obrigado pela opinião moderador, sucesso sempre!

Mais opiniões não deixem de postar!

pedromuyala:

Legal David, não havia pensado nessa hipótese. Pior é que também já escrevi código pelo EDIT e nunca havia percebido tal dificuldade, de fato, em terminais sem a interface gráfica, complica e muito! :roll:

Porém, essa constante quebra de linha vai aumentando o código em número de linhas. Tudo bem que a convenção diz para manter um código em até aprox. duas mil linhas que significam linhas que não acabam mais… Mas veja: pega uma classe qualquer do pacote swing, por exemplo, uma JComponent… tem mais de cinco mil e quinhentas linhas! :shock: E boa parte das linhas com +/- uns cem caracteres, ou seja, o próprio Hans Muller e Arnaud Weber esqueceram das convenções. :lol:

Por isso levantei essa questão mas com certeza e sem sombras de dúvidas, como disse, em terminais sem interface gráfica a coisa é mais complicada e a convenção cai como uma luva!
Obrigado pela opinião moderador, sucesso sempre!

Mais opiniões não deixem de postar!

Oi Pedro,

Eu não vejo problema em aumentar a quantidade de linhas. O ideal é sempre fazer com que seu código seja fácil de ler e entender. O caso do Swing é algo que foge mesmo do padrão, porque são classes de interface gráfica e que acabam precisando fazer muitas coisas, extrapolando o “limite”. Tudo é questão de bom senso. Novamente vou dar um outro exemplo. Eu dei manutenção em um sistema Web em Java por quase três anos que tinha APENAS 3 classes. Uma era pequena, menos de 50 linhas, enquanto as outras duas tinham aproximadamente 7000 linhas cada! E o pior, cada classe (eram dois Servlets) era responsável em fazer dezenas de coisas diferentes, tinham muita coisa hardcoded, etc. Era terrível ter que mexer naquela bagunça e havia uma resistência enorme em refatorar o sistema. Em um cenário normal, suas classes sempre serão pequenas. Em aplicações que desenvolvo, só tenho um tipo de classe que fica grande, as classes que contém métodos estáticos utilitários.

[]'s

Oi David, é verdade, de fato as classes dificilmente passam 500 linhas, até mesmo as de interface com o usuário, isso já repicando elas para que mantenham uma média de 80 caracteres por linha.
Mas muito legal sua opinião, foi realmente importante mostrar a dificuldade em determinado caso para fazer valer a pena o que na convenção escrito está, mais um motivo para não ignorar a informação.
Parabéns, grande abraço, sucesso sempre!

E se mais alguém conhece ainda mais motivos para aplicar a convenção, por favor, sintam-se à vontade em postar!
Obrigado.

Ah, é verdade. Faltou falar as classes de interface gráfica. Sempre ficam grandes. Ou melhor, qualquer código para interface normalmente fica grande.
Sucesso p/ vc tbm.

[]'s

Senhores, mais um motivo para seguir a convenção: na hora de imprimir o código. Se você não quiser imprimir com fontes minúsculas demais (no mínimo Arial, 10), é importante manter a convenção. Parece bobo, ainda mais nos dias de hoje, onde a utilização de papel é cada dia menor em razão da preservação da natureza mas importante citar aqui, vai que não tem outro jeito e a impressão é necessária…

Abraço a todos!