Discussion :

[Thomas Lebrun]

pour ce qui est des accolades je n'ai pas ce genre de problèmes vu que sur les claviers Azerty belge on les a avec altgr 9 et 0.

Pas besoin d'un clavier azerty belge pour ca : tous les clavier azerty le font avec altgr 9 et 0.

[Babylon]

bah je viens de regarder sur un azerty français et les accolades sont sur altgr 4 et la touche à coté du backspace

[Maniak]

L'auto-completion est plus présente avec VB, l'insertion des fin de constructeur automatique est un réèl gain de temps par rapport au {} qui ne sont pas les touches qui tombent le plus naturellement sous les doigts sur un clavier...

Aucun problème de mon côté, je tape en qwerty qui est bien plus pratique que l'azerty pour faire du C (ou n'importe quoi d'autre en fait, l'azerty est vraiment minable :). Que ce soit pour les accolades, les ponctuations, les chiffres, etc.

Il faudrait voir avec d'autre IDE si cela reste vrai.

Même pas besoin d'autres IDE. Plugin Visual Assist -> intellisense surboosté, beaucoup, beaucoup plus rapide pour rédiger que l'intellisense de base.

Sinon, la productivité, je ne crois pas que ça puisse se résumer à la vitesse de production de lignes de code. Loin de là même.

Exemple bête que j'ai eu l'occasion d'expérimenter plusieurs fois : une classe en VB.NET qui comporte un vingtaine ou trentaine de propriétés, et la même en C#. Ok, en VB.NET ça remplit les End Property/End Get/End Set tout seul, on peut gagner un peu de temps de rédaction grâce à ça. En revanche, on se retrouve avec des fichiers 2 fois plus longs (à peine exagéré si la classe en question contient essentiellement ces propriétés).

Exemple type, pour des propriétés très courantes se contentant de donner accès à des membres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
VB :
Public Property Toto() As String
  Get
    Return _toto
  End Get
 
  Set ( ByVal toto As String )
    _toto = toto
  End Set
End Property
 
C# :
public string Toto
{ get { return _toto; } set { _toto = value; } }

Ça, plus un saut de ligne entre propriétés, pour 20 propriétés, ça fait 200 lignes en VB.NET, 60 en C#. 80 si on met get et set sur deux lignes. Tout sur une seule ligne est une option aussi (40 lignes), mais là c'est un peu excessif quand même (enfin ça dépend des cas, ça peut rester très lisible, surtout si on aligne bien les noms d'une ligne à l'autre, chose qu'on ne peut pas faire en VB.NET, formatteur automatique oblige).

C'est légèrement plus pratique pour s'y retrouver après coup, non ? :)

Question lisibilité, c'est toujours subjectif, mais franchement, dans ce cas bien particulier, je vois mal comment on peut considérer la version VB.NET plus lisible (pas pour une propriété hein, pour 20). En plus de l'éternelle lourdeur de syntaxe. "Bonjour, je m'appelle Roger, je voudrais faire une propriété qui renvoit et modifie une chaine. J'y accède sans parenthèses, mais il faut quand même les mettre dans la déclaration. J'ai déjà dit qu'elle représente une chaine, mais il faut quand même le répéter pour le Set. Je ne mets qu'un Get pour qu'elle soit en lecture seule, mais il faut quand même ajouter ReadOnly."

Ok, ça se remplit plus vite, super, mais mes principales récriminations contre le côté verbeux du VB ne viennent pas du temps que ça met à taper, mais de l'impression de lire un roman particulièrement inintéressant après-coup :)
Les propriétés sont mon exemple favori pour ça, tellement l'écart est énorme. Et qu'on m'explique pourquoi MS empêche spécifiquement la possibilité d'utiliser ':' pour mettre Get et End Get sur la même ligne quand le code tient en 2 mots.

Dans mon cas, le temps éventuellement gagné pour pondre le code (minime, qwerty, VAssist et bonne vitesse de frappe aidant) est très, très largement compensé par le temps perdu en relecture. Et là, c'est à nouveau totalement subjectif :)

[Keihilin]

Même pas besoin d'autres IDE. Plugin Visual Assist -> intellisense surboosté, beaucoup, beaucoup plus rapide pour rédiger que l'intellisense de base.

J'connais pas ce plugin...C'est vraiment aussi bien que ça ? On le trouve où ?

Concernant les propriétés, j'suis assez d'accord avec toi sur le principe "d'inutilité" de toutes ces lignes...

Ca ne me gêne pas pour la lecture, mais c'est fastidieux à taper, même avec VS qui mâche le boulot.

Pour gagner du temps, j'utilise une macro pour construire cette partie de mes classes. J'ai juste à déclarer :

Private _Toto as String

et la propriété est créée toute seule sur demande (ctrl+P,ctrl+W = Read/write, ctrl+P,ctrl+R= Read only)...C'est peut être un des trucs qui me fait gagner le plus de temps...

[Maniak]

J'connais pas ce plugin...C'est vraiment aussi bien que ça ? On le trouve où ?

http://www.wholetomato.com/x/downloads/
C'est pas exempt de défauts, certaines options sont plus ou moins utiles selon les goûts, mais dans l'ensemble c'est sacrément pratique :)

Pour gagner du temps, j'utilise une macro pour construire cette partie de mes classes.

Ouaip, ça doit aider :)
Cela dit, ça n'empêche qu'au final, temps de frappe mis à part, on se retrouve avec des tonnes de lignes inutiles qui alourdissent (inutilement donc) la lecture.

Et vu que j'utilise beaucoup les propriétés et que je deviens déjà un peu hystérique quand les fichiers dépassent 300 lignes (même en utilisant #region pour aider un peu), l'idée de se retrouver avec 200 lignes juste pour lister quelques propriétés, c'est déjà suffisant pour me faire rejeter l'idée de faire du VB.NET volontairement :)

Doublé avec l'emploi de using que je considère comme impératif, la question ne se pose vraiment pas :)

[Thomas Lebrun]

bah je viens de regarder sur un azerty français et les accolades sont sur altgr 4 et la touche à coté du backspace

Oui, tu as raison : je sais pas alors d'où vient le clavier que g entre les mains

[austin49]

J'avais hésité à démarrer mon projet en VB.Net ou C#. J'ai finalement, bien fiat de choisir C#.

Pourquoi?
Parce que avec c#, on peut spécifier qu'un "event" ne doit pas être sérialisé ( Attribut [field : NonSerialize] devant l'évènement ), bizarrement en VB.Net, ce n'es pas possible.

Oufff

[alexischmit]

un réèl gain de temps par rapport au {} qui ne sont pas les touches qui tombent le plus naturellement sous les doigts sur un clavier...

franchement quand ta l'habitude de programmé (exemple en java) ces touches deviennent instinctives!

Sans parler des propriétés d'une classe...en VB.net, tu tapes une lignes et VS te complète toute la structure...Vu que généralement y en a beaucoup des propriétés...

quand une utilise c# avec visual studio c'est pareil il reconnait toutes les propriétés et toutes les methodes, je gain de temps est je pense identique. en tout cas c'est mieux qu'avec notePad!!

Allez au boulot tout le monde!!

[driard]

comme beaucoup d'entre vous le remarquent, malgré la grande ressemblance entre ces 2 langages, VB.NET est moins strict que C#.

Pour cette raison, et au regard des évolutions futures de ces deux langages (voir http://www.microsoft.com/france/vstu...-devtools.html), après en avoir longuement discuté avec de très nombreux clients, j'aurais tendance à répondre à ce vaste débat de la façon suivante :
- si vous connaissez déjà VB, allez vers VB.NET
- si vous connaissez déjà C++ ou Java, allez vers C#.

MAIS je tempérerais immédiatement ce conseil du fait qu'à mon avis, de par sa plus grande permissivité, VB.NET est mieux adapté à la conception de la couche d'affichage (écrans...) des applications, pour éviter les casts explicites à tout va, alors qu'ils n'apportent rien dans l'affichage, qui ne craint pas trop en terme de perfs et où les données ne sont pas réutilisées. A l'opposé, pour l'écriture de composants serveurs, de logique métier, et autres DLL, je privilégierais C# pour sa rigueur et une meilleure exploitation des concepts objet.

My 2 cents

[Keihilin]

j'aurais tendance à répondre à ce vaste débat de la façon suivante :
- si vous connaissez déjà VB, allez vers VB.NET
...

Cela peut paraître un peu surréaliste, mais on vient d'avoir un petit retour d'expérience qui tend à démontrer que cela peut être une erreur, même si ce choix est le plus naturel.
Nous avons eu pas mal de problèmes avec une équipe de développeur VB6 : Passage à .net, VB.net s'impose naturellement vu le background de l'équipe et...il a été très difficile de faire abandonner les "mauvaises habitudes" de VB6 et d'inculquer des notions correctes de POO à ceux qui n'en avait pas. En bref, si c'était à refaire, on imposerait C#, du moins au début.

...
VB.NET est mieux adapté à la conception de la couche d'affichage (écrans...) des applications.
...
A l'opposé, pour l'écriture de composants serveurs, de logique métier, et autres DLL, je privilégierais C# pour sa rigueur et une meilleure exploitation des concepts objet.

Tout à fait. (enfin sauf pour l'histoire des casts implicites...on fait du code propre partout ou on n'en fait pas !!)
J'ajouterais que VB s'impose pour les couches de présentation grâce à sa plus grande productivité. Même si certains "pro-C#" ne seront absolument pas d'accord ( hein Maniak ? ), je suis convaincu que pour le moment, Visual Studio rend VB.net plus productif que C# en "assistant" plus intensément le développeur lorsque en mode VB.

Sinon, je vois que c'est une approche assez souvent adoptée : C# pour tout ce qui est "réutilisable" (Composants, etc...), et VB.net pour le reste (Interfaces).

[Maniak]

J'ajouterais que VB s'impose pour les couches de présentation grâce à sa plus grande productivité.

Je ne suis absolument pas d'accord.

Même si certains "pro-C#" ne seront absolument pas d'accord ( hein Maniak ? :wink: ),

À ton service :)

je suis convaincu que pour le moment, Visual Studio rend VB.net plus productif que C# en "assistant" plus intensément le développeur lorsque en mode VB.

Et moi je suis convaincu que l'éventuel gain (qui peut très bien exister, ça je ne conteste pas) est loin d'être suffisant pour se trainer un langage spécifiquement pour une partie du développement, soit-disant non-réutilisable, avec lequel les habitués de VB ont un mal de chien à se mettre à la POO et risquent fortement de produire du code fortement bancal.

C# est plus strict et rigoureux, ça c'est un fait que même les pro-VB ne peuvent pas nier (chacun son tour :), et je ne vois pas en quel honneur les interfaces (ou quoi que ce soit) gagneraient à être faites de manière moins rigoureuse.

Tu dis "on fait du code propre partout ou on n'en fait pas", je complète avec "on est rigoureux partout ou on ne l'est pas" :)

VB.NET pour les interfaces et C# pour le reste, c'est un jonglage entre langages totalement inutile.

[Keihilin]

J'ajouterais que VB s'impose pour les couches de présentation grâce à sa plus grande productivité.

Je ne suis absolument pas d'accord.

Mdr. Je l'aurai parié !

C# est plus strict et rigoureux, ça c'est un fait que même les pro-VB ne peuvent pas nier (chacun son tour

Je ne suis pas pro-VB, mais je ne le nie pas.

et je ne vois pas en quel honneur les interfaces (ou quoi que ce soit) gagneraient à être faites de manière moins rigoureuse.

Tu dis "on fait du code propre partout ou on n'en fait pas", je complète avec "on est rigoureux partout ou on ne l'est pas"

VB.NET pour les interfaces et C# pour le reste, c'est un jonglage entre langages totalement inutile.

Simple question de productivité...rien d'autre.

Je ne dis pas que ce choix est la panacée universelle et que tout le monde devrait faire comme ça, je me borne à constater que c'est une orientation assez souvent prise.

Tu sembles quand même oublier une chose : on est d'accord que C# oblige à une certaines rigueur, mais VB.net n'empêche pas d'être aussi strict et rigoureux, même s'il est plus permissif à la base.

[bidou]

VB.NET pour les interfaces et C# pour le reste, c'est un jonglage entre langages totalement inutile.

Je partage cet avis.
Sans rentrer dans l'aspect verbeux ou non du langage, je ne vois pas l'intérêt de mélanger les deux langages.
Il est tout à fait possible d'écrire un code propre en VB.NET, et moi j'écris mon code (réutilisable ou non) en VB.NET, car je suis (par habitude) plus productif en VB.
Au jour d'aujourd'hui, il est clair que C# possède une meilleure capacité à utiliser le Framework. Néanmoins, MS corrige le tir dans la prochaine version (Whidbey) avec par exemple l'arrivée des Using en VB.

[abelman]

A propos du using. Personnellement je trouve son utilisation plutot "dangereuse". Je suis en effet de ceux qui préfère voir les instructions de nettoyage de ressources écrites explicitement.

[Keihilin]

et moi j'écris mon code (réutilisable ou non) en VB.NET, car je suis (par habitude) plus productif en VB.

Et ça t'embête pas plus que ça de ne pas avoir les commentaires XML pour un code réutilisable ?

[Maniak]

Les instructions de nettoyage de ressources sont écrites explicitement dans les méthodes Dispose. using permet juste de s'assurer qu'elles sont appelées, donc de ne plus avoir à y penser. Ce n'est plus la responsabilité du développeur, mais celle des objets. Un pas de plus en direction de la POO en somme :)

Sans parler de l'assurance que ces instructions de nettoyage seront appelées quoi qu'il arrive, même s'il y a des exceptions, des sorties de boucles/fonctions en cours de route etc.

[abelman]

et moi j'écris mon code (réutilisable ou non) en VB.NET, car je suis (par habitude) plus productif en VB.

Et ça t'embête pas plus que ça de ne pas avoir les commentaires XML pour un code réutilisable ?

Il y a des outils tierce qui le font plus ou moins bien. Et ce sera inclus pour VB dans Whidbey

[Keihilin]

Il y a des outils tierce qui le font plus ou moins bien. Et ce sera inclus pour VB dans Whidbey

Plutôt moins que plus.

Putain il serait temps que ce soit disponible en VB !!
C'est vraiment LE truc qu'il manque à VB depuis le début de .net.
J'ai jamais compris ce choix d'inclure ça dans C# seulement...

[abelman]

Les instructions de nettoyage de ressources sont écrites explicitement dans les méthodes Dispose. using permet juste de s'assurer qu'elles sont appelées, donc de ne plus avoir à y penser. Ce n'est plus la responsabilité du développeur, mais celle des objets. Un pas de plus en direction de la POO en somme

Sans parler de l'assurance que ces instructions de nettoyage seront appelées quoi qu'il arrive, même s'il y a des exceptions, des sorties de boucles/fonctions en cours de route etc.

Justement dans le code, je trouve qu'il est préférable de voir l'appel du Dispose (ou du Close). Si tu prends la classe SqlConnection par exemple, faire un using sur une instance de cette classe veut dire que tu n'appelles pas explicitement le Close dessus une fois que tu a finis de l'utiliser.
Je préfère vérifier la symétrie des appels Open /Close que de me dire que le "using sous entend que le Close sera appellé automatiquement".
De plus l'utilisation du Using n'entraine t elle pas une identation en plus ? qu'en est il si tu dois utiliser plusieurs using sur des dans la même fonction ? tu identes à chaque fois ?

[Maniak]

Et ce sera inclus pour VB dans Whidbey

Juste une petite note au passage, vu que les "ce sera inclus dans Whidbey" qui commencent à se multiplier : dans les entreprises qui ont investi dans VS.NET 2003, combien vont se jeter sur Whidbey quand il sortira ?

Déjà que le passage de VS.NET 2002 à 2003 n'est même pas fait partout, d'ici à ce que tout le monde soit sur Whidbey, faut peut-être pas s'empresser de prendre des décisions avec VS.NET 2003 qui ne vaudront que pour Whidbey (et pas directement réutilisables, vu que les projets développés sous 2003 resteront probablement sous 2003, pour éviter le redéveloppement qui sera nécessaire pour la prochaine version du framework).

Donc bon. Là on en est à VS.NET 2003, avec du 2002 qui traine encore un peu, autant s'en tenir à ça pour les discussions. Whidbey sera peut-être tout beau tout neuf avec plein de trucs en plus qui changeront la donne, mais il est encore loin, donc en gros : on s'en tape. Les décisions à prendre pour les projets de là, maintenant, sont à prendre par rapport à la situation là, maintenant.