Convenções de nomenclatura para arquivos de classe parcial

Estou gerando a maior parte do meu código de scaffolding ASP.NET MVC. Todos os arquivos gerados são classes parciais que usam convenções de nomenclatura padrão. Por exemplo, meu arquivo de controlador de funcionário é denominado EmployeeController.cs. Se eu desejar estender o EmployeeController com lógica personalizada não gerada, crio um segundo arquivo de classe parcial denominado EmployeeControllerCustom.cs. Eu separo a lógica personalizada e gerada em dois arquivos diferentes para que na próxima vez que eu gerar o EmployeeController minhas alterações personalizadas não sejam sobrescritas. Adicionar o sufixo "Custom" ao nome do arquivo parece razoável para mim, mas existe uma convenção de nomenclatura de arquivo de classe parcial mais estabelecida que eu deveria seguir?

c# naming-conventions code-generation partial-classes

— Ben Griswold
fonte

Respostas:

151

Eu uso .separação - por exemplo EmployeeController.SomeSpecialBehaviour.cs. Eu também o vinculo à árvore do projeto por meio de "dependsUpon" ou o que quer que esteja no csproj, para que ele se aninhe sob o arquivo (no explorador de soluções) de forma organizada. Você tem que fazer isso manualmente (editar o csproj) ou com um addin; por exemplo:

<Compile Include="Subfolder/Program.cs" />
<Compile Include="Subfolder/Program.Foo.cs">
  <DependentUpon>Program.cs</DependentUpon> <!-- Note that I do not reference the subfolder here -->
</Compile>

aparece como:

Subpasta
- Program.cs
  - Program.Foo.cs

— Marc Gravell
fonte

A sugestão do DependentUpon é muito legal e funciona muito bem. Obrigado por anotar. Se estou lendo corretamente, você não usa simplesmente um sufixo padrão como "Personalizado". Seu sufixo sempre expressa a intenção da funcionalidade do arquivo de classe parcial. Além disso, existe uma razão pela qual você usa o. separação oposta ao revestimento? Faz o. fornece algo mais do que legibilidade aprimorada? Obrigado.

— Ben Griswold

Correto - o nome do arquivo indica a intenção do código nessa parte . Portanto, se estou implementando uma interface exótica (e mantendo o código separado), pode ser SomeType.ICustomTypeDescriptor.cs. O .(IMO) separa as duas coisas: o tipo real ( SomeType) e a intenção ICustomTypeDescriptor- ambos já estão totalmente casados; além disso, combina perfeitamente com coisas como SomeForm.Designer.cs;-p

— Marc Gravell

Perfeito. Obrigado pelo insight adicional. Se eu pudesse fazer mais do que votar, sua resposta e marcar é a correta que eu faria.

— Ben Griswold,

@Marc Gravell: você por acaso conhece alguma extensão do VS que fornece a funcionalidade de configuração de DependentUpon para arquivos?

— Dyppl

@Dyppl A extensão FileNesting pode fazer isso

— gt

Para adicionar à resposta de Marc Gravell ♦, tive uma situação com arquivos em uma subpasta e o DependentUponnó sendo ignorado. Resumindo, nesse caso, meu xml tinha que ser:

<Compile Include="foo\bar.cs" />
<Compile Include="foo\bar.baz.cs">
    <DependentUpon>bar.cs</DependentUpon>  <!-- Note that I do not reference the subfolder here -->
</Compile>

Espero que isso ajude alguém :)

— Inominável
fonte

eu também. isso aconteceu porque eu comecei o projeto no banco de dados primeiro e quando ele criou o modelo, ele os colocou dentro do diagrama do modelo. VS2015 se fizer diferença para alguém.

— Joshua K