Regra de uma classe por arquivo no .NET? [fechadas]

Eu sigo essa regra, mas alguns de meus colegas discordam dela e argumentam que, se uma classe é menor, ela pode ser deixada no mesmo arquivo com outras classes.

Outro argumento que ouço o tempo todo é: "Mesmo a Microsoft não faz isso, então por que deveríamos?"

Qual é o consenso geral sobre isso? Existem casos em que isso deve ser evitado?

Uma classe por arquivo também oferece uma idéia melhor do que cada check-in está mudando sem examinar as diferenças do arquivo.

Eu odeio quando as pessoas pensam no absoluto e dizem que você nunca deve fazer isso ou aquilo com algo subjetivo e exigente como esse, como se todos precisássemos nos conformar com a idéia estúpida de alguém de certo e errado. Conclusão: ter mais de uma classe por arquivo é totalmente bom se fizer sentido. Por faz sentido, quero dizer coisas como:

1. Torna o código mais fácil de digerir e manter
2. Torna a solução menos irritante (percorrer inúmeros arquivos desnecessários) e menos lenta
3. A equipe de desenvolvimento está de acordo com isso como uma prática de codificação local

Um bom exemplo do motivo pelo qual desejo várias classes por arquivo:

Digamos que eu tenha algumas dezenas de classes de exceção personalizadas, cada uma com 4 linhas, eu poderia ter um arquivo separado para cada uma ou agrupar as exceções e ter um arquivo por grupo. Para mim, o que parece a abordagem mais racional / pragmática é agrupá-los e ter apenas alguns arquivos, porque é mais eficiente em termos de tempo / codificação (não preciso clicar com o botão direito do mouse -> Adicionar classe, renomear 50 vezes) , mantém a solução menos confusa e com melhor desempenho.

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Às vezes, agrupo mais de uma classe dentro de um arquivo se elas estiverem bem acopladas e pelo menos uma delas for muito pequena.

A 'melhor prática' geral é ter um arquivo por classe.

Além de argumentos hipotéticos e focando no Windows .NET com o Visual Studio IDE e em projetos de software em expansão, faz sentido nesse contexto ter uma classe por arquivo.

Em geral, para referência visual, nada supera uma classe por arquivo. Realmente.

Não sei se a Microsoft faz ou não faz o mesmo, no entanto, eles criaram a partialpalavra - chave para dividir uma classe em vários arquivos (isso é ainda mais grave). É frequentemente usado para dividir o código de designer gerado automaticamente do seu código personalizado na mesma classe (mas às vezes é usado para permitir que diferentes desenvolvedores trabalhem na classe ao mesmo tempo por meio de arquivos diferentes). Portanto, a Microsoft vê os benefícios de vários arquivos e todo mundo tem em mente várias idéias de organização de arquivos com certeza no .NET.

Para classes aninhadas, você não tem escolha a não ser usar um arquivo ou pelo menos as primeiras partes das classes. Um arquivo é necessário e bom neste caso:

class BicycleWheel {
    class WheelSpoke {
    }
}

Caso contrário, por que você manteria várias classes em um arquivo? O argumento "porque eles são pequenos" ou associados um ao outro não retém muita água porque, eventualmente, suas classes serão associadas a outras classes. Por fim, você não pode inferir facilmente a organização de objetos no arquivo com base no uso deles, especialmente à medida que o software continua a crescer.

Além disso, se você usar pastas para espaços para nome , nunca terá um conflito de nome de arquivo de classe. Também é conveniente localizar uma classe por nome de arquivo no sistema de arquivos quando não estiver em um ambiente de desenvolvimento como o Visual Studio (por exemplo, se você deseja editar rapidamente uma classe com o Bloco de Notas ou algo rápido / leve ).

Tantas boas razões ...

Na grande maioria dos casos, sigo a regra de uma classe por arquivo. A única exceção que faço regularmente é a definição de uma enumeração fortemente acoplada a uma classe específica. Nesse caso, frequentemente incluirei a definição da enumeração no arquivo dessa classe.

Eu também acredito que deve haver um tipo incluído em um único arquivo.

Há uma exceção a esta regra que deve ser mencionada: Ter duas classes que diferem apenas por um argumento genérico, como:

RelayCommand     

e

RelayCommand<T>

Realmente, isso se resume à preferência pessoal. Todo mundo vai dizer "uma classe por arquivo", mas todos temos nossas razões para evitar isso em determinadas circunstâncias. Eu costumava ter um grande projeto que tinha cerca de 300 enums diferentes. De jeito nenhum vou ter 300 arquivos separados, um para cada classe, quando algumas das enumerações eram apenas de três estados.

Também para pessoas que não conseguem encontrar determinadas classes se elas não estiverem em todos os arquivos com o mesmo nome, existe um motivo para você não usar o Find procurando em toda a solução? O uso de Localizar economiza um tempo valioso rolando pelo Solution Explorer.

Não importa quão leve seja o conteúdo, acho que uma classe / interface / etc. por arquivo é essencial.

Se estou trabalhando em uma grande solução no Visual Studio, quero poder ver os arquivos e não ter que me aprofundar para ver. Mesmo com ferramentas de navegação como ReSharper, eu quero um mapeamento 1: 1.

Se você encontrar muitos arquivos de origem com pouco ou nenhum conteúdo (talvez estendendo uma classe, mas não adicionando nada a ela), talvez deva repensar seu design.

Acho que agrupar uma classe com sua classe padrão de fábrica no mesmo arquivo é muito útil.

Eu normalmente teria uma classe por arquivo, mas você normalmente teria que usar sua discrição para ver se o arquivo poderia conter classes relacionadas, por exemplo, agrupando suas exceções que podem ser reutilizadas por você e por outros desenvolvedores. Nesse caso, o usuário precisa apenas de um arquivo para ser incluído, em vez de vários arquivos.

Portanto, o ponto é: a discrição deve ser usada !!!

Em soluções maiores, acho muito valioso ter uma classe por arquivo e que o arquivo tenha o mesmo nome que a classe. Torna muito mais fácil localizar o código em que você precisa trabalhar.

A ferramenta StyleCop para C # possui regras padrão que requerem não mais que uma classe de nível superior em um espaço para nome (mais qualquer número de interfaces, delegados e enumerações nesse espaço para nome).

Nos casos de duas ou mais classes em que a segunda e as classes subseqüentes são usadas apenas pela primeira, elas podem e devem ser classes internas, visíveis apenas para a classe consumidora.

Em algum momento uma classe por arquivo, mas ...

Quando várias classes estão estritamente relacionadas, mais de uma classe no mesmo arquivo de origem é, IMHO, MELHOR do que dedicar um arquivo de origem curto a cada classe. A fonte é mais legível e compacta (e usando #region a mesma fonte pode ser mais estruturada do que antes).

Considere também que, às vezes, é NECESSÁRIO espalhar a mesma classe por arquivos diferentes (usando parcial ), pois ter um arquivo de origem com mais de 20.000 linhas não é útil, mesmo com a RAM que tenho disponível (mas essa é outra pergunta).

Ocasionalmente, deixarei uma classe pequena com uma classe maior, mas apenas se eles estiverem muito relacionados, como um objeto e sua classe de coleção ou fábrica.

Há um problema com isso, no entanto. Eventualmente, a classe pequena cresce até o ponto em que deveria estar em seu próprio arquivo. Se você a move para o novo arquivo, perde fácil acesso ao seu histórico de revisões.

ie

• na segunda-feira, faço uma alteração nas minhas classes x e y no arquivo y.css
• na terça-feira, eu separo a classe x em seu próprio arquivo x.css porque cresceu para grande
• na quarta-feira, meu chefe quer ver o que eu mudei na classe x na segunda-feira, para que ele analise o histórico do x.css, apenas o x.css não mostra o histórico antes das alterações de terça-feira.

Isso é realmente um problema? :)
Classes muito pequenas, como enums, podem ser reunidas com outras pessoas. Há uma regra a seguir: reunir apenas classes que tenham algo em comum.

Como digressão - em um dos meus projetos, tenho um arquivo com 150 classes dentro. O arquivo possui 10000 linhas de código. Mas é gerado automaticamente, por isso é totalmente aceitável :)

Um dos motivos para colocar várias classes relacionadas em um arquivo é que o pobre coitado que usa sua API não precisa gastar meio dia digitando a declaração da importação e o pobre coitado que precisa manter o código não precisa gastar metade um dia percorrendo o clichê da declaração de importação. Minha regra geral é que várias classes pertencem ao mesmo arquivo se você quase sempre usasse um grande subconjunto delas ao mesmo tempo, em vez de apenas uma de cada vez.

Eu faço isso, mas apenas quando as classes são relacionadas de maneira pai-filho e as classes filho são usadas SOMENTE pelo pai.

Eu costumo ficar com uma classe por arquivo. Mas farei exceções para grupos de construções semelhantes usadas em todo o projeto. Por exemplo:

• Um EventArgs.cs que contém todas as EventArgssubclasses, pois geralmente elas têm apenas de 5 a 10 linhas de código, mas geralmente são usadas por várias classes diferentes. Como alternativa, posso colocar as EventArgsclasses no mesmo arquivo da classe que declara os eventos.
• Um Delegates.cs que contém delegados que são usados ​​em todo o projeto, pois eles geralmente têm apenas 1 linha cada. Novamente, a alternativa é colocá-los no mesmo arquivo da classe que os expõe / consome.
• Um Enums.cs que contém enums usados ​​em todo o projeto. (Se houver um enumque é usado apenas por uma classe, geralmente eu vou privatepara essa classe.)

Outro voto para uma classe por arquivo, sendo o nome do arquivo igual à classe. Para mim, ajuda na manutenção de longo prazo. Eu posso facilmente examinar o repositório e ver quais classes fazem parte de uma solução sem precisar abrir o projeto ou qualquer um dos arquivos.

Eu o sigo 99% do tempo. É bom seguir os padrões, mas também acredito que a flexibilidade tem seu lugar. Às vezes, parece uma perda de tempo boba separar as coisas. Naquela época, eu me superava e apenas escrevia meu código.

As respostas até agora parecem girar em torno das exceções das pessoas à regra, então aqui está a minha: eu mantenho as classes e as classes de 'amigo' dos metadados juntas ao usar o pacote DataAnnotations no .NET3.5 SP1. Caso contrário, eles estão sempre em arquivos separados. Você sabe, na maioria das vezes. Exceto quando não estão.

Eu só faço isso raramente. Por exemplo, se houver uma enumeração ou estrutura intimamente relacionada à classe, mas trivial demais para ser separada por si mesma.

Ou uma classe separada para conter alguns métodos de extensão para essa classe principal.

One case could be:quando suas aulas formam um conjunto module / unitque serve algumas classes principais como helper classes, caso contrário, não .

dê uma olhada no código-fonte do projeto ASP.NET MVC 2.0 . Segue estritamente esta regra

Gosto da ideia de criar classes menores e garantir que a classe esteja fazendo apenas o que deve fazer. Se você tem várias classes que estão contribuindo para resolver um único problema, não há mal algum em reuni-las no mesmo arquivo.

Eu não seguiria as práticas da EM, pois elas não são as MELHORES PRÁTICAS!

Outro ponto que eu não vi mais ninguém mencionar é que, quando você desenvolve o uso da regra de uma classe por arquivo, pode ver facilmente o que essa classe específica está usando.

Por exemplo: você pode ter duas classes em que uma classe usa Linq e a outra não.

Se essas classes estivessem no mesmo arquivo, você não saberia dizer sem examinar o código de qual classe usa o quê. Quando se trata de uma classe por arquivo, basta olhar para a parte superior do arquivo para ver exatamente o que está sendo usado nessa classe. Ajuda se você estiver migrando para uma nova biblioteca, etc.

Outro motivo para uma classe por arquivo que não foi mencionado nas respostas postadas até agora é que uma classe por arquivo facilita a compreensão do impacto de um PR durante uma revisão de código. Também reduz conflitos de mesclagem.

Quando alguém publica um PR para obter feedback, posso ver a lista de arquivos alterados e ver imediatamente qualquer sobreposição com o que eu possa estar trabalhando. Dependendo da sobreposição, talvez eu queira examinar o código mais profundamente ou dar um OK, porque estou bastante confiante de que não afetará minhas próprias alterações.

Quando duas pessoas estão trabalhando em um arquivo de várias classes e as duas adicionam uma dependência, há uma boa chance de você ter um conflito de mesclagem no usingbloco na parte superior. A separação das classes em arquivos separa as dependências para que você possa ver o que cada classe está usando e não tenha conflitos como este.

Existem exceções a essa regra (interface + implementação, enumerações, ...), mas é um ponto de partida melhor que o oposto, que normalmente permite que desenvolvedores juniores agrupem todo tipo de classes não relacionadas no mesmo arquivo.

Uma classe por arquivo é uma regra clara e inequívoca, não sujeita a interpretação.

As classes relacionadas em um arquivo estão sujeitas a preferências e interpretações pessoais (como você pode ver em todas as outras respostas aqui sobre quando está tudo bem em usar) e, portanto, é uma regra ruim.

As idas e vindas foram muito interessantes e aparentemente inconclusivas, embora minha impressão geral seja que um mapeamento 1-1 entre classes e arquivos seja a opinião da maioria, embora com algumas exceções de pessoa a pessoa.

Estou curioso para saber se alguma das suas respostas varia dependendo de você: (1) desenvolver um aplicativo Windows Forms, um aplicativo Web, uma Biblioteca ou o que for; ou (2) usando o Visual Studio ou não. Ao usar o VS, parece que a regra de uma classe por arquivo também implicaria uma classe por projeto do VS, uma vez que o consenso em outros segmentos parece ser que as soluções / projetos do VS devem ser espelhados na nomeação e estrutura do diretório / arquivo. De fato, minha impressão é que o consenso é ter o nome do projeto = nome do assembly = nome do espaço para nome (aninhado), os quais seriam espelhados na estrutura e nomeação de diretório / arquivo. Se essas são as diretrizes (ou regras) corretas, todos esses mecanismos de organização aparentemente ortogonais seriam mantidos em sincronia.

Sim, para facilitar a leitura, devemos ter um arquivo por classe !. Apenas pulou em um projeto. Eu vejo muitas classes em um arquivo. apenas torna tão difícil para um cara novo entender isso. não devemos pensar em manutenção? quando desenvolvemos um software? muitas vezes o desenvolvimento continuará por outros desenvolvedores. Temos namespaces para organizar nossas coisas, não precisamos de arquivos para isso !.

Um item de código por arquivo, sim.

Tudo o resto é uma má prática - e, francamente, um sinal de vítima da RAD.

Assim que se inicia o desenvolvimento adequado de software (IoC, padrões de design, DDD, TDD, etc ...) e deixa o campo "omg, vamos fazer isso, não faço ideia de como, mas sou pago", verá que essa regra realmente é realmente importante.