Em que ponto / intervalo um arquivo de código é muito grande?

Estou encontrando muitos arquivos de linha de 2-3k, e não parece que eles devam ser tão grandes.

Qual é um bom critério para chamar objetivamente um arquivo de código-fonte "muito grande"?, Existe uma quantidade máxima de linhas que um arquivo de código-fonte deve ter?

Como modelo ideal, uso os seguintes critérios (com uma lógica semelhante à sugerida por Martin Beckett, isto é, pensar em termos de estrutura lógica e não em termos de linhas de código):

Regra 1

Uma classe por arquivo (em C ++: uma classe -> um cabeçalho e um arquivo de implementação).

Regra 2

Sete é considerado o número de itens que nosso cérebro pode observar ao mesmo tempo sem ficar confuso. Acima de 7, achamos difícil manter uma visão geral do que vemos. Portanto: cada classe não deve ter mais de 7 a 10 métodos. Uma classe que possui mais de 10 métodos é provavelmente muito complexa e você deve tentar dividi-la. A divisão é um método muito eficaz, pois toda vez que você divide uma classe, você reduz a complexidade de cada classe individual pelo menos por um fator de 2.

Regra 3

Um corpo de método que não cabe em uma ou duas telas é muito grande (suponho que uma janela de tela / editor tenha cerca de 50 linhas). Idealmente, você pode ver todo o método em uma janela. Se não for esse o caso, você precisará rolar um pouco para cima e para baixo, sem esquecer a parte do método que fica oculta. Portanto, se você precisar rolar mais de uma tela para cima ou para baixo para ler todo o corpo do método, é provável que seu método seja muito grande e você poderá perder facilmente a visão geral.

Novamente, a divisão de métodos usando métodos de ajuda privados pode reduzir a complexidade do método muito rapidamente (a cada divisão, a complexidade é pelo menos reduzida à metade). Se você introduzir muitos métodos de ajuda particulares, considere criar uma classe separada para coletá-los (se você tiver mais métodos particulares do que os públicos, talvez uma segunda classe esteja oculta dentro da classe principal).

Reunindo essas estimativas aproximadas:

• No máximo uma classe por arquivo de origem.
• No máximo 10 métodos públicos por classe.
• No máximo 10 métodos particulares por classe.
• No máximo 100 linhas por método.

Portanto, um arquivo de origem com mais de 2000 linhas provavelmente é muito grande e começa a ficar muito confuso.

Essa é realmente uma estimativa muito aproximada e eu não sigo esses critérios sistematicamente (especialmente porque nem sempre há tempo suficiente para fazer a refatoração adequada). Além disso, como Martin Beckett sugeriu, há situações em que uma classe é uma grande coleção de métodos e não faz sentido dividi-los de alguma maneira artificial apenas para diminuir a classe.

De qualquer forma, na minha experiência, um arquivo começa a ficar ilegível quando um dos parâmetros acima não é respeitado (por exemplo, um corpo de método de 300 linhas que abrange seis telas ou um arquivo de origem com 5000 linhas de código).

Não - não em termos de linhas de código. O driver deve ser um agrupamento lógico. Certamente não deve haver várias classes em um arquivo grande, por exemplo

Se você tivesse uma classe que tivesse legitimamente algumas centenas de métodos (não é impossível dizer, por exemplo, modelagem 3D), seria muito menos conveniente dividi-la em arquivos arbitrários. Costumávamos fazer isso quando a memória era mais escassa e os processadores mais lentos - e isso era um esforço, procurando constantemente a definição da função.

Quando o código se torna inalterável. ou seja: você não pode dizer apenas observando o código se o método / classe / função que você está procurando (e precisa editar / depurar) está lá ou não, e se sim, onde está.

Porém, sua escolha e recursos de IDE / Editor influenciarão a quantificação real desse limite superior. Dobramento de código , função / método de listagem e pesquisa vai adiar o momento em que este desenvolvimento cenário apresenta.

Mas quando isso acontecer, é hora de dividir.

Aqui está uma visão alternativa: você está perguntando sobre como limitar o tamanho do arquivo. Minha opinião é que existem muitos fatores que tornam os arquivos de código grandes muito problemáticos. Às vezes, o arquivo de código é enorme, mas seu conteúdo é bem agrupado e com um código extremamente limpo, para que o tamanho não cause problemas significativos. Eu já vi muitos arquivos que são muito legíveis, apesar do alto LOC.

Em vez de usar a métrica LOC, prefiro pensar em usar os dados do histórico para entender com que frequência o código é quebrado nesses arquivos grandes. Geralmente, a razão disso é que os desenvolvedores não têm tempo para paciência para verificar os outros locais relevantes no mesmo arquivo e fazer a alteração com a mentalidade de "solução rápida", sem entendimento suficiente.

O maior perigo é a presença de código de copiar e colar. A codificação de copiar e colar naturalmente também acelera o crescimento do LOC. Eu acho que eliminar copiar e colar é ainda mais importante do que manter o LOC abaixo de algum número mágico. Além de copiar e colar puro, também existe um segundo perigo nos arquivos grandes: funcionalidade sobreposta. Quanto maior o arquivo, maior a probabilidade de você reimplementar algum trecho que já está em outra seção do mesmo arquivo.

Assim, enquanto proporção bug fix (proporção de correção de bug commit todos os commits) é baixo para os arquivos maiores, a situação é tolerável. Por favor, tente git loge percorra quantas confirmações estão relacionadas a erros. Ou use uma ferramenta que possa analisá-lo e visualizá-lo automaticamente, por exemplo, Softagram .

Considere isso Metaphor. No que diz respeito ao tamanho do código, acho que devemos considerar o seguinte:

The Cat in The Hat (50 pp.)

e

Lord of The Rings (1,178 pp.)

Não há nada errado com isso Lord of the Rings. É um livro fabuloso. The Cat in the Hattambém é um ótimo livro. Ambos podem ser entendidos por crianças de 5 anos, mas apenas um é mais adequado devido ao conteúdo.

Para o meu ponto, escrever código deve fazer sentido para uma criança de 5 anos sempre que possível. Cyclomatic Complexityé um conceito importante que os desenvolvedores devem considerar ao gerar código. Utilizando e criando bibliotecas para aprimorar a funcionalidade e a reutilização de código, tanto quanto possível. Dessa forma, nosso código pode falar mais volumes do que o que vemos escrito.

A maioria de nós não está escrevendo código de montagem . Mas a raiz do nosso código é assembly. Pesquisando através da montagem de 10000 linhas é mais difícil do que 10000 linhas de python, se isso for feito corretamente.

Mas algum trabalho requer a escrita de 500 a 1000 linhas. Nosso objetivo com o código deve ser escrever 300 linhas de código limpo.

Como desenvolvedores, queremos escrever "Senhor dos Anéis". Até conseguirmos um bug e desejarmos escrever "Cat in the Hat". Não faça da codificação uma medida do ego. Basta fazer as coisas funcionarem de maneira simples.

Os desenvolvedores não querem documentar o código (eu amo o código documentado pessoalmente, não sou tão egoísta). Portanto, não escreva código que somente você possa entender / ler. Escreva Cat in the Hatcódigo.

Todos sabemos que você é JRR Tolken (na sua cabeça). Lembre-se de que você não terá nada a provar com o código sem erros.

Outra razão para a metáfora.

Não exagere no leitor, espalhe a riqueza. Se você trabalha com um grupo de pessoas e todas elas precisam alterar o mesmo arquivo grande, provavelmente estará se metendo no gitinferno.

Todo mundo adora rebater.

-> Disse que ninguém nunca!

TL; DR Foco na legibilidade. Espalhe seu código e auxiliar por várias linhas e arquivos o máximo que puder. Não jogue 8 ou 9 classes em um único arquivo, isso torna o código difícil de ler e de manter. Se você tiver um código ou loop grande de condição, considere alterá-los para Lambdas se o idioma suportar. As funções de utilitários devem ser consideradas um ótimo caminho para aumentar a legibilidade do código. Evite aninhamento pesado.