c# - titulo - title tag h1




Há alguma sugestão para desenvolver um documento de padrões/práticas de codificação C#? (18)

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

Acho que devo explicar que sou provavelmente o engenheiro de software mais jovem, mas estou ansioso por essa tarefa, pois espero poder realmente produzir algo que seja utilizável em parte. Fiz uma pesquisa bastante extensa da Internet e li artigos sobre o que um documento de normas de codificação deveria / não deveria conter. Este parece ser um bom lugar para pedir algumas sugestões.

Percebo que estou potencialmente abrindo uma porta para todo um mundo de discordância sobre "a melhor maneira de fazer as coisas". Eu tanto entendo e respeito o fato inegável de que cada programador tem um método preferido de resolver cada tarefa individual, como resultado, eu não estou querendo escrever nada tão draconiano e descritivo que abafasse o gosto pessoal, mas tentar obter uma metodologia geral e concordar padrões (por exemplo, convenções de nomenclatura) para ajudar a tornar o código do indivíduo mais legível.

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


Você provavelmente está sendo configurado para falhar. Bem vindo ao setor.

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, você poderá solicitar que ele as atualize para mostrar o que elas preferem. Dessa forma, sai do seu prato e os outros têm a responsabilidade de justificar suas mudanças.


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

m_strName = p_strName;

Horrível. Realmente horrível.


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


Como escrevi tanto o publicado pela Philips Medical Systems quanto o publicado em http://csharpguidelines.codeplex.com, eu poderia ser um pouco tendencioso, mas tenho mais de 10 anos escrevendo, mantendo e promovendo padrões de codificação. Eu tentei escrever o único CodePlex com diferenças de opinião em mente e passei a maior parte da introdução sobre como lidar com isso em sua organização particular. Leia e me dê feedback .....


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

Eu tenho que dizer que cheguei um pouco tarde na minha carreira, mas isso rege muitas das maneiras que eu penso sobre codificação e desenvolvimento de frameworks na minha vida profissional.

Vale a pena conferir;)



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



Eu usei o de Juval antes e isso é meio que se não for exagero, mas eu sou preguiçosa e agora apenas me conformo com a vontade de Resharper .


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

Minha primeira sugestão seria extrair sugestões dos outros engenheiros sobre o que eles acham que deveria ser coberto e quais diretrizes eles acham que são importantes. Aplicar qualquer tipo de diretrizes requer um grau de adesão das pessoas. Se de repente você soltar um documento neles que especifique como escrever código, você encontrará resistência, seja você o mais júnior ou sênior.

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

Pode já haver práticas de codificação informais que são adotadas (por exemplo, prefixando variáveis ​​de membros, nomes de funções de camelcase). Se isto existir, e a maior parte do código estiver de acordo com ele, ele pagará para formalizar seu uso. Adotar um padrão contrário causará mais sofrimento do que vale, 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 um desperdício de tempo, mas ter código que não atenda aos padrões pode ser contraproducente, pois você terá uma mistura de estilos diferentes. 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.


No código que escrevo, geralmente sigo as http://msdn.microsoft.com/en-us/library/ms229042.aspx para APIs expostas publicamente e as Diretrizes de Codificação Mono para invólucro e recuo de membros privados . Mono é uma implementação open source 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 do Mono é usar guias 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.

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 imponha nada assim se seus colegas de trabalho não gostarem (a menos que você esteja disposto a contribuir para o Mono ;-)


Nunca escreva seus próprios padrões de codificação usando os 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 o seu próprio. Quem realmente acha 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 um. O máximo que você deve fazer é resumir os pontos críticos, mas aconselho que não faça isso, porque o que é crítico varia de pessoa para pessoa. Dois outros pontos que gostaria de fazer em padrões de codificação

  1. Fechar é bom o suficiente - Alterar código para seguir os padrões de codificação à 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 foi escrito, siga os 'padrões de codificação locais', ou seja, faça com que o novo código se pareça com o código ao redor.

Esses dois pontos são a realidade para o meu desejo de que todos escrevessem código que parecesse o mesmo.


Os outros cartazes apontaram para você na linha de base, tudo que eu acrescentaria é tornar o seu documento curto, doce e direto ao ponto, empregando uma dose pesada de Strunk e White para distinguir os "must haves" dos "seria legal" ".

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

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


Pessoalmente eu gosto do que a pdf montou. Mas não é por isso que estou postando ...

A parte complicada da minha empresa estava levando em conta todas as diferentes línguas. E eu sei que minha empresa não está sozinha nisso. Usamos C #, C, assembly (fazemos dispositivos), SQL, XAML, etc. Embora haja algumas semelhanças nos padrões, cada um é geralmente tratado de forma diferente.

Além disso, acredito que padrões de nível mais alto 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 vs. valores de retorno, qual é a maneira objetiva de determinar o que deve ser código controlador versus código de apresentação, Não me entenda mal, os padrões de baixo nível também são necessários (a formatação é importante para a legibilidade!) Eu apenas tenho uma tendência para a estrutura geral.

Outra peça a ter em mente é a adesão e a execução. 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 em vão.


Todo o nosso padrão de codificação diz mais ou menos: "Use StyleCop".




Regras SSW

Ele inclui alguns padrões C # + muito mais .... principalmente focado em desenvolvedores da Microsoft







procedure