ti-enxame.com

Padrões de codificação .NET / C # recomendados?

Quais padrões de codificação você considera importantes para projetos .NET/C #? Isso pode ser qualquer coisa, desde lidar com aparelhos encaracolados, espaçamento e pediatria assim. Ou podem ser perguntas mais fundamentais, como quais namespaces evitar no .NET Framework, práticas recomendadas com arquivos de configuração etc.

Tente evitar criar uma postagem que seja simplesmente o corolário de outra. Por exemplo, seria bom ter um post focado em chaves. Não precisamos de dois para suportar um estilo versus o outro. A idéia não é votar no seu padrão de estimação, mas sim detalhar o que deve ser pensado ao criar padrões.

19
RationalGeek

Aqui está o Guia oficial da Microsoft sobre padrões de codificação para o .NET framework Versão 4.0.

Se você deseja a versão mais antiga para 1.1, tente aqui .

Eu não necessariamente sigo isso para um 'T', como eles dizem. No entanto, em caso de dúvida, este é o melhor lugar para começar a ser consistente com a atual estrutura .NET, o que facilita a todos, independentemente de serem novos em seu projeto ou não.

29
Ryan Hayes

Pode querer dar uma olhada em StyleCop . Você pode até incorporá-lo em alguns sistemas de compilação para que erros de estilo interrompam a compilação. As configurações padrão são principalmente congruentes com o que o MS sugere para diretrizes (conforme publicado por outros).

Você também pode alterar as regras fornecidas com o padrão.

10
Steven Evers
6
ysolik

Adotamos isso em nosso escritório. Foi escrito por Lance Hunt e é bastante abrangente:

http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx

5
CokoBWare

Comece com FxCop . Ele informará sobre violações das melhores práticas em seu código existente.

4
Victor Hurdugaci

Eu tenho que recomendar os padrões disponibilizados pela SSW (uma empresa de consultoria australiana).

Não apenas codificação, mas gerenciamento de projetos etc ... Um recurso incrivelmente valioso.

http://www.ssw.com.au/ssw/standards/default.aspx

2
davewasthere

Os métodos devem ser curtos

A maioria dos métodos deve usar a maioria dos campos de uma classe.

Escolha bem seus nomes.

Por exemplo, leia o livro Código Limpo

2
Ian

Estou usando os seguintes aplicativos para manter um padrão de codificação além das regras camelback, nome do método e etc.

GhostDoc - Adiciona um comentário gerado automaticamente na parte superior de cada método. O aplicativo fornece um bom resumo inicial do método. (livre)

http://submain.com/products/ghostdoc.aspx

Resharper - análise e refatoração de código http://www.jetbrains.com/resharper/

StyleCop - Como uma limpeza final antes de fazer o check-in no TFS. (livre)

http://code.msdn.Microsoft.com/sourceanalysis

2
Nickz

Eu tento escolher um conjunto comum de estilos de várias fontes. Alguns que não foram mencionados antes:

2
alexandrul

Eu odeio padrões de codificação estabelecidos, eles estão preocupados em dizer para você não cometer alguns erros tolos ou em como formatar seu código de uma maneira ou de outra. Todos os quais são trivialidades.

Quero dizer, eles lhe dirão quantos espaços colocar entre operadores, como colocar suas variáveis, que prefixos de 'estilo húngaro' usar (por exemplo, _ para membros), conselhos conflitantes (por exemplo, você não pode chamar uma classe Cxyz, mas você - deve chamar uma interface Ixyz), como fazer o layout do seu código (colocar sua variável na parte superior da classe ou na parte inferior)

Todos são inúteis no quadro geral.

O que importa para escrever código eficaz, de manutenção e legível nunca é mencionado nesses padrões.

Por exemplo: você coloca suas variáveis ​​na parte superior ou inferior da sua classe? Bem, quem se importa - o que importa é se você agrupar suas variáveis ​​por área funcional. Isso importa (você saberá disso se já viu 20 variáveis ​​espalhadas pelo local).

Eles dizem para você colocar seus colchetes em certos lugares. Grande negócio! Eu posso ler código nos bracketing K&R e ANSI, não importa. O que importa é se todas as classes Window forem diferenciadas de alguma forma (como serem sufixadas com Form ou Dlg ou o que for) para que você possa ver quais arquivos contêm código de janela e quais são objetos comuns.

Coisas assim importam muito mais do que os pontos menores que os padrões geralmente contêm. Não sei por que eles se desenvolveram assim, mas geralmente são apenas uma tonelada de regras que impedem uma codificação produtiva e eficaz.

Meus padrões tentam se concentrar mais na organização de códigos e arquivos. Temos certos padrões que se referem a onde os arquivos serão encontrados. Por exemplo, para quem não é desenvolvedor, pode ver um de nossos projetos e pegar imediatamente os arquivos de documentação que eles precisam. Da mesma forma, tentamos estruturar o código do projeto de maneira semelhante a outros projetos, como prático (nota: como prático, não de uma maneira muito proibida que possa não ser apropriada o tempo todo) e basicamente tentamos fazer diretrizes de padrões que pode ser modificado conforme necessário.

Em resumo - eles estão lá para nos ajudar a trabalhar juntos, não como um conjunto de regras restritivas que sempre têm a serem seguidas.

1
gbjbaanb

Aviso: Pragmatismo abaixo - A pergunta parece ser formulada para suscitar um debate sobre o estilo "adequado" de chaves, etc. Eu não tolero desperdiçando tempo com essa bobagem.

  1. Instale ReSharper , deixe os padrões, faça o que ele disser.

  2. Lucro - Todos os membros de sua equipe terão o mesmo estilo, muito próximo às diretrizes da Microsoft, apenas divergindo em alguns pontos em que os padrões do Resharper refletem o que é realmente mais amplamente usado na indústria e são (sem dúvida) melhorias.

Quanto menos tempo sua equipe gasta criando e referenciando algum documento ou livro hediondo ou discutindo sobre os curly braces e outras inanidades, mais codificação elas serão executadas. O ReSharper aplicará a nomeação e o estilo à medida que digitarem. Feito. Fim do debate. Nada mais a discutir. Se movendo.

Dito isso, uma leitura do clássico Código Completo ajudará a entender a lógica por trás dos padrões de codificação e oferecerá muitos ótimos indicadores sobre como transmitir efetivamente o significado através do código - algo que um documento de normas ou programa de inspeção não pode fazer .

Se você deseja aprimorar o que o resharper pode fazer por você, adicione StyleCop com o plug-in StyleCop for ReSharper. Como mencionado, haverá alguns pequenos conflitos entre as diretrizes da MS e os padrões do ReSharper. Eu iria apenas com ReSharper neles. Seja qual for o lado escolhido, salve os resultados no arquivo de configuração do ReSharper, compartilhe-o com sua equipe e pronto.

(Não, não sou um shill pago pelo ReSharper, apenas um cliente satisfeito. Além de muitos outros recursos, ele lida com questões básicas de estilo são mais econômicas do que qualquer documento de normas ou sistema de revisão de código - deixando a inteligência para coisas importantes.)

1
DanO