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


19

Quais padrões de codificação você considera importantes para projetos .NET / C #? Isso pode ser qualquer coisa, desde lidar com aparelhos curvos, espaçamento e pedantismo 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.

Respostas:


29

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.


3
Sim - não pode dar errado combinar o que as pessoas que constroem o software usam. Eu já vi algumas guerras religiosas sobre esse tipo de coisa, mas quando você recebe algo que permite que seu próprio código seja consistente com as estruturas que ele está usando, você teria que ter um argumento extremamente forte para não usá-lo. Como um bônus, as ferramentas de análise estática que a MS produz já estão ajustadas para procurar essas práticas.
Todd Williamson

Posso obter algum feedback sobre o voto negativo, por favor?
Ryan Hayes

O que você não segue?
Jeffo

Bem, há muitas coisas lá e eu ainda não as memorizei. Então, ao invés de dizer que eu sigo exatamente (o que eu não sei o que faço, então pode ou não ser verdade), eu apenas digo que não, haha. Se eu soubesse a coisa toda, provavelmente saberia.
21711 Ryan Hayes

10

Pode querer dar uma olhada no 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.




4

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


O FxCop analisa os binários, não informa sobre o estilo de codificação, mas identifica alguns problemas.
19411 Steve



2

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

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 do check-in no TFS. (livre)

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


1

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 deve chame uma interface Ixyz), como fazer o layout do seu código (coloque 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 o sufixo Form ou Dlg ou o que for) para que você possa ver quais arquivos contêm código da 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 de que precisa. 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 precisam ser seguidas.


1

Aviso: Pragmatismo abaixo - A pergunta parece ser formulada para suscitar um debate sobre o estilo "adequado" de chaves, etc. Eu não aguento perder tempo com esse absurdo.

  1. Instale o 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 curly braceshediondo, ou discutindo sobre e outras inanidades, mais codificação elas serão executadas. O ReSharper aplicará nomes e estilos à medida que digitam. Feito. Fim do debate. Nada mais a discutir. Se movendo.

Dito isso, uma leitura do clássico Code Complete os 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 por meio do código - algo que um documento de padrões ou programa de inspeção não pode fazer.

Se você deseja aprimorar o que o resharper pode fazer por você, adicione o 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, eu não sou um shill pago pelo ReSharper, apenas um cliente satisfeito. Além de muitos outros recursos, ele lida com questões de estilo básicas com mais custo-benefício do que qualquer sistema de revisão de código ou documento de padrões - deixando a inteligência para coisas importantes .)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.