ReSharper 7.1 est disponible : de nombreuses améliorations au programme

ReSharper 7.1 est disponible : de nombreuses améliorations au programme

Un jour, tout cela sera natif dans Visual Studio

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

14/11/2012 2 minutes
25

ReSharper 7.1 est disponible : de nombreuses améliorations au programme

Après avoir dévoilé la nouvelle version de son environnement de développement IntelliJ IDEA, Jet Brains vient de mettre à jour son outil phare dédié aux développeurs .Net : Resharper. Une mouture 7.1 qui se veut plus performante, mais aussi plus complète.

ReSharper 7.1

 

Resharper est un outil considéré comme indispensable pour de nombreux développeurs .Net. Au programme de la version 7.1 de ce complément de Visual Studio, on trouve bien entendu le support de Windows Phone 8 qui avait été présenté en octobre dernier. Celui de VB.Net a pour sa part été légèrement amélioré.

 

L'analyse du code et le partage des résultats avec les membres de votre équipe ont été simplifiés et les outils de formatage du code ont été améliorés comme expliqués dans cette publication. L'auto-complétion du code XAML et les différentes aides aux développeurs ont aussi été largement améliorées.

 

ReSharper 7.1 ReSharper 7.1

 

Du côté des performances, un gros travail a été effectué par l'équipe qui annonce que près de 300 soucis relevés ont été corrigés à ce niveau. De nombreux bugs ont aussi été corrigés au passage.

 

La mise à jour vers Resharper 7.1 est annoncée comme gratuite pour ceux qui disposent d'une licence 7.0 ou pour ceux qui ont acheté Resharper 6 depuis le 1er juin dernier. Pour rappel, il est possible d'obtenir Resharper gratuitement pour certains projets Open Source ou pour les écoles. La version complète est, elle, proposée à 47 €, 189 € ou 332 € HT selon que vous soyez un étudiant / professeur, un développeur ou une entreprise.

 

Vous trouverez tous les détails de cette nouvelle version par ici. Pour le téléchargement de la version d'évaluation de 30 jours, ça se passera par là.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (25)


newsmars
Le 14/11/2012 à 09h 52

Un petit plugin serait top pour exporter vers Android & iOS


jinge
Le 14/11/2012 à 09h 56

Une phrase pour expliquer les fonctionnalités principales de l’outil serait la bienvenue :)


psychotik2k3
Le 14/11/2012 à 10h 01

cool vais taner mon chef pour mettre a jour.


psychotik2k3
Le 14/11/2012 à 10h 02







jinge a écrit :



Une phrase pour expliquer les fonctionnalités principales de l’outil serait la bienvenue :)





en gros quand tu dev en c# cet outils est si indispensable que le retour sur investissement est de l’ordre de la semaine au maximum.



tom103
Le 14/11/2012 à 10h 13







jinge a écrit :



Une phrase pour expliquer les fonctionnalités principales de l’outil serait la bienvenue :)





Refactoring et génération de code, analyse du code pour détecter les problèmes potentiels, suggestions pour corriger ces problèmes, etc…

Ca fait gagner un temps fou, une fois que tu as commencé à l’utiliser c’est dur de s’en passer !



Takhiarel
Le 14/11/2012 à 10h 15

Vous êtes sûr que c’est digne d’une news ça ? D’une brève peut-être, mais bon…



C’est pas parce que le site est développé en .NET qu’il faut essayer de nous convertir aussi hein!

Remarque, j’m’en fous, je dév en C++ <img data-src=" />


darkdestiny
Le 14/11/2012 à 10h 25

Je trouve qu’un grand nombre des fonctionnalités de reSharper est aujourd’hui intégré à Visual Studio.

Au point de desfois on a juste l’impression de supplanter un raccourci par un autre.

J’adore sa règle pour les “var”… Si tu connais le type de ta variable utilise “var” n’importe quoi…


grunk
Le 14/11/2012 à 10h 30

C’est l’équivalent de Lint en java non ? en regardant la vidéo sur leur site , on retrouve exactement les même option qu’eclipse et lint (sauf que c’est payant ^^ ).


Anonyme
Le 14/11/2012 à 10h 44







darkdestiny a écrit :



Au point de desfois on a juste l’impression de supplanter un raccourci par un autre.

J’adore sa règle pour les “var”… Si tu connais le type de ta variable utilise “var” n’importe quoi…







Je n’ai jamais compris non plus l’intérêt de ce mot clé. Le code est bien plus compréhensible quand il est typé explicitement. Et quand on l’écrit, c’est toujours bien de savoir sur quel type on travaille pour savoir ce qu’on peut faire avec.

Et si on a aucune idée du type sur lequel on bosse, il y a probablement un problème quelque part.

(edit : ah, j’ai compris, c’est utile pour les types générés par le compilateur)



Lynh
Le 14/11/2012 à 10h 58

L’utilisation du mot clé var rend le code plus lisible dans certains cas :



MyCustomClass myObject = new MyCustomClass();



devient



var myObject = new MyCustomClass();


Le file structure de r# est pas mal. Je n’ai pas trouvé quelque chose d’aussi bien en gratuit. (codemap v2 est sympa aussi pour le file structure).


Inodemus Abonné
Le 14/11/2012 à 11h 28







Lynh a écrit :



var myObject = new MyCustomClass();



Je ne trouve pas cette forme plus ou moins lisible que l’autre, juste moins redondante. Mais il ne me semble pas qu’on paie les caractères à l’unité, en plus ReSharper propose tout seul de compléter la fin de la ligne dès qu’on a tapé le new, si le type a été spécifié à gauche.



Un cas par contre où c’est vraiment moins lisible, c’est ça (si le nom de la fonction ne permet pas d’identifier un type sans possibilité d’erreur) :



var myObject = GetCustomClass();



Et pourtant il me semble que ReSharper propose ce genre de remplacement par défaut, même si ça peut toujours se configurer.



tanguy_k Abonné
Le 14/11/2012 à 11h 32







unixorn a écrit :



Je n’ai jamais compris non plus l’intérêt de ce mot clé. Le code est bien plus compréhensible quand il est typé explicitement.











Lynh a écrit :



L’utilisation du mot clé var rend le code plus lisible dans certains cas :

MyCustomClass myObject = new MyCustomClass();

devient

var myObject = new MyCustomClass();







Ca me fait penser a cette vidéo :http://www.youtube.com/watch?v=z99EHyG2jQA



Lynh
Le 14/11/2012 à 11h 34

@Inodemus : effectivement, dans certains cas, c’est beaucoup moins lisible.

Mais chez moi, Resharper ne fait pas ses modifications tout seul, c’est seulement à la demande :-).


Inodemus Abonné
Le 14/11/2012 à 11h 48







Lynh a écrit :



Mais chez moi, Resharper ne fait pas ses modifications tout seul, c’est seulement à la demande :-).



Non effectivement, je me suis mal exprimé, je veux dire qu’il considère ça comme un changement à faire. Du coup, si tu lui demandes de faire automatiquement tous les changements de var, il fera sans distinction les lisibles et les moins lisibles.



Sans compter que ça vient encore s’ajouter à la barre d’infos/warnings/erreurs à droite du code (et pas qu’un peu), et que chez moi elle est déjà passablement surchargée de plein de trucs inutiles, ce qui la rend quasi inutilisable pour autre chose que les erreurs. Et à chaque version il y en a des nouveaux.



jinge
Le 14/11/2012 à 16h 58







psychotik2k3 a écrit :



en gros quand tu dev en c# cet outils est si indispensable que le retour sur investissement est de l’ordre de la semaine au maximum.





J’ai beau dev en C# je ne connaissais pas ^^





tom103 a écrit :



Refactoring et génération de code, analyse du code pour détecter les problèmes potentiels, suggestions pour corriger ces problèmes, etc…

Ca fait gagner un temps fou, une fois que tu as commencé à l’utiliser c’est dur de s’en passer !





Merci pour la brève explication <img data-src=" />



Bejarid
Le 14/11/2012 à 20h 39







Inodemus a écrit :



Mais il ne me semble pas qu’on paie les caractères à l’unité, en plus ReSharper propose tout seul de compléter la fin de la ligne dès qu’on a tapé le new, si le type a été spécifié à gauche.







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).









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 =&gt; z.Enabled).GroupBy(z =&gt; z…..)…



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









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 !



tanguy_k Abonné
Le 14/11/2012 à 21h 10







hadoken a écrit :



Je suis un acharné de cet outil (StyleCop)







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 !



psn00ps
Le 14/11/2012 à 23h 23







jinge a écrit :



Une phrase pour expliquer les fonctionnalités principales de l’outil serait la bienvenue :)



+1



tom103 a écrit :



Refactoring et génération de code, analyse du code pour détecter les problèmes potentiels, suggestions pour corriger ces problèmes, etc…

Ca fait gagner un temps fou, une fois que tu as commencé à l’utiliser c’est dur de s’en passer !



Il ne faut pas oublier FxCop, de simples règles suffisent à trouver des bugs subtils dans les moindres recoins d’un projet.



psn00ps
Le 14/11/2012 à 23h 25







Takhiarel a écrit :



Vous êtes sûr que c’est digne d’une news ça ? D’une brève peut-être, mais bon…



C’est pas parce que le site est développé en .NET qu’il faut essayer de nous convertir aussi hein!

Remarque, j’m’en fous, je dév en C++ <img data-src=" />



Tu ne dis rien quand Nvidia nous sort des drivers spécifiques à un jeu je crois<img data-src=" />









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 <img data-src=" /> 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
Le 15/11/2012 à 20h 48







hadoken a écrit :



De plus va falloir m’expliquer le ! 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 !





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.









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 <img data-src=" />



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:



Bejarid
Le 16/11/2012 à 19h 57







hadoken a écrit :



public enum MyEnum : int { }



mais pas



public enum MyEnum : Int32 { }







Tu cite justement un des exemples utilisé par l’équipe C# de MS quand ils ont critiqué cette règle de StyleCop (la covariance s’applique à INT32 mais pas à int, prouvant que ce n’est PAS là même chose et que donc on ne peut pas appliquer une règle dans un sens comme dans l’autre…). Et si StyleCop a été initié par MS celà fait longtemps qu’ils en sont retiré (rendant mensonger l’utilisation de Microsoft dans le path, mais bon, legacy oblige…), au point que la majorité des règles ont été implémenté par Andy (qu’il l’ait conçu où qu’on lui ait soufflé).



Pour R# je donnerais pas d’exemple, j’en ai pas qui tiendrait dans un simple commentaire (c’est du resort d’un forum là) mais R# génère beaucoup de code, principalement pour aider le coding ou la factorisation, mais comme tout générateur de code, il a ses faiblesses, et on a nos surprises en l’utilisant. Après, on est vaciné :p