Quantas linhas por classe são demais em Java? [fechadas]

Na sua experiência, qual é uma regra prática para quantas linhas de código são demais para uma classe em Java?

Para ser claro, eu sei que o número de linhas não está nem perto do padrão real a ser usado para o que deveria estar em uma classe específica e o que não deveria. As aulas devem ser projetadas de acordo com as filosofias apropriadas de OOP (encapsulamento etc.) em mente. Dito isso, uma regra geral pode fornecer um ponto de partida útil para considerações sobre refatoração (por exemplo, "Hmmm, esta classe tem> n linhas de código; provavelmente é ilegível e está fazendo um péssimo trabalho de encapsulamento, então eu gostaria de ver se deveria ser refatorado em algum momento ").

Por outro lado, talvez você tenha encontrado exemplos de classes muito grandes que ainda obedeciam bem ao design de OOP e eram legíveis e de manutenção, apesar de seu comprimento?

Aqui está uma pergunta não duplicada relacionada sobre linhas por função .

Algumas métricas interessantes:

            O que outras pessoas estão dizendo
            ----- -------- ------ --- ------- --- ------
max 500 498 1450 355 668 2168 5457
média 64,0 77,6 62,7 95,3 128,8 215,9 261,6
min 4 6 4 10 20 3 12
sigma 75 76 110 78 129 261 369
arquivos 90 632 1152 69 55 954 1468
linhas totais 5756 49063 72273 6575 7085 206001 384026

Eu uso o FitNesse como referência porque eu tinha muito a ver com escrevê-lo. No FitNesse, a classe média tem 77 linhas. Nenhum tem mais de 498 linhas. E o desvio padrão é de 76 linhas. Isso significa que a grande maioria das classes tem menos de 150 linhas. Mesmo o Tomcat, que possui uma classe acima de 5000 linhas, tem a maioria das classes com menos de 500 linhas.

Diante disso, provavelmente podemos usar 200 linhas como uma boa orientação para permanecer abaixo.

Para mim, linhas de código são irrelevantes neste contexto. É tudo sobre o número de razões diferentes pelas quais eu viria a essa classe para mudar isso.

Se eu vir para essa classe quando quiser alterar as regras para validar uma Pessoa, não quero vir para a mesma classe para alterar as regras para validar uma Ordem, nem quero vir aqui para mudar onde persistir uma pessoa.

Dito isto, se você busca isso, raramente encontrará classes com mais de 200 linhas. Eles acontecerão por motivos válidos, mas serão raros. Portanto, se você está procurando uma métrica de bandeira vermelha, não é um bom ponto de partida; mas faça disso uma diretriz, não uma regra.

Sinto muito, mas estou muito surpreso que muitas respostas afirmem que "realmente não importa". MUITO importa quantas linhas existem em uma classe. Por quê? Considere estes princípios ao escrever um bom código Java ...

• Testabilidade
• Coesão
• Acoplamento
• Compreensibilidade

Classes com muitas linhas nelas provavelmente violarão todos esses princípios.

Para aqueles que declararam que "realmente não importa" ... quão divertido foi para você tentar entender uma classe que tem mais de 5000 linhas? Ou, para modificá-lo? Se você diz que é divertido, você tem uma estranha afinidade com a dor ...

Eu diria que qualquer classe que tenha mais de 1000 linhas deve ser questionada pelo menos em como elas podem estar violando os princípios acima e possivelmente analisadas em várias classes "fora da sessão".

Meus comentários são baseados na leitura e no estudo de autores como Martin Fowler, Joshua Bloch e Misko Hevery. Eles são excelentes recursos para consultar para escrever um bom código Java.

Faça um favor ao próximo (que pode ser você em alguns anos) e se esforce para escrever aulas que tenham menos e não mais falas.

Depende da complexidade, não do número de linhas. Eu escrevi grandes rotinas idiotas que eram fáceis de entender e que fizeram exatamente uma coisa e fizeram bem, mas continuaram por centenas de linhas. Eu escrevi funções bastante curtas que eram difíceis de entender (e depurar).

Outra coisa que você pode ver é o número de funções públicas em uma classe. Isso também pode ser um sinal de alerta.

Não tenho boas contagens disponíveis, mas sugiro que você procure um código decente que faça coisas úteis em sua loja e baseie-o nisso. Certamente você deve observar as classes mais longas e as maiores APIs.

Existem muitas linhas de código se a classe estiver fazendo muitas coisas diferentes. Essencialmente, se você seguir o princípio de responsabilidade única para as aulas, há um limite para o tamanho da classe.

Quanto às limitações físicas que você pode ter (fonte: formato de arquivo de classe Java5 ):

• 65.536 constantes, interfaces aplicadas, campos, métodos e atributos - cada um. NOTA: você ficará sem espaço constante antes de ficar sem qualquer um dos outros itens. NOTA 2: atributos são construções de arquivo de classe - não devem ser confundidos com marcadores '@Attribute' (ou seja, informações de depuração e código de bytes são armazenados como atributos separados para um método).
• Cada método pode ter 4 GB (32 bits) de código de bytes gerado. NOTA: As versões Java anteriores à 1.5 só podiam ter 64 KB (16 bits) de código de bytes gerado para cada método.

Em resumo, o arquivo de classe pode ser muito maior do que qualquer um consideraria útil. Se você seguir o princípio da responsabilidade única, seus arquivos de classe terão o tamanho certo.

A resposta correta é 42. Brincadeira.
Na verdade, o máximo de linhas recomendadas por classe é de 2000 linhas.

As "Convenções de Código Java" desde 1999 declararam o seguinte:
Arquivos com mais de 2000 linhas são pesados ​​e devem ser evitados.

Tendo seguido as convenções de codificação Sun / Oracle desde que o Java foi inventado, achei razoável essa regra geral nas linhas por classe. 99% do seu código Java deve estar em conformidade ... E se ultrapassar o ano 2000, basta colocar um TODO no topo dizendo que a classe precisa de trabalho.

O pior é o caso oposto, quando os programadores criam muitas classes minúsculas com quase nenhuma funcionalidade real em cada classe. Ignorando os conselhos sobre "Favor da composição", os programadores criam centenas de classes herdadas que criam modelos de objetos complicados que são muito piores que o problema de classe grande (que pelo menos geralmente mantém a funcionalidade com um nome de classe relevante).

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html#3043

Código Limpo:

As aulas devem ser pequenas!

A primeira regra das classes é que elas devem ser pequenas. A segunda regra das classes é que elas devem ser menores que isso. Não, não vamos repetir exatamente o mesmo texto do capítulo Funções. Mas, como nas funções, menor é a regra principal quando se trata de criar classes. Como nas funções, nossa pergunta imediata é sempre "Quão pequena?"

** Com funções, medimos o tamanho contando linhas físicas. Nas aulas, usamos uma medida diferente. Contamos responsabilidades. **

O nome de uma classe deve descrever quais responsabilidades ela cumpre. De fato, nomear é provavelmente a primeira maneira de ajudar a determinar o tamanho da classe. Se não podemos derivar um nome conciso para uma classe, é provável que seja muito grande. Quanto mais ambíguo o nome da classe, maior a probabilidade de ele ter muitas responsabilidades. Por exemplo, nomes de classe, incluindo palavras de doninha como Processor ou Manager ou Super, geralmente sugerem uma agregação infeliz de responsabilidades.

Então:

• Apenas verifique se seus métodos fazem apenas uma coisa.
• Em seguida, verifique se a classe não tem muitas responsabilidades.

Você terminará com uma classe de tamanho gerenciável.

O número de linhas é uma métrica bastante ruim para a qualidade da classe. Para mim, gosto de analisar (como outros já mencionaram) métodos públicos, bem como quaisquer propriedades expostas publicamente (acho que getters / setters públicos em Java). Se eu tivesse que puxar um número do ar para quando pudesse chamar minha atenção, eu diria quando houver mais de 10 de cada. Realmente, se houver mais de 5 propriedades ou métodos, vou dar uma olhada e frequentemente encontrar maneiras de refatorar, mas qualquer coisa acima de 10 anos é geralmente um sinal de aviso de que é provável que algo seja pouco exposto.

É outra conversa inteiramente, mas métodos e campos privados são menos cheirosos para mim; portanto, se eles estão contribuindo muito para o número de linhas, talvez eu não esteja tão preocupado. No mínimo, isso mostra que provavelmente não há algum controlador de Deus manipulando o objeto de longe, o que é um problema de design de problemas bastante.

Tente usar uma métrica melhor.

Um exemplo é a métrica ABC . É mais uma medida de quanto trabalho está sendo realizado pelo código do que de quanto existe.

Qualquer linha que se enquadre no domínio de problemas da sua classe gravada fora da classe é uma linha a menos e a mais na classe em que vive. Pense em uma classe como um tópico. Você tem que cobri-lo. O mais concisamente possível é o ideal, mas se for necessário 500 linhas, serão necessárias 500 linhas. Se 100 dessas linhas abrangem outro tópico, elas pertencem a outro lugar. Quebrar em subdomínios menores dentro da classe como classes internas faz sentido, mas eu só definiria aqueles fora da classe se eles tivessem usado em outro lugar.