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


74

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 .


4
Já vi aulas com mais de mil falas, não acho que exista "demais".
Mahmoud Hossam

5
É demais quando não compila mais. Sério, é demais quando a classe está fazendo muitas coisas diferentes.
Berin Loritsch

20
Uma regra prática se transforma em um máximo que se transforma em uma política que se transforma em desacordo. Evite numerosidade. Contar e medir não é a maneira ideal de estabelecer se as responsabilidades foram alocadas corretamente.
S.Lott

7
Quase o mesmo que o número correto de polegadas para um pedaço de barbante.
Matt

6
Uma pergunta com 30 votos, vista ~ 24k vezes, 10 respostas com (coletivamente) ~ 75 votos. "fechado como essencialmente baseado em opiniões" Bem-vindo à troca de pilhas :) Algo precisa mudar na cultura SE ...
jb.

Respostas:


79

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.


9
Se a turma tiver apenas uma responsabilidade, as chances de ultrapassar as 200-500 linhas são muito pequenas. Os que normalmente possuem "classes internas" para lidar com outras responsabilidades relacionadas . Por exemplo, a classe de linha Tomcat 5000+ pode realmente ser uma classe principal com uma dúzia de classes internas. Isso não é incomum em Java, onde você tem manipuladores de solicitação e coisas do tipo.
Berin Loritsch

4
como essas métricas são obtidas, realmente? só quero saber #
31515

1
Normalmente, eu me inclinaria mais para esta resposta na pergunta relacionada a funções: programmers.stackexchange.com/a/9452/100669 LOC é meio irrelevante, exceto como talvez uma regra geral extremamente simples de começar a se perguntar se você pode ser capaz de quebrar as coisas ainda mais. E eu concordo com a coisa das classes aninhadas. No entanto, 500 é provavelmente mais próximo de um sinal de alerta geral.
Panzercrisis

@ Sнаđошƒаӽ github.com/AlDanial/cloc
firephil

32

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.


O 200 parece certo como um palpite bastante grosseiro. Como você diz, não é com o que você se preocupa primeiro.
8113 Steve

A coisa mais importante sobre Java é que, ao contar os LOCs, eu ignoraria os getters / setters.
MrFox 07/02

1
@ MrFox: eu discordo. Se a sua classe possui getters e setters suficientes para distorcer os dados do LOC, isso conta no "esta classe está fazendo muito?" Pergunta, questão. No entanto, como compromisso, eu estaria disposto a obter / setters do NetBean com menos de 1 linha / linha, em respeito ao excesso de placas-caldeira que esses métodos têm.
Brian

23

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.


Acho que todo mundo concorda que 5000+ geralmente não é um bom sinal (sem contar as classes aninhadas), mas eles sentem que é mais um efeito colateral ou algo do que o problema real. Obviamente, algumas pessoas são excessivamente verbosas e usam um número excessivo de linhas apenas para declarar e inicializar variáveis ​​e tal - e elas precisam parar com isso. Que não torná-lo menos legível. Mas se estiver relacionado à estrutura de classes, o problema não é o próprio LOC; é o fato de que alguém simplesmente não está terminando muito bem as coisas, e o LOC é um efeito colateral disso.
Panzercrisis

2
O ponto é que uma classe deve ter alta coesão e uma responsabilidade clara, o que significa que as classes geralmente não crescem tanto. Porém, se uma classe é bem projetada, mas ainda possui mais de 5000 linhas de código, não ajuda ninguém a dividi-la em várias classes menores e bem acopladas.
precisa saber é o seguinte

12

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.


7
+1: não meça coisas idiotas, como linhas. A complexidade ciclomática e a contagem de recursos (número de métodos) fazem mais sentido para as linhas.
S.Lott

2
sim e não. Um número excessivo de linhas geralmente é um sintoma de mau design e, portanto, uma bandeira vermelha de que a classe provavelmente precisa ser refatorada.
jwenting

1
@jwenting Sim, era nisso que eu estava falando. Eu sei que muitas linhas! = Precisam ser refatoradas, mas quase todas as classes com as quais estou trabalhando que realmente precisam ser refatoradas devido ao mau design têm muitas linhas.
Michael McGowan

5

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.


1
+1 por responsabilidade única :) @Berin, você implementa isso estritamente em seu software?
Aditya P

Sim. O truque é dividir as responsabilidades de uma maneira que faça sentido.
Berin Loritsch

ah, o bom e velho limite de 64 KB. Teste lithmus bom ver se suas JSPs são demasiado complexas, como eles se traduzido em um único método com lotes de declarações println para todo o seu html :) estática
jwenting

No Java 5, eles aumentaram para 4 GB. Não se preocupe lá agora.
Berin Loritsch

5

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


Na verdade, a maioria deles são comentários @LluisMartinez
Xtreme Biker

Discordo totalmente de 2000 . Uma classe não deve exceder 200 linhas, excluindo comentários.
Nikolas

4

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.


se Clean Codeno topo da sua resposta se refere ao livro de Robert C. Martin (o que é verdade!), devo dizer que você e eu o temos em comum; esse livro foi o que me levou a essa pergunta. Eu acho que esta resposta já diz tudo #
31515

2

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.


2

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.


1

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.

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.