Como você resolver a discrepância entre “StyleCop C estilo #” e “estilo Framework Design Guidelines C #”?
-
06-07-2019 - |
Pergunta
Depois de passar pelo Apêndice A, "C # estilo de codificação convenções" do grande livro "Framework Design Guidelines" (2ª edição de novembro de 2008), estou muito confuso quanto ao que estilo de codificação é Microsoft usando internamente / recomendando.
A entrada do blog Uma Breve História de reivindicações C # Estilo :
Na verdade, as diferenças entre o "estilo StyleCop" eo "estilo de design orientações-quadro" são relativamente menores
A meu ver, as diferenças são bastante acentuada. StyleCop diz chave de abertura deve ser em uma linha separada, Framework Design Guidelines dizer que deve ser após a declaração de abertura. StyleCop diz que todas as palavras-chave devem ser seguidos por um espaço, Framework Design Guidelines dizer 'se livrar de todos os espaços' (mesmo operadoras de todo binários).
Eu acho essa regra do livro Framework Design Guidelines especialmente irônico (página 366, 6 de regra a partir do topo):
Do not espaços de uso antes de instruções de controle de fluxo
Right: while(x==y) Wrong: while (x == y)
Esta é explicitamente afirmando que o estilo StyleCop é errado (espaço após o tempo de palavra-chave, espaços antes e depois do operador de igualdade binária).
No final, código formatado usando o estilo de StyleCop tem uma "sensação" bastante diferente daquele formatado usando o estilo Framework Design Guidelines. Seguindo o estilo Framework Design Guidelines, um teria que desativar um monte de regras (E não há regras que a adesão de seleção para o estilo Framework Design Guidelines ...).
Poderia alguém (insiders MSFT talvez?) Lançar alguma luz sobre essa divergência?
Como é a sua equipe de lidar com isso? Após StyleCop? Projeto Framework Diretrizes? Ignorando estilo completamente? Cozer o seu próprio estilo?
Solução
Em um blog eu li sobre isso (eu não consigo encontrar a url) afirmou-se: as orientações-quadro baseiam-se e evoluiu de guideliness C ++ (eles são tudo temperado desenvolvedores C ++), enquanto as diretrizes StyleCop fornece são apenas guideliness mais moderno novo C # ... Ambos estão bem, tomar uma decisão a si mesmo ... Eu pessoalmente uso os StyleCop
Outras dicas
Este artigo pela equipe StyleCop explica exatamente o que você está pedindo que eu penso. http://blogs.msdn.com /sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx
E para responder à segunda parte da sua pergunta, nossa equipe só comecei a usar StyleCop usando todas as regras (algumas pessoas escolher e escolher quais usar). A única coisa que eu não gosto é o tempo extra que leva, mas usando uma ferramenta como StyleCopForResharper torna ir muito mais rápido. Eu costumava ficar muito irritado quando as pessoas escreveram código que olhou de forma diferente do que eu teria escrito, mas agora que usamos StyleCop, código de todos parece idêntico. Não mais mordendo o lábio sobre coisas irritantes pessoas fazem
Nós usamos StyleCop para todo o nosso código, e para além de algumas pequenas imperfeições, a maioria dos seus padrões Sinto liderança para o código mais legível. Um monte de seus padrões têm sido fortemente discutida dentro da Microsoft, e tiveram feedback da comunidade, e enquanto não se espera que todos vão concordar com tudo, é provavelmente sobre o melhor 'standard' existe (em particular, pois permite automática validação e correção automática com o StyleCop para ReSharper plugin).
Se houver alguma coisa você discorda fortemente com, Jason Allor que mantém a ferramenta é muito aberto a sugestões em torno de certas coisas, por exemplo, com auto-propriedades StyleCop originalmente insistiu em ...
public int Prop
{
get;
set;
}
... mas nós levantamos uma solicitação de mudança para permitir propriedades de linha única (tudo isto em uma linha), uma vez que há menos legível e ocupa menos espaço. Ele fez esta mudança dentro de alguns dias.
Você tomar uma decisão. Se você gosta de algumas partes de um e algumas partes do outro, escreva seu próprio guia de estilo. Se você gosta de um melhor que o outro, buscá-lo.
O essencial a fazer é escolher um estilo; não há nenhuma maneira de avaliar um sobre o outro de alguma forma quantitativa rigorosa.