MS Visual Studio 2008 : Une mauvaise copie d’Eclipse

Depuis quelques jours, j’ai l’occasion d’utiliser Visual Studio 2008 à mon travail. Ceci me permet de faire quelques comparaisons avec mes outils fétiches, Eclipse et Netbeans.

Et la conclusion est désespérante pour Microsoft.

Leur produit est plus ancien mais beaucoup moins fourni, un comble.

Voici mes arguments :

  • Pas de touche magique (Le Ctrl + Shift + 1 d’Eclipse). Et oui, ces 3 touches parfaitement positinionnées qui permettent de faire pratiquement tout ce dont vous avez besoin au moment ou vous en avez besoin. Correction d’erreurs, import de classes, renommage, complétion. Avec VS 2008, rien de tout ca, vous avez la souris et son clic droit qui permettent de faire certaines choses, mais très peu en comparaison d’Eclipse.
  • Pas d’accès facile entre les classes, vous êtes obligé d utiliser le bouton droit de la souris et de faire « go to definition ». C’est lent, demande plusieurs manoeuvre et ca m’a rebuté plus d’une fois.
  • Génération de code laborieuse. Il est difficile de trouver les générateurs de code (genre get/set), et les complétions de code se génèrent souvent sans les parenthèses nécessaires aux appels de méthodes (vides) ou sans les accolades de fin des méthodes ou blocs conditionnels. Vous êtes donc toujours obligés de fermer les accolades, VS 2008 ne le fait pas pour vous.
  • Mise à jour des erreurs très tardives parfois. VS 2008 vous indique des erreurs, assez bien, même si on aurait aimé un affichage plus lisible, mais lorsque vous corrigez ces erreurs, celles-ci restent affichées jusqu’au prochain lancement du serveur. Ce n’est pas très agréable de chercher une erreur alors que vous venez de la corriger.
  • Documentation avec peu d informations. Je crois que c’est le pire. Microsoft vous fournit une grosse documentation sur MSDN, mais pour trouver un type en entrée ou en sortie d’appels de méthodes, il faut écrire la méthode dans l’éditeur pour le savoir. C’est plutôt moyen. Quand on compare avec la javadoc, on s’aperçoit vite que MS fait beaucoup moins bien dans ce domaine. J’avais trouvé une doc assez complète dans la MSDN, j’allais féliciter MS pour ces progrès et finalement il s’agissait de documentation java. Y’a pas à dire (faudra m’expliquer ce que fait la documentation java dans MSDN).
  • Utilisation brouillon des génériques. MS a fait pareil que Java en rajoutant des génériques sur ses types. Mais pourquoi faire simple quand on peut faire compliquer. Ce sont de nouveaux types, extensions des anciens mais dans d’autres packages et avec des fonctionnalités parfois différentes. Ce qui implique des imports différents, des utilisations différentes de type en fonction du contexte de programmation. Au final, on est vite perdu dans leur utilisation. Mais pourquoi n’ont-ils pas fait comme java ? Les mêmes types mais on autorise la généricité…
  • Fonctionnement de l’éditeur différent en fonction du langage. Et oui, l’éditeur ne se comporte pas de la même façon si vous développez en VB ou en C#. La complétion par exemple, avec la touche entrée, dans un cas, elle vous renvoie à la ligne, dans l’autre elle vous laisse après le bloc compléter. Ceci s’explique surement par des raisons historiques, mais c’est quand même bien dommage.
  • Pas de surbrillance des éléments. C’est une fonction bien agréable d’Eclipse. Vous placez le curseur sur une variable, une méthode, une exception et Eclipse vous montre son utilisation dans le code. C’est particulièrement pratique pour voir les références dans le code. Sous VS 2008, cette fonctionnalité n’explique tout simplement pas. Une horreur lorsqu’on a pris l’habitude de l’utiliser.
  • Presque pas de couleur. L’éditeur de MS ne fournit quasiment pas de couleur pour la syntaxe. Beaucoup de noir, un peu de bleu clair, un peu de bleu foncé et du vert pour les commentaires, c’est tout. Pas de mise en gras ou de souligné, pas d’autres couleurs. Ca rend le code peu lisible et peu engageant.
  • Une documentation en pseudo HTML avec des balises limitées. La javadoc .Net se crée avec des balises style HTML <summary> qui sont à moitié généré. A moitié car les fins de balise sont à écrire à la main. Déjà que les développeurs n’aiment pas écrire la documentation dans le code, avec VS 2008, on dirait que MS a fait exprès de les rebuter au maximum. En plus, il n’existe qu’un nombre très limité de balise et pas de author, since ou version. Comment voulez-vous faire dans ces conditions ?

Avec tous ses défauts, on se demande ce qu’on peut trouver à VS 2008. L’éditeur a 2 ans de retard sur ses concurrents directs (Eclipse et Netbeans). Il apprend et copie des autres, mais vraisemblablement pas assez vite.

Et avec tout ca, on vous raconte que l’environnement .Net vous permet d’être plus productif. Il va falloir me donner des arguments pour me le prouver !!

Heureusement j’ai lu qu’Eclipse allait permettre d’écrire du code .Net. Voila une très grosse concurrence pour VS2008. Vite c’est où qu’on récupère le plugin ?!!!

Les 7 règles d’or du développement

En naviguant sur le Web, viadeo en l’occurrence, je suis tombé sur un post de la société OCTO, qui propose un livre blanc concernant 12 règles pour booster votre productivité en java. Curieux par nature, je me suis dit que j’allais devenir encore plus productif que je ne le suis déjà, super.

Ah ah, dommage, en lisant rapidement le document, on s’aperçoit qu’il ne s’agit que des règles élémentaires du développement, même pas java d’ailleurs :

  • Utiliser un IDE, style Eclipse ;
  • Utiliser un gestionnaire de version, style CVS ;
  • Utiliser un bugtracker, style Bugzilla ;

C’est dommage, je pense qu’il y avait matière à donner des conseils plus avisés. Allez, comme je suis un gars investi et impliqué par son travail, ;-), je vous fais part de mes 7 règles d’or, vous me direz ce que vous en pensez.

les_7_regles_d_or_du_developpement_v0.6.7

Le site d’OCTO où trouver leur document : http://www.octo.com/com/com_Java-Productivity-Primer-white-paper-octo.html

%d blogueurs aiment cette page :