tanguy_k a écrit :



Ra je le deteste ! :)

Par défaut il t’oblige a tout documenter, meme les methodes evidentes. Du coup tu te retrouves avec des trucs complètement idiot pour faire plaisir a l’outil :



/// {{summary}}

/// Returns the user’s name.

/// {{/summary}}

string GetName()



Sans compter le format XML des commentaires verbeux et illisible au possible.



A cela faut rajouter Sandcastle qui est particulièrement chiant a manipuler.



A cote Java et la JavaDoc c’est juste du pur bonheur, c’est pour dire !





Tu peux utiliser GhostDoc (gratos) pour te simplifier la vie " /> Il auto-génère des commentaires.



pour



public string Name { get; set; }



il va te générer



///

/// Gets or sets the name.

///



Après cet exemple est pas le meilleur, vu que le getter est trivial, mais dans tous les cas vu qu’il est public, il faudra le commenter. Dans ce cas précis çà va être dur de trouver un truc moins débile qu’un code autogénéré (ghostdoc sert juste à mettre une base, après faut améliorer le commentaire généré pour qu’il serve vraiment).



Sinon commenter c’est chiant au début, mais à la fin quand ton code est propre et documenté, c’est beaucoup mieux pour la maintenabilité.

Bejarid a écrit :



Ne compare pas StyleCop à FxCop, ce n’est pas la même chose, du tout.



StyleCop c’est UN DEV (Andy Chaypuquoi) qui balance des règles. C’est bien, mais ce dev, qui a tout mon respect pour maintenir ce projet à travers les versions de .Net et de VS, fait de sacré bourde. Tel que par exemple de forcer par defaut à utiliser les alias partout à la place de “String” “Int32” ou “Nullable…”. Ceci a été particulièrement décrié par toutes les têtes pensantes qui conçoivent ou influent sur le C# (qu’on trouve le choix de ces têtes pensantes justifiés ou non). Et se mettre en porte-à-faux avec ceux qui mène la barque dans laquelle on est, c’est pas terrible…



R# c’est un peu le même principe, y a une équipe (déjà un peu mieux) qui décide comment tu dois coder. Le problème étant que cette équipe est en faite dirigé par un responsable qui a le dernier mot (pourquoi pas) et dont le job est de faire de l’argent… Et là, ça coince. Tout est fait pour que ça soit chiat de faire demi-tour ou pour impressionner les responsables avec des fonctionnalités qui dans les cas d’école facilite énormément le boulot, puis 1 ans plus tard te font t’arracher les cheveux car niveau maintenabilité c’était juste catastrophique, sans parlé des problème de perf récurrent car ça cache le fonctionnement interne du framework.



A trop vouloir se simplifier la tâche sans être un minmum prudent, on s’en mord les doigts…

Donc StyleCop est un super moteur de vérification de code, et R# est bourré de bonne idée, mais autant StyleCop est parfaitement personalisable et donc peut être adapté au projet, autant R# ne l’est pas et au final c’est le projet qui se fait adapter, avec les soucis que ça implique car le client comme le Runtime .Net s’en moque bien de R#.



Donc FxCop (CodeAnalysis) et StyleCop sont des must have (après un peu de config) autant R# est beaucoup plus dangereux comme outil.





Je connais très bien Stylecop et FxCop " />



Stylecop a très longtemps été managé par Microsoft (d’ailleurs il y avait même “Microsoft” dans le path d’install de l’outil…). Les règles ne sont pas tirées du chapeau, elles sont issues de MSDN, des best practices éditées par Microsoft, et d’un consensus sur la façon de coder.



Pour ta règle en particulier (alias au lieu du type du framework), l’idée est simple : homogénéiser l’utilisation des types. Soit int de partout, soit Int32 de partout. Et quand il a fallut choisir… seul int était possible, vu qu’il est possible de faire



public enum MyEnum : int { }



mais pas



public enum MyEnum : Int32 { }





Pour toutes les règles de stylecop c’est pareil : on peut en discuter, on peut désactiver certaines règles, mais toutes ont une raison et aucune n’est farfelue.





Pour R#, l’objectif de jetbrains est de vendre. Leur arme ? Un produit efficace et demandé par 99% des développeurs. Franchement il faudrait expliciter tes critiques envers cet outil. R# ne refactore rien tout seul, il n’y a pas de “retour arrière” à faire vu que l’outil ne change rien au code.





puis 1 ans plus tard te font t’arracher les cheveux car niveau maintenabilité c’était juste catastrophique, sans parlé des problème de perf récurrent car ça cache le fonctionnement interne du framework.



Je vois pas de quoi tu parles exactement ? R# ne cache rien du tout, R# ne produit pas de code ni n’encapsule quoi que ce soit :confus:

tanguy_k a écrit :









Inodemus a écrit :





var est en fait principalement utile avec LINQ.



var maString = string.Empty; ne sert à rien.



Par contre



var myResult = this.repository.Query().Where(z => z.Enabled).GroupBy(z => z…..)…



où myResult est un mix de IQueryable /IGrouping/IEnumerable/… (voire bien pire…), le var est très pratique " />









Bejarid a écrit :



C’est pas R# qui propose ça, c’est visual studio directement.

Et ce genre de remarque est valable pour bcp de chose dont se targue R# : VS10 avec quelques plugins gratuit (souvent open source) et t’as + de 80% des fonctionalités qu’il propose. Et sans les inconvénients (difficile de coder sans après s’y être habitué car il remplace certain fonctionnement de base fourni par VS par les siens, configuration pas assez poussé pour faire ce qu’on veut quand on est pas d’accord avec les sacro saintes règles de R# (qui comme StyleCop nous balance des perles assez épiques par moment), etc.).



Bref, R# c’est loin d’être le messie, et je vous demande pas de me croire (contrairement aux précédents commentaires), seulement de croire les architectes du C# qui crache régulièrement sur R# (cet outil est interdit d’utilisation chez MS en passant, et ce n’est pas pour rien car plus d’un dev arrivé chez eux ces dernières années l’ont réclamé, mais la réponse a toujours été… instructive).





Pas d’accord. Un grand nombre de fonctionnalités de R# n’ont pas d’équivalent dans les extensions gratos de VS (autocomplétion XAML, imports XAML, refactoring avancé, erreurs potentielles (closures…), intégration avec stylecop pour proposer les warnings stylecop pendant que tu tappes…)



De plus va falloir m’expliquer le

qui comme StyleCop nous balance des perles assez épiques par moment

! Je suis un acharné de cet outil (tout comme code analysis, remplaçant de FxCop), va falloir nous dire ce que tu trouves qui est foireux comme règle !