Que choisir ? C# , VB.NET, C++, Delphi ? pourquoi ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

23/03/2004, 13h05
Piotrek

Merci pour l'eclaircissement, je crois que je vais passer a c# alors
(joke :) )

et bon courage!
23/03/2004, 13h12
Maniak

Citation:

Envoyé par Babylon

Personnellement je suis plus beaucoup plus pour la syntax du C# (avis personnel) mais je vais devoir me plier devant le choix du plus grand nombre vu que les autres sont purs VB.

Dans ce cas, essaye au moins d'obtenir qu'ils n'utilisent pas ce qui se trouve dans le namespace Microsoft.VisualBasic, et qu'ils fassent tout en Option Explicit + Strict.
Sinon les mauvaises habitudes données par le VB sont toujours là. C'est déjà crade pour du procédural, mais pour de la POO ça peut devenir carrément monstrueux (en plus de donner du code VB-only, absolument pas portable si un jour béni arrive où ça pourra passer au C# :)

Ah, pour le using (la version non-équivalente d'Import), ce n'est pas qu'une facilité d'écriture, c'est une grande aide pour une gestion de ressources propre, qui est généralement zappée en VB.NET.

Parce qu'utiliser using en C# est ultra-simple, il n'y a aucun problème à l'utiliser partout où c'est possible. Donc aucun problème à s'assurer que les ressources sont toujours libérées dès que possible, bref que tout ça soit vraiment propre. L'équivalent en VB.NET étant de tout encastrer dans des blocs Try/Finally + appel manuel à Dispose, c'est beaucoup trop lourd pour être utilisé en pratique.

C'est pas mortel, le garbage collector passe derrière de toute façon, c'est juste bien moins propre et pratique.

Mais bon, si tu n'as pas le choix, tant pis, VB.NET ce sera. Du moment que Microsoft.VisualBasic est banni et que Option Explicit et Strict sont activés.
23/03/2004, 13h46
Keihilin

Citation:

Envoyé par Maniak

L'équivalent en VB.NET étant de tout encastrer dans des blocs Try/Finally + appel manuel à Dispose, c'est beaucoup trop lourd pour être utilisé en pratique.

J'suis pas d'accord. Try/Finally plus lourd que Using ? C'est ton aversion pour VB qui te fait parler là :)

Citation:

Envoyé par Maniak

C'est pas mortel, le garbage collector passe derrière de toute façon, c'est juste bien moins propre et pratique.

Mais bon, si tu n'as pas le choix, tant pis, VB.NET ce sera. Du moment que Microsoft.VisualBasic est banni et que Option Explicit et Strict sont activés.

Entièrement d'accord sur ce point.

Je citerais quand même quelques points à l'avantage de VB :

:arrow: With / End With

:arrow: Le code VB est (avis personnel souvent partagé) un peu plus facile à (re)lire...

:arrow: Arguments optionnels
23/03/2004, 13h53
Babylon

:arrow: question lisibilité de langage ça dépend du background de chacun :
pour prendre mon expérience personnelle, j'ai fait du C, du C++, un peu de java et pas mal de PHP, ce qui fait que pour moi la syntaxe du C# est nettement plus lisible (habitude) qu'un langage de type verbeux comme VB.

:arrow: With / end Width : c'est quelque chose que je n'aime pas du tout, ça doit aussi venir du background

:arrow: Arguments optionnels : du point de vu de la POO ce n'est pas mieux de faire une "surcharge" (encore une fois je ne suis pas sûr d'utiliser le bon terme) de méthode ?
23/03/2004, 14h22
Keihilin

Citation:

Envoyé par Babylon

question lisibilité de langage ça dépend du background de chacun

Oui ok, c'est une question d'habitude. Mais en étant tout à fait objectif, VB est plus lisible. En régle générale les trucs du genre [Sub / End Sub], [If / Else / End if], etc...permettent de plus vite s'y retrouver dans un code complexe et inconnu. T'as qu'à supprimer l'indentation pour t'en convaincre. :wink:

Citation:

Envoyé par Babylon

:arrow: With / end Width : c'est quelque chose que je n'aime pas du tout, ça doit aussi venir du background

Ben pourtant, bonjour l'économie de frappe dans beaucoup de cas...
J'aime mieux ça que le copier/coller, et que le chercher/remplacer quand par malheur le nom de l'objet change pour une raison ou pour une autre.

Citation:

Envoyé par Babylon

:arrow: Arguments optionnels : du point de vu de la POO ce n'est pas mieux de faire une "surcharge" (encore une fois je ne suis pas sûr d'utiliser le bon terme) de méthode ?

Je ne suis pas certain que cette question soit du ressort des principes de POO.
Dans la pratique, les arguments optionnels sont un confort, rien de plus.
En C#, tu vas surcharger tes méthodes autant de fois que nécessaires, chaque méthode copiera les paramètres dans des variables de class et appellera une méthode "finale"...

En VB tu n'écris qu'une seule méthode...c'est un poil plus léger.
23/03/2004, 15h30
Maniak
Citation:

Envoyé par Keihilin

Citation:

Envoyé par Maniak

L'équivalent en VB.NET étant de tout encastrer dans des blocs Try/Finally + appel manuel à Dispose, c'est beaucoup trop lourd pour être utilisé en pratique.

J'suis pas d'accord. Try/Finally plus lourd que Using ? C'est ton aversion pour VB qui te fait parler là :)

Euh non, vraiment pas :)
Code:

1 2 3 4 using ( Toto toto = new Toto() ) { ... }
Code:

1 2 3 4 5 6 Try Dim toto As Toto = New Toto() ... Finally toto.Dispose() End Try
Non seulement c'est plus lourd (lourdeur innée de la syntaxe VB :), mais surtout, ça oblige à appeler Dispose à la main. Faut y penser. C'est pas forcément gagné :)
Avec using, on n'a plus à y penser, et tout ce ki réduit ce à quoi il faut penser est sacrément positif :)

Citation:

Envoyé par Keihilin

Je citerais quand même quelques points à l'avantage de VB :

:arrow: With / End With

Beurk. S'il y a de gros blocs qui nécessitent l'emploi de With, ça indique le besoin d'une méthode. Si ce sont de petits blocs, ça gêne la lecture plus qu'autre chose.

Citation:

Envoyé par Keihilin

:arrow: Le code VB est (avis personnel souvent partagé) un peu plus facile à (re)lire...

Autre avis personnel souvent partagé : oula non, c'est tellement verbeux que c'est extrêmement lourd à lire :)

Citation:

Envoyé par Keihilin

:arrow: Arguments optionnels

L'overloading est fait pour ça dans un contexte OO. Les arguments optionnels sont un reste de programmation procédurale :)
23/03/2004, 15h37
Babylon

je pense qu'il serait bon d'arrêter là, sinon ça va repartir comme au début de la discution.
23/03/2004, 15h52
Maniak

Citation:

Envoyé par Keihilin

Mais en étant tout à fait objectif, VB est plus lisible.

Euh non, vraiment pas :)
Y a pas d'objectivité là-dessus. C'est du 100% subjectif :)
Quand je dis que pour moi la syntaxe du VB est beaucoup moins lisible, c'est vraiment ce que je pense hein, pas pour le plaisir de critiquer VB. Et je ne suis pas le seul dans ce cas :)

C'est très certainement une question d'habitude, et la syntaxe du VB est très certainement plus facilement compréhensible pour quelqu'un qui vient de débarquer en programmation. Maintenant à moins que ce quelqu'un veuille rester au stade de débutant, c'est pas quelque chose qui devrait le refroidir (surtout quand on y gagne en clareté après, ça aussi c'est subjectif mais ça ne m'empêche pas d'en être totalement convaincu :)

Citation:

Envoyé par Keihilin

Citation:

Envoyé par Babylon

:arrow: With / end Width : c'est quelque chose que je n'aime pas du tout, ça doit aussi venir du background

Ben pourtant, bonjour l'économie de frappe dans beaucoup de cas...

J'adore entendre parler d'économie de frappe avec la syntaxe du VB, t'as pas idée à quel point ça a tendance à me plier de rire instantanément :)

Et donc cf mon précédent post pour ce point.

Citation:

Envoyé par Keihilin

Citation:

Envoyé par Babylon

Arguments optionnels

Je ne suis pas certain que cette question soit du ressort des principes de POO.

Les arguments optionnels signifie qu'une même méthode pourrait répondre à plusieurs interfaces. Ça ne cadre pas. Ça implique aussi que les méthodes avec paramètres optionnels doivent tester si tel ou tel paramètre est présent ou non. Super le confort.

À ne pas confondre avec les paramètres par défaut comme en C/C++. Dans ce cas-là, les paramètres sont toujours là, il n'y a pas de traitement particulier à faire.

Ce n'est pas du ressort de la PO. C'est du ressort de la (non-)propreté du code :)

Citation:

Envoyé par Keihilin

En C#, tu vas surcharger tes méthodes autant de fois que nécessaires, chaque méthode copiera les paramètres dans des variables de class et appellera une méthode "finale"...

Vi, et la méthode finale saura que tous les paramètres sont bien présents, sans avoir à faire de cas particuliers pour ça. Ce qui est bien plus propre. 1 méthode = 1 façon de l'appeler.

Citation:

Envoyé par Keihilin

En VB tu n'écris qu'une seule méthode...c'est un poil plus léger.

Enième facilité syntaxique qui pousse dans la direction des mauvaises pratiques :)
23/03/2004, 16h00
Keihilin
Citation:
Envoyé par Maniak

Code:

1 2 3 4 using ( Toto toto = new Toto() ) { ... }

Code:

1 2 3 4 5 6 Try Dim toto As Toto = New Toto() ... Finally toto.Dispose() End Try

Non seulement c'est plus lourd (lourdeur innée de la syntaxe VB :), mais surtout, ça oblige à appeler Dispose à la main. Faut y penser. C'est pas forcément gagné :)
Avec using, on n'a plus à y penser, et tout ce ki réduit ce à quoi il faut penser est sacrément positif :)
Blablabla...Mais quelle mentalité d'assisté ! J'y crois pas ! :D :wink:

Citation:

Envoyé par Maniak

:arrow: With / End With
Beurk. S'il y a de gros blocs qui nécessitent l'emploi de With, ça indique le besoin d'une méthode. Si ce sont de petits blocs, ça gêne la lecture plus qu'autre chose.

Mauvaise fois évidente du CSharpFanatiste (oui, j'fais des néologismes si j'veux !) :D
Code:

1 2 3 4 5 6 7 8 9 With myObject.mySubObject .Property1=1 .Property2=2 ... End With
Tu trouves que ça gêne la lecture ?
Je pense que c'est juste une faute de frappe de ta part. Tu voulais écrire "ça facilite la lecture en aérant le code", mais tes doigts ont dérapé...T'excuse pas, je t'accorde le bénéfice du doute. :wink:

Citation:

Envoyé par Maniak

Citation:

Envoyé par Keihilin

:arrow: Le code VB est (avis personnel souvent partagé) un peu plus facile à (re)lire...

Autre avis personnel souvent partagé : oula non, c'est tellement verbeux que c'est extrêmement lourd à lire :)

Bon, on va arrêter de débattre sur ce point précis, s'agissant définitivement d'une question de goûts et de couleurs (et de myopie avancée pour ceux qui trouve le code VB illisible)

Citation:

Envoyé par Maniak

L'overloading est fait pour ça dans un contexte OO. Les arguments optionnels sont un reste de programmation procédurale :)

Je ne vois pas en quoi les arguments optionels iraient à l'encontre des principes POO ?!

J'suis sûr que si C# les avaient mais pas VB tu trouverais ça très bien ! Hein ?! Avoue ! :D

Citation:

Envoyé par Babylon

je pense qu'il serait bon d'arrêter là, sinon ça va repartir comme au début de la discution.

Ben que ça reparte...Un bon débat inutile entre gens de bonne compagnie, ça nous change du HelpDesk !
23/03/2004, 16h05
Babylon

moi je dis ça, je dis rien.

pour les params optionnels, comme l'a dit Maniak, c'est bon pour le procédural pas pour la POO, sinon l'overloading n'aurait pas été mis en place.

et pour ce qui est de la lisibilité, je le crie haut et fort : LE VB EST ILLISIBLE (enfin pour moi)
23/03/2004, 16h08
Maniak

Citation:

Envoyé par Keihilin

Blablabla...Mais quelle mentalité d'assisté ! J'y crois pas ! :D :wink:

C'est un des principes auxquels je m'efforce de tenir le plus :)
Y a suffisamment de choses à gérer pour ne pas s'encombrer de trucs inutiles :)

Ah pi j'avais oublié un autre défaut du Try/Finally : les exceptions c'est gentil, mais c'est pas super performant :)

Citation:

Envoyé par Maniak

Mauvaise fois évidente du CSharpFanatiste (oui, j'fais des néologismes si j'veux !) :D

Non non, ça c'est un principe de POO (enfin plutôt un principe de refactorisation, j'ai tendance à relier les deux :).
Plein de lignes de suite passant par des accesseurs à un objet -> méthode à ajouter dans la classe (surtout quand il s'agit de copier les champs etc :)

Et oui, je trouve moins lisible d'avoir des .BlaBla que d'avoir le nom de l'objet juste devant. Bien plus clair comme ça, et intellisense & co ne sont pas faits pour les chiens. Y a jamais besoin de taper le nom complet chaque fois, alors le gain en temps de frappe est discutable :)
(là je suis aidé, j'ai Visual Assist pour faciliter grandement l'écriture de code :)

Et oui, c'est encore un point subjectif, donc là on peut éviter de rallonger le topic pour rien, ça a quand même peu d'importance (même si les gens sensés peuvent argumenter que la syntaxe illisible du VB ne nécessite même pas de débat :)

Citation:

Envoyé par Keihilin

Je ne vois pas en quoi les arguments optionels iraient à l'encontre des principes POO ?!

1 méthode = 1 forme d'appel :)

Citation:

Envoyé par Keihilin

J'suis sûr que si C# les avaient mais pas VB tu trouverais ça très bien ! Hein ?! Avoue ! :D

J'aimerais beaucoup que le C# aient les paramètres par défaut oui. Mais les paramètres optionnels, qu'ils restent dans le VB et qu'ils meurent avec :)

Citation:

Envoyé par Keihilin

Ben que ça reparte...Un bon débat inutile entre gens de bonne compagnie, ça nous change du HelpDesk !

Surtout dans des journées comme aujourd'hui :)
23/03/2004, 16h15
Keihilin
Citation:

Envoyé par Maniak

J'adore entendre parler d'économie de frappe avec la syntaxe du VB, t'as pas idée à quel point ça a tendance à me plier de rire instantanément :)

Ouais, je ne peux qu'être d'accord. La synthaxe C# est beaucoup plus légère. Alors justement, les trucs comme With/End With qui permette à VB d'alléger un peu la sienne c'est du tout bon...

Citation:

Envoyé par Maniak

Les arguments optionnels signifie qu'une même méthode pourrait répondre à plusieurs interfaces. Ça ne cadre pas.

Euh...faux ! CF : Point suivant

Citation:

Envoyé par Maniak

Ça implique aussi que les méthodes avec paramètres optionnels doivent tester si tel ou tel paramètre est présent ou non. Super le confort.

À ne pas confondre avec les paramètres par défaut comme en C/C++. Dans ce cas-là, les paramètres sont toujours là, il n'y a pas de traitement particulier à faire.

Ben ça tombe bien que t'en parles, parce qu'un paramètre optionnel en VB.net ça s'utilise comme ça :
Code:

1 2 3 4 5 Public Sub DoSmth(ByVal p1 As String, Optional p2 As String = "ABC") ... End Sub
et l'indication d'une valeur par défaut est OBLIGATOIRE !
Donc elle est où la différence avec les paramètres par défaut du C++ ?
23/03/2004, 16h39
neo.51
j'aurais jamais du dévérouiller le thread :lol:

Bon moi aussi je m'y remet, car je vois que quand même je ne suis pas le seul à trouver le VB.NET plus lisible que du C# !!!!

Déjà ne serais ce que pour attacher une méthode à un events:

en VB.NET :

Code:

Public Sub rechercher_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles rechercher.Click

En C#
Code:

1 2 this.DataGrid1.ItemCommand += new System.EventHandler(this.DataGrid1_ItemCommand);
au chargement

et
Code:

1 2 3 public void rechercher_Click(System.Object sender, System.EventArgs e) { }
en gros j'ai 50 évènement à gérer je me retrouve avec 50 lignes de déclarations d'évènement au chargement et aprés toutes mes méthodes !!!

Je veux bien que les puristes veuillent que tous les évènement soit déclarés avant le chargement, mais bon niveau lisibilitée, je vois pas en quoi le C# devient plus lisible ici ;)

Aprés qu'on me dise que VB.NET est plus "verbeux" soit, mais bon quand on a vs.net et des variable bien nommées, on fait

Code:

Me.

et on va chercher ce dont on a besoin avec l'intelisense

Les try catch et finaly, tu tape try, t'appuis sur la touche entrer et tout le squelette se fait tout seul.

Toujours au niveau lisibilitée, prennons 2 extraits de code VB.NET et C#

VB.NET
Code:

1 2 3 End Try End IF End Sub
C#
Code:

1 2 3 } } }
:lol:

Donc VB.NET plus verbeux OUI, mais compensé par l'intellisense quand on a un bon IDE et With/End with. Mais dire que c'est moins lisible c'est de la mauvaise fois :lol:
23/03/2004, 16h55
Keihilin

Citation:

Envoyé par neo.51

j'aurais jamais du dévérouiller le thread :lol:

Attend voir, j'ai cru voir marquer "Forum de discussions" quelque part par ici... :D
Ah ben oui, c'est bien ça...c'est pas marqué "forum de helpdesk", alors on va pas commencer à vérouiller les débats. fussent-ils complètement inutiles comme celui-ci, mdr !

Citation:

Envoyé par neo.51

Donc VB.NET plus verbeux OUI, mais compensé par l'intellisense quand on a un bon IDE et With/End with. Mais dire que c'est moins lisible c'est de la mauvaise fois :lol:

Ben oui c'est évident...

Bon, moi j'ai résolu le problème du choix du language, je code directement en MSIL. 8) :wink:
23/03/2004, 17h03
freegreg

Citation:

Envoyé par neo.51

j'aurais jamais du dévérouiller le thread :lol:

Je crois aussi :wink:

Citation:

Envoyé par neo.51

Mais dire que c'est moins lisible c'est de la mauvaise fois

:nono: Pour moi aussi, c'est moins lisible!
Rien ne sert de continuer sur des palabres qui ne menent nul part! Certaines personnes préfèrent lire du VB d'autres (J'en fait parti :wink: ) le C#, c'est un fait et personne n'y changera rien!
C'est un peu comme les goûts et les couleurs. Et croyez-moi coté couleurs, je m'y connais, je suis daltonien!! :wink:

Le principal est de bien structurer son code, c'est tout.

Citation:

Envoyé par Keihilin

je code directement en MSIL.

:rire:
23/03/2004, 17h21
Keihilin

Citation:

Envoyé par freegreg

Citation:

Envoyé par Keihilin

je code directement en MSIL.

:rire:

Ouais...Je trouvais le C# beaucoup trop verbeux :wink: mdr.

Non, c'est vrai, les discussions sur la lisibilité c'est une question de goûts.

D'autre part, les petits points de "facilité" comme le With/End With sont largement gommés par le confort apporté par Visual Studio.

Maintenant dans la pratique, je pense que le débat peut s'orienter dans 2 directions :

1. Je suis un développeur, je veux me mettre à Dotnet, quel langage choisir ?

2. Je suis un chef de projet, je dois démarrer un développement, quel langage choisir ?

Au 1., je répond sans hésiter : les deux !

Les principales difficultés dans le passage à .net résident dans l'apprentissage de la POO (si on ne connait pas déjà), et des centaines de classes offertes par le framework.
Alors une fois que c'est fait, commencer par C# et passer à VB ou l'inverse, c'est l'histoire de 2 jours...

Je suis consultant, développeur freelance. Des projets, j'en vois passer un certain nombre au cours d'une année, et même au sein d'une même société, il n'y a pas toujours de choix définitif pour un langage ou l'autre...Un jour c'est VB, le suivant c'est C#...Devant un recruteur qui ne s'y connait pas, pouvoir dire qu'on code indifféremment avec l'un ou l'autre est important.

Pour le point 2.

Je ne vois pas la nécessité d'imposer un langage. L'important est de pouvoir réutiliser les briques applicatives...alors qu'elles soient en VB ou en C#, quelle importance ?
23/03/2004, 17h46
Maniak
Citation:

Envoyé par Keihilin

Ouais, je ne peux qu'être d'accord. La synthaxe C# est beaucoup plus légère. Alors justement, les trucs comme With/End With qui permette à VB d'alléger un peu la sienne c'est du tout bon...

Ou du moins mauvais :)
(ok j'arrête :)
Citation:
Envoyé par Keihilin

Ben ça tombe bien que t'en parles, parce qu'un paramètre optionnel en VB.net ça s'utilise comme ça :

Code:

1 2 3 Public Sub DoSmth(ByVal p1 As String, Optional p2 As String = "ABC") ... End Sub

et l'indication d'une valeur par défaut est OBLIGATOIRE !
Donc elle est où la différence avec les paramètres par défaut du C++ ?
Tiens, c'est nouveau de VB.NET ça ?
Bon ben si c'est bien comme ça, on peut donc résumer que les paramètres optionnels de VB6- sont à jeter, et dans VB.NET, malgré la syntaxe toujours aussi lourde, c'est un point positif :)
(et que les paramètres par défaut sont bien un des trucs qui manquent le plus au C#, sans raison en plus, grmpf :)

Citation:

Envoyé par neo.51

Déjà ne serais ce que pour attacher une méthode à un events:
...
Je veux bien que les puristes veuillent que tous les évènement soit déclarés avant le chargement, mais bon niveau lisibilitée, je vois pas en quoi le C# devient plus lisible ici ;)

Pas plus lisible non, plus utilisable. Permettant de voir rapidement tous les événements gérés, de qui, par quoi, ainsi que d'y affecter des gestionnaires d'événements d'autres objets. Parce que là, VB.NET repasse sur une syntaxe proche de celle du C#, mais en plus lourd :)

En C#, c'est clair et net, tout se fait pareil, au même endroit, sans forcer à chercher dans tout le code pour voir où est géré tel événement :)

Citation:

Envoyé par neo.51

Aprés qu'on me dise que VB.NET est plus "verbeux" soit, mais bon quand on a vs.net et des variable bien nommées, on fait

Les noms de variables ne dépendent pas du langage, donc c'est pas un problème :)

Citation:

Envoyé par neo.51

Toujours au niveau lisibilitée, prennons 2 extraits de code VB.NET et C#
...

Et c'est toi qui parle de mauvaise foi ? :)
Sans indentation 1) aucun langage n'est lisible, 2) c'est du code de merde (et ça c'est indiscutable hein :), bref c'est totalement hors de propos :)

Et si tu y mets de l'indentation, repérer des accolades bien alignées est bcp plus rapide et clair que de chercher des mots-clefs.
Mais on retombe sur l'habitude et les goûts persos, donc basta :)

Mais bon, sacrée mauvaise foi de ta part sur ce coup-là, honte sur toi :)
24/03/2004, 08h44
Piotrek

On a tous notre passif de programmeur, franchement la "lisibilite" c'est vraiement un parametre personnel, le but c'est juste d'accepter le fait que d'autres pensent pas comme nous et que personne ne possede la verite vraie unique.

En resume : retournez bosser ! ( :D )
24/03/2004, 09h12
Keihilin

Ben tiens, hier soir je me suis amusé à faire un petit test de "productivité" pour comparer C# et VB.net...

Principe de l'exercice : Ecrire une petite bibliotheque de classes, d'abord dans un des languages en chronométrant, puis dans l'autre.

J'ai choisi un truc qui permettait d'utiliser un peu tout les types d'objets : des classes, des enums, des exceptions, des évenements...bref, j'ai écrit un p'tit DataAccessHelper introspectif.

- Pas de problèmes de "reflexion technique", étant un sujet moult fois abordé dans les projets.
- Mêmes nom de variables pour les deux projets.

C# : 25mn
VB.net : 18mn

Ce qui est drôle, c'est qu'avant de commencer j'imaginais plutôt un résultat inverse. D'expérience je pensais bien que ce serait très proche, mais je voyais la balance pencher en faveur de C#.

A quoi c'est du ? Ben à Visual Studio, tout simplement.

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

Donc, malgré sa synthaxe plus {lourde | verbeuse }, VB.net semble quand même plus productif, du moins avec Visual Studio. Il faudrait voir avec d'autre IDE si cela reste vrai.
24/03/2004, 09h15
Babylon

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.

PS : et non je ne suis pas belge
24/03/2004, 10h40
Thomas Lebrun

Citation:

Envoyé par Babylon

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. :wink:
24/03/2004, 10h42
Babylon

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

Citation:

Envoyé par Keihilin

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.

Citation:

Envoyé par Keihilin

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:

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

24/03/2004, 11h08
Keihilin

Citation:

Envoyé par Maniak

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...
24/03/2004, 11h17
Maniak

Citation:

Envoyé par Keihilin

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

Citation:

Envoyé par Keihilin

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 :)
24/03/2004, 11h29
Thomas Lebrun

Citation:

Envoyé par Babylon

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

8O

Oui, tu as raison : je sais pas alors d'où vient le clavier que g entre les mains :?
25/03/2004, 18h11
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
08/04/2004, 17h25
alexischmit

Citation:

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!

Citation:

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!!
12/04/2004, 19h47
driard

A chaque langage son utilité

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
13/04/2004, 09h49
Keihilin

Re: A chaque langage son utilité

Citation:

Envoyé par driard

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.

Citation:

Envoyé par driard

...
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 ? :wink: ), 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).
13/04/2004, 10h16
Maniak

Re: A chaque langage son utilité

Citation:

Envoyé par 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.

Citation:

Envoyé par Keihilin

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

À ton service :)

Citation:

Envoyé par Keihilin

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.
13/04/2004, 10h26
Keihilin

Re: A chaque langage son utilité

Citation:

Envoyé par Maniak

Citation:

Envoyé par 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é ! :D

Citation:

Envoyé par Maniak

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.

Citation:

Envoyé par Maniak

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.
13/04/2004, 10h27
bidou

Re: A chaque langage son utilité

Citation:

Envoyé par Maniak

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.
13/04/2004, 10h34
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.
13/04/2004, 10h38
Keihilin

Re: A chaque langage son utilité

Citation:

Envoyé par bidou

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 ?
13/04/2004, 10h38
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.
13/04/2004, 10h41
abelman

Re: A chaque langage son utilité

Citation:

Envoyé par Keihilin

Citation:

Envoyé par bidou

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
13/04/2004, 10h44
Keihilin

Re: A chaque langage son utilité

Citation:

Envoyé par abelman

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...
13/04/2004, 10h47
abelman

Citation:

Envoyé par 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.

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 ?
13/04/2004, 10h51
Maniak

Re: A chaque langage son utilité

Citation:

Envoyé par abelman

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.

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 13h36.