como sei que dividi meu programa em pedaços muito pequenos?

4
Desde que entrei no mundo da programação, tenho sido bombardeado com dicas como "arquivo deve ser apenas x linhas", o que é justo, já que novos programadores tendem a colocar tudo em um único arquivo. Mas, depois de ter feito programação profissionalmente por mais de um ano, eu me via principalmente prejudicada pelo tamanho pequeno dos arquivos, e não pelo tamanho grande deles. Um dos maiores obstáculos que tenho, é ter que embaralhar entre 10 a 20 arquivos diferentes ao investigar como algo funciona, quando alguns desses arquivos contêm apenas algumas linhas.

Então, eu acho que minha pergunta é: como eu sei que dividi meu programa em pedaços muito pequenos?

    
por tsiki 12.08.2012 / 10:34
fonte

3 respostas

13

O tamanho do arquivo não parece ser o seu problema - no desenvolvimento do mundo real, você encontrará projetos que teriam centenas de arquivos, mesmo que cada um deles contenha milhares de linhas de código.

Se trabalhar com muitos arquivos for um problema, você precisará de melhor organização e ferramentas. Os IDEs modernos têm muitos recursos que ajudam nisso (por exemplo, ao programar o Java no eclipse, o "Open Call Graph" trará lágrimas de alegria aos seus olhos se você ainda não o viu), então aprenda a usar um deles bem. Quanto à organização, um código bem projetado deve ter baixo acoplamento e alta coesão , o que significa que o código o que faz coisas relacionadas é muito próximo (alta coesão) e para entender um dado pedaço de código você não precisa olhar para muitos outros (baixo acoplamento).

Tudo o que foi dito, o tamanho médio de um arquivo em código bem projetado deve ter talvez 300 linhas de código, mais ou menos (depende da linguagem também). Não há mínimo: às vezes, o design exige uma classe vazia.

    
por 12.08.2012 / 10:51
fonte
4

Em vez de ter que misturar com 20 arquivos, você teria que misturar com 20 locais no mesmo arquivo. Na minha experiência, os editores facilitam o shuffle com 20 arquivos e mantêm algum contexto - como a posição do cursor - para cada um, além de embaralhar com 20 locais no mesmo arquivo e tentar manter algum contexto para cada um. Você terá problemas para pular facilmente de um para o outro.

    
por 12.08.2012 / 11:40
fonte
1

Eu sugeriria que o tamanho do arquivo não é realmente tão importante, para mim a complexidade do objeto e o tamanho da função / método são muito mais importantes. Supondo que você esteja usando uma linguagem orientada a objetos, certifique-se de criar objetos que tenham uma função clara e certifique-se de que eles tenham apenas código para essas funções específicas.

Como regra geral, não tem nenhum método / função com mais de 25 linhas (excluindo linhas de comentários), se ele for maior do que isso.

Quanto aos arquivos em si, eles se tornam irrelevantes se você seguir as dicas acima porque você pode separá-los mais tarde, mas tente separar os arquivos logicamente ou fazer o que muitos idiomas fazem como uma linha de guia e colocar uma classe para um arquivo, se for uma linguagem procedural, tente quebrar a funcionalidade usando os arquivos, ou seja. IO em um arquivo, UI em outro arquivo e assim por diante.

Apenas meu 2c.

    
por 12.08.2012 / 15:36
fonte