Existem sugestões para o desenvolvimento de um documento de normas / práticas recomendadas para codificação em C #? [fechadas]

Sou recém-formado em AI (cerca de 2 anos) trabalhando para uma operação modesta. Incumbiu a mim (principalmente porque sou o primeiro 'adotante' no departamento) criar um documento básico (lido útil?) Sobre padrões de codificação C #.

Acho que devo explicar que provavelmente sou o engenheiro de software mais júnior, mas estou ansioso por essa tarefa, pois espero conseguir produzir algo meio utilizável. Eu fiz uma pesquisa bastante extensa na Internet e li artigos sobre o que um documento de normas de codificação deve ou não deve conter. Parece um bom lugar para pedir algumas sugestões.

Percebo que estou potencialmente abrindo uma porta para um mundo inteiro de discordâncias sobre "a melhor maneira de fazer as coisas". 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 estou procurando escrever algo tão draconiano como proscritivo que sufocar o talento pessoal, mas tentar obter uma metodologia geral e concordar. normas (por exemplo, convenções de nomenclatura) para ajudar a tornar os indivíduos mais legíveis.

Então aqui vai .... alguma sugestão? Alguma coisa?

Começamos com

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

e, em seguida, documente as diferenças e adições a essa linha de base.

O IDesign possui um documento de padrões de codificação em C # que é comumente usado. Veja também o Framework Design Guidelines 2nd Ed .

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

Minha primeira sugestão seria obter sugestões dos outros engenheiros sobre o que eles acham que deveriam ser abordados e quais diretrizes eles consideram importantes. A aplicação de qualquer tipo de diretrizes requer um certo comprometimento das pessoas. Se você soltar repentinamente um documento especificando como escrever código, encontrará resistência, seja você o mais novo ou o mais velho.

Depois de ter um conjunto de propostas, envie-as à equipe para obter feedback e revisão. Mais uma vez, leve as pessoas a comprá-las.

Já pode haver práticas informais de codificação que são adotadas (por exemplo, prefixando variáveis ​​de membros, nomes de funções camelcase). Se isso existir e a maior parte do código estiver em conformidade, será pago para formalizar seu uso. A adoção de 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 refatorar o 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 em um dilema se o código em um determinado módulo deve estar em conformidade com o novo padrão ou seguir o estilo de código existente.

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

Os outros pôsteres apontaram você para a linha de base, tudo o que eu gostaria de acrescentar é tornar seu documento curto, agradável e direto ao ponto, empregando uma dose pesada de Strunk e White para distinguir o "must haves" do "seria bom se" "

O problema com a codificação de documentos de normas é que ninguém realmente os lê como deveria e, quando os lê, não os segue. A probabilidade de tal documento ser lido e seguido varia inversamente com o tamanho.

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

Nunca escreva seus próprios padrões de codificação, use os padrões da MS (ou os 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 sua própria. Quem realmente pensa que aprender um novo conjunto de 'padrões' toda 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 aconselho a não fazer isso, porque o que é crítico varia de pessoa para pessoa. Outros dois pontos que gostaria de destacar sobre os padrões de codificação

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

Esses dois pontos são a realidade do meu desejo de que todos escrevam códigos com a mesma aparência.

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

Padrão de codificação C #

Nota: o link acima agora 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) Experimente aqui

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

m_strName = p_strName;

Horrível. Realmente horrível.

Eu adicionaria o Code Complete 2 à lista (eu sei que Jeff é um fã aqui) ... Se você é um desenvolvedor júnior, o livro é útil para configurar sua mente de uma maneira que estabeleça as bases para o melhor práticas de escrita de código e criação de software.

Devo dizer que cheguei a isso um pouco mais tarde na minha carreira, mas rege muitas maneiras de pensar sobre codificação e desenvolvimento de estruturas na minha vida profissional.

Vale a pena conferir;)

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

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

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

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

http://blogs.msdn.com/sourceanalysis/

Pessoalmente, gosto do que o IDesign montou. Mas não é por isso que estou postando ...

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

Além disso, acredito que padrões de nível superior têm um impacto maior na qualidade do produto final. Por exemplo: como e quando usar comentários, quando as exceções são obrigatórias (por exemplo, eventos iniciados pelo usuário), se (ou quando) usar exceções versus valores de retorno, qual é a maneira objetiva de determinar o que deve ser o código do controlador versus o código da 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 facilitar a leitura!) Eu só tenho um viés em relação à estrutura geral.

Outra peça 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 o mais importante) ninguém os aplica, então é tudo por nada.

Enquanto escrevi tanto o publicado para a Philips Medical Systems quanto o http://csharpguidelines.codeplex.com, posso ser um pouco tendencioso, mas tenho mais de 10 anos em escrever, manter e promover padrões de codificação. Tentei escrever o CodePlex com diferentes opiniões em mente e passei a maior parte da introdução sobre como lidar com isso em sua organização em particular. Leia e forneça feedback .....

Regras SSW

Ele inclui alguns padrões de C # e muito mais .... principalmente voltado para desenvolvedores da Microsoft

Você provavelmente está configurado para falhar. Bem-vindo à indústria.

Eu discordo - desde que ele crie o documento, o pior que pode acontecer é que ele seja esquecido por todos.

Se outras pessoas tiverem problemas com o conteúdo, peça para atualizá-lo para mostrar o que eles preferem. Dessa forma, está fora de seu alcance, e os outros têm a responsabilidade de justificar suas alterações.

Recentemente, encontrei o Encodo C # Handbook , que inclui idéias de muitas outras fontes (IDesign, Philips, MSDN).

Outra fonte pode ser o Professional C # / VB .NET Coding Guidelines .

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

É muito detalhado e abrange todos os tópicos essenciais. Ele não apenas fornece a regra, mas também explica o motivo por trás da regra, além de fornecer uma anti-regra em que poderia haver duas práticas recomendadas opostas. A única desvantagem é que ele foi escrito para desenvolvedores do .NET 1.1.

Todo o nosso padrão de codificação lê aproximadamente "Use StyleCop".

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

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

Eu usei o Juval antes e isso acabou, se não for um exagero, mas sou preguiçoso e agora apenas me conforme com a vontade do Resharper .

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

Acho que ecoo os outros comentários aqui de que as diretrizes já vinculadas ao MS são um excelente ponto de partida. Eu modelo meu código amplamente sobre eles.

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 você precisa de mais alguma coisa :)

O padrão da Philips Medical Systems é 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 o .NET 2.0 (o padrão da Philips foi escrito para o .NET 1.x, por isso é um pouco datado).

Eu também sigo o Resharper. Também a linha de guia mencionada no blog scott guthrie http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net .aspx E http://csharpguidelines.codeplex.com/releases/view/46280

No código que escrevo, geralmente sigo as Diretrizes de Design do .NET Framework para APIs expostas publicamente e as Diretrizes de codificação mono para identificação e revestimento de membros particulares . Mono é uma implementação de código aberto do .NET, e acho que esses caras conhecem seus negócios.

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 Mono é que elas usam guias de 8 espaços. No entanto, após alguma prática, descobri que ele realmente me ajuda a escrever código menos confuso ao impor um tipo de limite de indentação.

Eu também amo 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 aplique algo assim se seus colegas de trabalho não gostarem (a menos que você esteja disposto a contribuir com o Mono ;-)