Há alguma sugestão para desenvolver um documento de padrões/práticas recomendadas de codificação C#?[fechado]

Question

Sou recém-formado em IA (cerca de 2 anos) e trabalho em uma operação modesta.Coube a mim (principalmente porque sou o primeiro 'adotador' no departamento) criar um documento básico (leia-se útil?) de padrões de codificação C#.

Acho que devo explicar que sou provavelmente o engenheiro de software mais júnior, mas estou ansioso por esta tarefa, pois espero ser capaz de produzir algo parcialmente utilizável.Fiz uma pesquisa bastante extensa na Internet e li artigos sobre o que um documento de padrões de codificação deveria/não deveria conter.Este parece ser um lugar tão bom quanto qualquer outro para pedir algumas sugestões.

Percebo que estou potencialmente abrindo uma porta para todo um mundo de desacordo sobre “a melhor maneira de fazer as coisas”.Eu entendo e respeito o fato inegável de que cada programador tem um método preferido para resolver cada tarefa individual; como resultado, não pretendo escrever nada tão draconicamente proscritivo a ponto de reprimir o talento pessoal, mas tentar obter uma metodologia geral e concordar padrões (por ex.convenções de nomenclatura) para ajudar a tornar o código individual mais legível.

Então aqui vai....alguma sugestão?Algum?

Answer 1

Começamos com

• Diretrizes .NET da Microsoft: http://msdn.microsoft.com/en-us/library/ms229042.aspx (link atualizado para .NET 4.5)
• Diretrizes C# da Microsoft: http://blogs.msdn.com/brada/articles/361363.aspx.

e então documentar as diferenças e adições a essa linha de base.

Answer 2

IDesign tem um documento de padrões de codificação C# que é comumente usado.Veja também o Diretrizes de Design de Estrutura 2ª Ed.

Answer 3

Ironicamente, estabelecer os padrões reais provavelmente será a parte mais fácil.

Minha primeira sugestão seria obter sugestões de outros engenheiros sobre o que eles acham que deveria ser abordado e quais diretrizes eles consideram importantes.A aplicação de qualquer tipo de diretriz requer um certo grau de adesão das pessoas.Se você de repente colocar neles um documento que especifica como escrever código, você encontrará resistência, seja você o mais novato ou o mais velho.

Depois de ter um conjunto de propostas, envie-as à equipe para feedback e revisão.Mais uma vez, faça com que todas as pessoas acreditem neles.

Pode já haver práticas informais de codificação adotadas (por exemplo, prefixação de variáveis ​​de membros, nomes de funções de camelcase).Se isso existir, e a maior parte do código estiver em conformidade com ele, será compensador formalizar seu uso.Adotar um padrão contrário causará mais sofrimento do que vale a pena, mesmo que seja algo geralmente recomendado.

Também vale a pena considerar a refatoração do código existente para atender aos novos padrões de codificação.Isso pode parecer uma perda de tempo, mas ter um código que não atenda aos padrões pode ser contraproducente, pois você terá uma mistura de estilos diferentes.Isso também deixa as pessoas no dilema se o código de um determinado módulo deve estar em conformidade com o novo padrão ou seguir o estilo de código existente.

Answer 4

Eu sempre usei Juval Lowy pdf como referência ao criar padrões/melhores práticas de codificação internamente.Segue muito próximo FxCop/Análise de Fonte, que é outra ferramenta inestimável para garantir que o padrão esteja sendo seguido.Entre essas ferramentas e referências, você deverá ser capaz de criar um bom padrão que todos os seus desenvolvedores não se importarão em seguir e ser capazes de aplicá-los.

Answer 5

Os outros postadores apontaram você para a linha de base, tudo que eu acrescentaria é tornar seu documento curto, agradável e direto ao ponto, empregando uma grande dose de Strunk e White para distinguir os "obrigatórios" dos "seria bom se ".

O problema com os documentos de padrões de codificação é que ninguém os lê como deveria e, quando os leem, não os seguem. A probabilidade de tal documento ser lido e seguido varia inversamente com o seu comprimento.

Concordo que o FxCop é uma boa ferramenta, mas muito disso pode tirar toda a diversão da programação, então tome cuidado.

Answer 6

Nunca escreva seus próprios padrões de codificação, use os da MS (ou da Sun ou ...conforme apropriado para o seu idioma).A pista está na palavra padrão: o mundo seria um lugar muito mais fácil de codificar se cada organização não tivesse decidido escrever o seu próprio.Quem realmente acha que aprender um novo conjunto de 'padrões' cada vez que você muda de equipe/projeto/função é um bom uso do tempo de qualquer pessoa.O máximo que você deve fazer é resumir os pontos críticos, mas eu desaconselho fazer isso porque o que é crítico varia de pessoa para pessoa.Dois outros pontos que gostaria de abordar sobre os padrões de codificação

1. Fechar é bom o suficiente - Alterar o código para seguir os padrões de codificação ao pé da letra é uma perda de tempo, desde que o código esteja próximo o suficiente.
2. Se você estiver alterando o código que não escreveu, siga os 'padrões de codificação locais', ou seja,faça com que seu novo código se pareça com o código ao redor.

Esses dois pontos são a realidade do meu desejo de que todos escrevessem códigos que parecessem iguais.

Answer 7

Achei a documentação a seguir muito útil e concisa.Vem do site idesign.net e é de autoria de Juval Lowy

Padrão de codificação C#

Observação:o link acima está morto.Para obter o arquivo .zip, você precisa fornecer seu endereço de e-mail (mas eles não o usarão para marketing...honestamente) Tente aqui

Answer 8

Acabei de começar em um lugar onde os padrões de codificação exigem o uso de m_ para variáveis ​​de membro, p_ para parâmetros e prefixos para tipos, como 'str' para strings.Então, você pode ter algo assim no corpo de um método:

m_strNome = p_strNome;

Horrível.Realmente horrível.

Answer 9

Eu adicionaria Código Completo 2 para a lista (eu sei que Jeff é meio fã aqui)...Se você é um desenvolvedor júnior, o livro é útil para definir sua mente de uma forma que estabeleça a base para as melhores práticas de escrita de código e construção de software que existem.

Devo dizer que cheguei a isso um pouco tarde em minha carreira, mas isso rege muitas das maneiras como penso sobre codificação e desenvolvimento de frameworks em minha vida profissional.

Vale a pena conferir ;)

Answer 10

As próprias regras da Microsoft são um excelente ponto de partida.Você pode aplicá-los com FxCop.

Answer 11

Eu ficaria tentado a impor o StyleCop da Microsoft como padrão.Ele pode ser aplicado no momento da construção.mas se você tiver código legado, basta aplicar o uso do StyleCop no novo código.

http://code.msdn.microsoft.com/sourceanálise

Eventualmente, ele terá uma opção de refatoração para limpar o código.

http://blogs.msdn.com/sourceanálise/

Answer 12

Pessoalmente gosto daquele que IDesign reuniu.Mas não é por isso que estou postando...

A parte complicada na minha empresa foi levar em consideração todos os diferentes idiomas.E sei que minha empresa não está sozinha nisso.Usamos C#, C, assembly (fazemos dispositivos), SQL, XAML, etc.Embora existam algumas semelhanças nos padrões, cada um geralmente é tratado de forma diferente.

Além disso, acredito que padrões de nível mais elevado têm um impacto maior na qualidade do produto final.Por exemplo:como e quando usar comentários, quando exceções são obrigatórias (por exemplo,eventos iniciados pelo usuário), se (ou quando) usar exceções vs.valores de retorno, qual é a maneira objetiva de determinar o que deve ser o código do controlador versus o código de apresentação, etc.Não me interpretem mal, também são necessários padrões de baixo nível (a formatação é importante para a legibilidade!) Só tenho uma tendência para a estrutura geral.

Outra parte a ter em mente é a adesão e a aplicação.Os padrões de codificação são ótimos.Mas se ninguém concorda com eles e (provavelmente mais importante) ninguém os aplica, então tudo será em vão.

Answer 13

Como escrevi tanto o publicado pela Philips Medical Systems quanto o da Philips Medical Systems http://csharpguidelines.codeplex.com Posso ser um pouco tendencioso, mas tenho mais de 10 anos escrevendo, mantendo e promovendo padrões de codificação.Tentei escrever aquele CodePlex tendo em mente as diferenças de opinião e passei a maior parte da introdução explicando como lidar com isso em sua organização específica.Leia e me dê feedback.....

Answer 14

Regras SSW

Inclui alguns padrões C# e muito mais....focado principalmente em desenvolvedores da Microsoft

Answer 15

Provavelmente você está fadado ao fracasso.Bem-vindo à indústria.

Discordo - enquanto ele criar o documento, o pior que pode acontecer é ele ser esquecido por todos.

Se outras pessoas tiverem problemas com o conteúdo, você pode pedir que atualizem para mostrar o que preferem.Dessa forma, está fora de seu controle e os outros têm a responsabilidade de justificar suas mudanças.

Answer 16

Eu descobri recentemente Manual do Encodo C#, que inclui ideias de muitas outras fontes (IDesign, Philips, MSDN).

Outra fonte pode ser Diretrizes de codificação profissional C#/VB .NET.

Answer 17

Sou um grande fã do livro de Francesco Balena "Diretrizes práticas e práticas recomendadas para desenvolvedores VB e C#".

É muito detalhado e cobre todos os tópicos essenciais. Não apenas fornece a regra, mas também explica o motivo da regra e até fornece uma anti-regra onde pode haver duas melhores práticas opostas.A única desvantagem é que ele foi escrito para desenvolvedores .NET 1.1.

Answer 18

Todo o nosso padrão de codificação diz aproximadamente “Use StyleCop”.

Answer 19

Veja isso:http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx.

Answer 20

Eu tenho que sugerir o dotnetspider.com documento.
É um documento excelente e detalhado que é útil em qualquer lugar.

Answer 21

Já usei Juval antes e isso é demais, senão exagero, mas sou preguiçoso e agora apenas me conformo com a vontade de Reafiador.

Answer 22

Você pode conferir isto,7 principais padrões de codificação e documentos de orientação para desenvolvedores C#/.NET http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html espero que isto ajude

Answer 23

Acho que concordo com os outros comentários aqui de que as diretrizes da MS já vinculadas são um excelente ponto de partida.Eu modelo meu código principalmente neles.

O que é interessante porque meu gerente me disse no passado que não gosta muito deles :D

Você tem uma tarefa divertida pela frente, meu amigo.Boa sorte e pergunte se precisar de mais alguma coisa :)

Answer 24

O padrão da Philips Medical Systems está bem escrito e segue principalmente as diretrizes da Microsoft:www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

Meus padrões são baseados nisso com alguns ajustes e algumas atualizações para .NET 2.0 (o padrão Philips foi escrito para .NET 1.x, portanto é um pouco desatualizado).

Answer 25

Eu também sigo o Resharper.Também a linha de orientação mencionada no blog de Scott Guthriehttp://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net.aspxEhttp://csharpguidelines.codeplex.com/releases/view/46280

Answer 26

No código que escrevo costumo seguir Diretrizes de design do .NET Framework para APIs expostas publicamente e Diretrizes de codificação mono para revestimento e recuo de membro privado.Mono é uma implementação de código aberto do .NET, e acho que esses caras conhecem o que fazem.

Eu odeio como o código da Microsoft desperdiça espaço:

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

O que você pode achar estranho nas diretrizes do Mono é que elas usam tabulações de 8 espaços.No entanto, depois de alguma prática, descobri que isso realmente me ajuda a escrever código menos emaranhado, impondo uma espécie de limite de recuo.

Também adoro como eles colocam um espaço antes de abrir parênteses.

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

Mas por favor, não imponha nada assim se seus colegas de trabalho não gostarem (a menos que você esteja disposto a contribuir para o Mono ;-)