Une variable const locale devrait-elle commencer par une enveloppe supérieure ou inférieure

Vous avez un conflit de style entre StyleCop et Resharper. Stylecop 1303 dit que const vars devrait commencer en majuscule et je suis d'accord. Resharper dit OK pour les déclarations const à l'échelle de la classe, mais lorsque vous utilisez un const dans une portée locale (par exemple, une méthode), Reshaper n'approuve pas et veut tout faire camelCasing.Une variable const locale devrait-elle commencer par une enveloppe supérieure ou inférieure

Bien sûr, aucun problème pour désactiver cette règle R #, mais ce qui pourrait être la raison de cette règle? Quelqu'un a des pensées?

Source

2010-10-01 Marcel de Kleine

Si vous téléchargez StyleCop pour ReSharper il est livré avec un fichier de paramètres de ReSharper qui corrigera cela pour toi. Il est aussi un excellent moyen d'obtenir ReSharper pour vous aider à la conformité StyleCop:

http://stylecopforresharper.codeplex.com/

Source

2010-10-01 08:30:38

J'ai déjà ça en cours d'exécution :) Mais encore ce conflit. –

@Marcel de Kleine Avez-vous importé le fichier de paramètres? Cela n'arrive pas automatiquement lorsque vous installez le plugin. Quoi qu'il en soit, je resterais fidèle aux paramètres StyleCop - c'est ce que vous utilisez pour StyleCop. Si vous avez importé ce fichier, il pourrait être utile de déposer un bug sur S4R pour leur faire savoir qu'il y a quelque chose d'autre à redéfinir :) –

J'ai importé le fichier de paramètres mais j'ai toujours le conflit comme vous l'avez suggéré. ce. –

Je pense que StyleCope utilise le cas pour faire la distinction entre la portée de la classe et celle de la méthode.

Source

2010-10-01 08:13:40 Polyfun

Huh? Cela signifierait que tous les champs de portée de classe seraient aussi UpperCamelCase ... –

Ne me dis pas - je n'ai pas fait les règles. – Polyfun

Vous n'avez pas fait les règles, bien sûr ... Mais vous devriez penser à eux de toute façon ;-) –

Je suis sûr que presque tout le monde a des idées à ce sujet, et celles-ci sont rarement synchronisées. Trouvez votre saveur et respectez-la. Re # et similaires sont des suggestions. Vous et vos collègues devriez vous mettre d'accord sur quelque chose, c'est le plus important.

Source

2010-10-01 08:14:20 danijels

Je m'en tenir à l'interprétation R # dans ce cas (sur la portée locale, tout devrait être lowerCamelCase). C'est en grande partie une habitude, parce que je commence habituellement avec une variable, et après que j'ai fini la méthode, je pourrais changer le var en un const, si la balise intelligente de R # respective me recommande ceci .

Mais comme l'a souligné, l'important est d'être cohérent dans l'équipe ...

Thomas

Source

2010-10-01 08:24:50

Bien que je sois d'accord, la cohérence est la chose importante, en utilisant StyleCop implique que vous avez choisi de suivre les règles StyleCop. Cela signifie que vous préférez modifier la configuration de Resharper plutôt que de désactiver les règles. –

Huh? Il n'y a pas de 'règles StyleCop'. StyleCop est juste un outil de vérification de texte configurable et extensible qui est préconfiguré avec _Microsoft rules_. Et quoi qu'il en soit: Qu'est-ce qui vous amène à penser que StyleCop devrait être 'juste' et que R # devrait être 'faux'? –

De nombreuses décisions sur le format de code dans StyleCop peuvent être considérées comme arbitraires. Certains ont un bon raisonnement et certains sont juste un exemple de choisir un style et de s'y tenir. La plupart des règles ne sont pas configurables d'une façon ou d'une autre, alors choisir Resharper par défaut plutôt que StyleCop signifie que StyleCop ne sera plus compatible avec votre code. Le but de l'utilisation de StyleCop est de s'assurer que le code est identique et d'éviter les arguments "ce qui est le mieux". Ce n'est pas que StyleCop est forcément meilleur que Resharper, juste que c'est plus facile d'utiliser StyleCop pour l'application. –

Une variable const locale devrait-elle commencer par une enveloppe supérieure ou inférieure

Répondre

Questions connexes