Discussion :

[SesechXP]

Je ne prendrai pas cela pour une argumentation percutante étant donné que, programmant en VB.NET, je n'ai aucun mal à appliquer des solutions trouvées en C# : quand on comprend la logique d'un code, peu importe le langage de programmation

Bien sûr, je fais parfois l'inverse : je regarde des solutions VB.net que j'applique en C#. Ce critère a surtout été important pour privilégier C# et VB.net face à Delphi.

Mais la communauté a tout de même été un critère pour mon choix, après les gens le considèrent comme valable ou non...

++

[lapec_and_cie]

Salut,

OK je suis d'accord que les communautés autour des des langages Microsoft sont bien plus importantes que celle autour de Delphi. Mais celle-ci tend à se développer...
D'autre part retranscrire un code VB en Delphi, voire C# en Delphi ne pose aucun problème tant que l'on a compris ce que doit faire le programme dans les grandes lignes (je veux dire par là l'algorithme). Après tout est une question de syntaxe...
En plus certaines solutions sont propres à la plateforme .Net et donc indépendantes du langage utilisé, prenez par exemple le problème de signature d'une assembly, il est révélateur: posté dans le forum Delphi.Net, j'ai vu des utilisateurs C# poser une question à ce sujet ....
Non .Net, à mon avis, est fait pour rassembler les communautés de développement.
Et le débat sur tel ou tel langage fait mieux que tel ou tel langage est de nos jours révolu. Si on prend des langages comme VB ou même le Pascal Objet qui était réputé facile pour débuter dans la programmation, mais qui ne faisaient pas le poids face à C++, pour les applications lourdes. Aujourd'hui ce fait n'a plus lieu d'être, vu la puissance des machines, les compilos de plus en plus fiables, robustes et rapides... Donc je rejoins certains qui disent qu'il faut choisir son langage selon ses affinités...

A plus,

Chris...

[Hatchepsout]

bon pour moi je préfére vb.net parsque c'est le seul languge que je connait parmi eux peut etre dans le future j'appris les autres
bon j'ai programer avec c mais pas c++ peut etre dans le future aussi .

[mesdouri]

bonjour

a mon avis peu importe le langage que ca sois le vb.net ou le c#...d'ailleur moi je cree des library en c# et je les exploite en vb.net et vice versa et tout ca grace a l'interoperabilité entre tous les langages .NET
a vrai dire on produit tous du code MSIL.

il faut surtout se soucier de la maniere avec laquelle on programme

[Process Linux]

Dans mon cas, je travail dans une SSII, et nous avons adopté une logique claire pour le choix entre VB.net et C#.net.

Pour chaque projet .NET, le développement des couches model, métier et persistance se fait toujours en C#, et on laisse la présentation en VB.net.

Car par experience, la syntaxe de C# est plus rigoureuse car la compilation fait beaucoup attention aux opération de cast qu'il faut tout le temps mettre explicitement. Et comme les couches modèl, métier et persistance demandent beaucoup de rigueur, on met toujours les développeurs C# (qui proviennent de C++ / java) sur ces parties. Et on met les développeurs VB.NET (qui proviennent de vb6 ...) sur la partie présentation.

[FremyCompany]

Dans mon cas, je travail dans une SSII, et nous avons adopté une logique claire pour le choix entre VB.net et C#.net.

Pour chaque projet .NET, le développement des couches model, métier et persistance se fait toujours en C#, et on laisse la présentation en VB.net.

Car par experience, la syntaxe de C# est plus rigoureuse car la compilation fait beaucoup attention aux opération de cast qu'il faut tout le temps mettre explicitement. Et comme les couches modèl, métier et persistance demandent beaucoup de rigueur, on met toujours les développeurs C# (qui proviennent de C++ / java) sur ces parties. Et on met les développeurs VB.NET (qui proviennent de vb6 ...) sur la partie présentation.

C'est un peu stéréotypé comme raisonnement... Ca rejoint la logique des gens qui disent C# est mieux, vu qu'en fait, le travail de design n'est pas intéressant, alors que celui du métier, lui l'est...

En plus, la partie design ne devrait pas être faite par des développeurs mais bien par des stylistes... Evidemment, il faut les former à la programmation pour qu'ils aient un minimum de connaisssances...

[Kelpan]

Car par experience, la syntaxe de C# est plus rigoureuse car la compilation fait beaucoup attention aux opération de cast qu'il faut tout le temps mettre explicitement.

Il est logique de retrouver ce genre de commentaire, car on a tellement répété la même chose que tout le monde s'en persuade sans prendre la peine de verifier...

Traditionnellement, Visual Basic possède une sémantique permissive, c'est-à-dire que le langage Visual Basic ne nécessite pas, en règle générale, l'emploi d'une syntaxe explicite lors d'opérations qui peuvent ne pas être d'une efficacité optimale (la liaison tardive, par exemple) ou qui peuvent échouer au moment de l'exécution (les conversions restrictives, par exemple).Bien qu'une sémantique permissive simplifie l'apprentissage du langage Visual Basic, elle risque d'entraver le développement d'applications à grande échelle en permettant aux erreurs de codage de passer inaperçues. Visual Basic .NET vous permet de mettre en vigueur une sémantique stricte durant la compilation.
L'instruction Option Strict détermine si les conversions et les opérations sur Object sont gouvernées par une sémantique de type stricte ou permissive et si les types sont implicitement Object par défaut. L'instruction peut être suivie par les mots clés On ou Off, le mot clé par défaut étant Off. Si aucune instruction n'est spécifiée dans un fichier, l'environnement de compilation détermine celle qui sera utilisée.

La sémantique stricte interdit les éléments suivants :

• les conversions restrictives sans opérateur de cast explicite.
• les liaisons tardives.
• les opérations sur le type Object autre que =, <>, TypeOf...Is et Is.
• l'omission de la clause As dans une déclaration.

Conclusion : La rigueur existe aussi sous VB (même VB 2003)....

[Maniak]

Conclusion : La rigueur existe aussi sous VB (même VB 2003)....

...pour peu qu'on prenne la peine d'être rigoureux.

[mode politiquement correct off]
Ceux qui font du VB.NET sans activer Option Explicit et Option Strict peuvent être au choix de deux types :
- ceux qui ne sont pas au courant qu'Option Strict existe, que l'option est (connement) désactivée par défaut, et qui devraient regarder de plus près le fonctionnement de leur IDE
- les feignasses qui ne veulent pas perdre de temps à apprendre à bosser correctement et qui préfèrent coder comme des porcs. C'est pas grave, pour beaucoup ce sont d'autres personnes qui devront se dépêtrer avec leur 'code'

Je n'ai pas de problème avec le premier groupe, il faut bien commencer quelque part. Du moment qu'ils veulent apprendre et qu'ils cherchent à faire du mieux qu'ils peuvent, tout va bien.
Le deuxième groupe par contre, ceux qui savent à quoi servent ces options et qui choisissent de les ignorer pour se faciliter la vie, je voudrais bien les voir intégralement virés de leurs boîtes et reconvertis pour aller derrière un guichet à la Poste. Ce serait plus approprié pour eux et ça, ça simplifierait utilement la vie de beaucoup d'autres personnes.

Ceux qui veulent un typage 'laxe' sont mal barrés avec .NET. Avec Ruby ok, pas de problème, c'est fait pour. Avec VB.NET non. C'est basé sur un framework lui-même basé sur un typage strict (qu'on aime ou non), avec juste des artifices pour simplifier l'apprentissage aux dépends de la qualité du code.


Bref : VB.NET sans Option Strict -> poubelle (on ne va même pas mentionner ceux qui pourraient désactiver Option Explicit)
VB.NET avec Option Strict -> mis à part quelques détails, la différence avec C# (ou autre langage .NET) est purement syntaxique, donc techniquement négligeable. C'est plus un choix politique/humain qu'autre chose.
[/mode politiquement correct off]

PS: pour éviter une impression de déjà-vu, tout ça s'applique aux 'vrais' projets. Pas ceux qui tiennent dans la tête d'une seule personne.
Pour les mini-applis à deux balles faites en vitesse et pour lesquelles on se fiche royalement de la qualité du code, rien à cirer.
Pour les applis pour lesquelles il faut se demander si elles seront maintenables par une nouvelle équipe 2 ans (que dis-je, 6 mois) plus tard, c'est autre chose.

[FremyCompany]

Je suis d'accord avec vous, oui, et non...

Je ne crois pas qu'activer Option Strict soit la seule facon d'avoir du VB "soigné"...

Il arrive des occasions, ou coder qqchose en C# ressemble à ca :

Code C# :

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

1
2
3
4
5
// Le mauvais exemple, puisque c'est mal de faire une classe qui fonctionne comme ca, mais bon soit
MyClassInstanceConvertibleToInteger = (MyClassConvertibleToInteger)((System.Integer)MyClassInstanceConvertibleToInteger) + UnNombre;
// Le bon exemple
oClass3 = (Class3)(((Class2)oClass1).Field)
// Le VB étant :

Je suis désolé, mais moi qui ait l'habitude du VB, je trouve que ce code ne rimme à rien, n'est pas du tout lisible, ...

Le même code en VB :

Code :

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

1
2
3
4
' CODE 0 :
MyClassInstanceConvertibleToInteger += UnNombre
' CODE 1
oClass3=CType(Class1, Class3).Field

De plus, parfois, on a besoin de faire des liasons tardives, en C# ca donne des trucs incomprhéensibles (et je peste chaque fois que je dois en faire) où il faut passer par la réflexion, et en VB :

Code VB.Net :

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

1
2
3
4
5
6
' Soit UnObject As Object, d'un type inconnu mais implémentant des fonctions données
Try
   UnObject.Load(My.Application, Me)
Catch Ex as Exception
   ' Prevenir dans une console que l'Add-In a causé une erreur
End

On me dira que c'est mal, je dirais que ca m'a fait gagner 20 minutes, et que celui qui devra utiliser le code après moi n'aura aucune difficulté à comprendre/modifier...

Pour moi tout est une question de rigeur, pas de Option Strict...
C'est qu'un programmeur C# peut faire des fautes "graves" aussi :

Code C# :

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

1
2
3
4
 
for (i=0; i<array.length; i++) {
   unString+=array[i].toString();
}

, la ou en VB on peut faire du code très propre :

Code :

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

1
2
3
While I <> Array.length
  StringBuilder.Append(Array(I))
End While

[spidermario]

FremyCompany n'a pas tort, je rejoins son avis.

[Maniak]

Je suis d'accord avec vous, oui, et non...

Je ne crois pas qu'activer Option Strict soit la seule facon d'avoir du VB "soigné"...

Il arrive des occasions, ou coder qqchose en C# ressemble à ca :

[snip]

VB.NET avec Option Strict -> mis à part quelques détails, la différence avec C# (ou autre langage .NET) est purement syntaxique

Si je n'ai pas mentionné C# ailleurs que là, c'est pas pour rien :)

Évidemment qu'on peut faire du code crade en C#. On peut en faire en n'importe quoi.

Pour reformuler :
VB.NET avec Option Strict == C#, mis à part la syntaxe et 2-3 détails.
Le code peut être aussi propre ou crade avec l'un ou l'autre, là n'est pas la question. C'est juste une question de syntaxe.

VB.NET sans Option Strict -> crade de base.

C'est pas une histoire de VB.NET vs C# là. C'est une question de VB.NET qui peut donner du bon code vs VB.NET qui... bah qui ne vaut rien, pour faire simple :)

Après, C# crade vs VB.NET Strict propre, la question ne se pose même pas.


Tu dis que c'est une question de rigueur, on est d'accord. Et Option Strict implique cette rigueur.

Tu dis qu'on a parfois besoin de faire du late binding en C#. Mis à part avec COM, ce qui peut se localiser dans un petit coin séparé, tu as des exemples ?

À noter que :
- les casts à répétition (ton 1er exemple) sont généralement indicateurs de problèmes de design bien plus importants que le choix du langage
- ton 2è exemple est un peu la raison d'être des interfaces
- ton 3è exemple a un problème de performance potentiel en C#, un bug en VB.NET et ferait mieux d'utiliser un foreach de toute façon dans les deux langages :)

[FremyCompany]

Je suis d'accord pour ce qui est de mon premier exemple, et je l'ai d'ailleurs écrit moi-même

Je ne comprends pas en quoi les interfaces aident à résoudre le problème de l'exemple deux, mais peut-être as-tu raison, tu pourrais donner un exemple ?

Pour ce qui est du 3e, lol, c'est une faute de distraction, j'ai tapé ca très vite, et j'en ai oublié le I+=1... Sinon, While I <> Array.lenght est plus rapide de For Each...

A part les COM... Ben en soit les COM c'est déjà un gros packet...

Des exemples : Add-In Office, le Controle WebBrowser

Code VB :

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

1
2
3
4
5
' Renvoie un objet typé, mais il est impossible, si l'objet retourné est un formulaire, de faire un submit de celui-ci
WebBrowser.Document.getElementById("ID") 
'Renvoie un objet non-typé, avec lequel on est libre d'utiliser pleinement les fonctionnalité du contrôle, comme en JavaScript
Dim Document = WebBrowser.Document.ActiveXObject
Try : Document.getElementById("ID").Submit() : Finally : End Try

Concernant ce dernier exemple, je tiens à dire que si vous voulez inculquer à un developpeur l'inventivité et surtout l'utilisation d'objet non-typé (COM) en toute sécurité, il faut lui apprendre le JavaScript..

Ca peut paraitre idiot, mais en javascript, on prend tout les temps ses précautions avant de faire une opération, car l'objet que l'on recoit est différent selon le navigateur, selon la version de celui-ci, ...

Cela implique que je fais pareil en VB.
VB et JavaScript ont beaucoups de point commun, mis à part le fait que la syntaxe du JS est d'origine "C".

Et même au niveau de la syntaxe, de nombreuses choses ont évolué du coté du JS pour s'approcher du VB (ex: ";" non obligatoire en fin de ligne)

Je ne suis pas en train de vanter le JS, mais je penses que beaucoups de développeur C# ne se rendent pas compte des possibilités que peuvent offrir un type non explicit des variables. D'ailleurs, je rappelerai à ceux qui estiment que .Net est un langage "de Classes" que C# 3.0 permettera les typage non-explicites de variable, et d'une manière étonemment proche de celle du JS, vu que le "mot introducteur" (semblable au Dim de VB) sera "var"...

Code JavaScript :

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

1
2
// Ce code est en C# 3
var Document = ...

Que vous pensiez que cela est bien ou mal, peu importe... MS le fera...

PS : En ce qui concerne l'utilisation "intempstive" de try... catch à cause des objets non-typés, il faut bien avouer son existence, et tenter donc de l'éviter là ou c'est possible !

Sinon, en JS, il existe une solution plus efficace et plus propre :

Code JavaScript :

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

1
2
var form=document.getElementById("ID");
if (form.submit) { form.submit(); }

[Maniak]

Je ne comprends pas en quoi les interfaces aident à résoudre le problème de l'exemple deux

Qu'au lieu de passer par Object et de soit caster soit faire du late binding, on passe par des interfaces qui correspondent au comportement commun, même quand l'héritage n'est pas possible. Cf IDisposable.

Si on a besoin de faire les mêmes appels sur différentes classes qui n'ont pas de lien de parenté, c'est un signe qu'une interface a peut-être envie d'apparaitre.

Pour ce qui est du 3e, lol, c'est une faute de distraction, j'ai tapé ca très vite, et j'en ai oublié le I+=1... Sinon, While I <> Array.lenght est plus rapide de For Each...

1/ pas forcément
2/ so what?
C'est plus lisible, ça évite les erreurs de compteur, les modifications de la collection parcourue et c'est plus lisible.

Ah aussi, c'est plus lisible.

C'est fini le temps où il fallait essayer de grapiller le moindre cycle de CPU dans tous les sens. Les cas où les performances de foreach posent un problème sont (très) rares. Quand on les repère, on utilise for à la place. Le reste du temps, on met l'accent sur la lisibilité (et maintenabilité) du code.

A part les COM... Ben en soit les COM c'est déjà un gros packet...

Pas pour tout le monde :)
Et un wrapper est vite fait, quitte à ce qu'il soit fait en VB.NET sans Option Strict dans une librairie à part, pour isoler le reste du code de ces détails.

VB et JavaScript ont beaucoups de point commun, mis à part le fait que la syntaxe du JS est d'origine "C".

Et mis à part que JS est un langage dynamique, qui n'est pas basé sur un framework qui n'a rien de dynamique. Et que JS permet de faire beaucoup plus de choses avec les objets que .NET. Et que JS n'implose pas intégralement quand l'interpréteur a le moindre doute sur sa conversion entre un objet 'non-typé' dans un vrai type avec lequel faire son traitement.
(ce qui peut poser d'autres problèmes, mais on s'éloigne gravement du sujet :)

Et même au niveau de la syntaxe, de nombreuses choses ont évolué du coté du JS pour s'approcher du VB (ex: ";" non obligatoire en fin de ligne)

J'ai comme un doute sur la partie "ça a été fait pour le rapprocher du VB" :)

Je ne suis pas en train de vanter le JS, mais je penses que beaucoups de développeur C# ne se rendent pas compte des possibilités que peuvent offrir un type non explicit des variables.

Yup. Et c'est pour ça qu'il peut être intéressant de se pencher sur Ruby. En gardant en tête qu'une fois de retour en .NET, on est de retour dans un monde fortement typé.

Le 'non-typage' avec VB.NET, ça n'a rien à voir. C'est juste une facilité. De l'assistanat. Juste derrière, tout reste fortement typé. Et si on compte sur le compilo et le framework pour deviner ce qu'il faut faire, il ne faut pas venir pleurer ensuite quand on ne comprend plus d'où viennent les problèmes.

D'ailleurs, je rappelerai à ceux qui estiment que .Net est un langage "de Classes" que C# 3.0 permettera les typage non-explicites de variable, et d'une manière étonemment proche de celle du JS, vu que le "mot introducteur" (semblable au Dim de VB) sera "var"...

Qui ne sert qu'à simplifier la ligne de création de l'objet et qui n'est pas forcément des plus utiles quand on s'efforce de passer essentiellement par des interfaces.
Dans tous les cas, aucun rapport avec le late binding et encore moins avec un éloignement de ce statut de langage "de classes", quoi que ça veuille dire (langage objet ? encore heureux que ce soit toujours le cas :)

Que vous pensiez que cela est bien ou mal, peu importe... MS le fera...

Rien de mal a priori. Après ça dépendra de la façon dont ce sera utilisé (cohérence du code). Mais c'est comme le reste, il y aura toujours des gens pour en abuser pour se simplifier la vie et compliquer celle des autres.

PS : En ce qui concerne l'utilisation "intempstive" de try... catch à cause des objets non-typés, il faut bien avouer son existence, et tenter donc de l'éviter là ou c'est possible !

Donc on active Option Strict et on l'évite partout d'un seul coup.

Sinon, en JS, il existe une solution plus efficace et plus propre :

Code JavaScript :

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

1
2
var form=document.getElementById("ID");
if (form.submit) { form.submit(); }

Ce qui est pratique.
Et vu que VB.NET n'a rien à voir et n'est pas fait pour ce genre de choses, on active Option Strict et on évite de se faire des illusions qui se transformeront en cauchemars.

En JS, quand on veut savoir si on peut envoyer un certain appel à un objet, on regarde s'il le supporte.
En VB.NET sans Option Strict, quand on veut savoir si on peut traiter une variable de type Object comme le type dont on a besoin, on va fouiller dans le code pour voir d'où peut venir cet objet et vérifier qu'on ne va pas se manger un cast invalide dans certains cas à l'exécution. Top.

Et je ne dis pas ça parce que j'ai justement eu à me taper de la maintenance sur du code VB.NET fait par certains qui croient que si on peut faire du late binding, il faut le faire. Parce que ça simplifie trop la vie.
Code buggué et incompréhensible, dont les 3/4 des bugs ont disparu simplement en activant Option Strict et en faisant le tour des erreurs.

Mais à part ça, c'est vrai que désactiver Option Strict est vachement pratique. Du moment qu'on change de mission pas longtemps après et qu'on ne se soucie pas trop du reste du monde.

[FremyCompany]

Code :

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

1
2
3
4
Et je ne dis pas ça parce que j'ai justement eu à me taper de la maintenance sur du code VB.NET fait par certains qui croient que si on peut faire du late binding, il faut le faire. Parce que ça simplifie trop la vie.
Code buggué et incompréhensible, dont les 3/4 des bugs ont disparu simplement en activant Option Strict et en faisant le tour des erreurs.
 
Mais à part ça, c'est vrai que désactiver Option Strict est vachement pratique. Du moment qu'on change de mission pas longtemps après et qu'on ne se soucie pas trop du reste du monde

Mouais... Mis à part que cela m'a fait sourrire, je trouve l'argument un peu faible... Et surtout un peu hyperbolique...
(lol, qui a dit que le cours de francais était inutile xD)

Je crois qu'en effet ton opinion est très valable, du moins pour un developpeur habitué à un cadre stricte, casse pied (je ne vois pas d'autre mot pour caractériser l'éditeur C#) et rébarbatif...

Mais pour quelqu'un qui est habitué à programmer en JS, et ne s'occuper dans la programmation que de ce qui importe (le résultat), je ne suis pas sûr que cela plaise...

Bien sûr, une partie de mon rationnel me dit que tu as raison, bien évidemment, mais je continuerai à développer sans Option Strict.

De toute facon, je reste convaincu que pour faire ce que j'aime (le Développement Web), le VB9 (équivalent du C# 3, largement meilleur selon moi, mais je peux me tromper, au point de vue de la gestion du XML (XLINQ-VB), et dont la syntaxe est plus proche du SQL, et donc de DLINQ) sera plus que suffisant et même conseillé. J'ai d'ailleurs l'impression qu'il existe plus de code VB que C# traitant du Web-Dev en ASPx, ce qui contredit la tendance "habituelle" (supériorité du C#)

[Maniak]

Mouais... Mis à part que cela m'a fait sourrire, je trouve l'argument un peu faible...

Faible ou pas, c'est du vécu :)
Maintenant, est-ce que la prolifération des bugs et les problèmes de maintenance directement liés à la désactivation d'Option Strict est un argument faible ou non, à chacun de juger.

Et surtout un peu hyperbolique...
(lol, qui a dit que le cours de francais était inutile xD)

Beaucoup de cours sont essentiellement inutiles :)

Je crois qu'en effet ton opinion est très valable, du moins pour un developpeur habitué à un cadre stricte

Pas strict. Rigoureux.

Mais pour quelqu'un qui est habitué à programmer en JS, et ne s'occuper dans la programmation que de ce qui importe (le résultat), je ne suis pas sûr que cela plaise...

Encore une fois (bon ok, je ne l'ai pas encore dit clairement) : on ne peut pas comparer un langage dynamique comme JS avec des langages statiques comme les langages .NET. C'est pas le même mécanisme.
Et profiter de quelques artifices de VB.NET en croyant que ça suffit à gommer les différences, c'est s'exposer à des retombées bien moins drôles. Si ce n'est pour soi, du moins pour les autres.

Ah et aussi, ne se préoccuper que du résultat sans penser à la méthode pour y arriver, à l'état du résultat en question et à la suite de l'existence de ce même résultat, c'est un raisonnement pour le moins incomplet.
Sauf donc si on change de mission juste après et qu'on se fiche du reste.

De toute facon, je reste convaincu que pour faire ce que j'aime (le Développement Web), le VB9 sera plus que suffisant et même conseillé.

Mais chacun a le droit d'utiliser ce qu'il veut voyons :)

Il y a juste une différence entre désactiver Option Strict parce qu'on préfère et le désactiver parce que c'est mieux. On peut préférer, mais ce n'est pas mieux. Loin de là. Et je préfère ne pas préférer ceux qui préfèrent ça, parce que de ce que j'ai vu du résultat jusque-là, c'est *vraiment* pas un cadeau.
Au moins avec Option Strict, même les feignasses ont besoin de faire un effort. Ça fait autant de boulot en moins pour ceux qui passent derrière pour réparer les dégâts.

VB.NET n'est pas un langage dynamique.


Ah tiens, tant que j'en suis dans ma série de 10 trouzaines d'éditions après avoir posté le message, je viens de penser à un cas où désactiver Option Strict me gênerait moins : si le code est fait en TDD.
Là ça élimine d'un coup la plupart de mes objections. Mais je doute un peu que ceux qui désactivent Option Strict soient au courant de ce que c'est et l'appliquent correctement et rigoureusement.

[Kelpan]

Il y a juste une différence entre désactiver Option Strict parce qu'on préfère et le désactiver parce que c'est mieux. On peut préférer, mais ce n'est pas mieux. Loin de là. Et je préfère ne pas préférer ceux qui préfèrent ça, parce que de ce que j'ai vu du résultat jusque-là, c'est *vraiment* pas un cadeau.
Au moins avec Option Strict, même les feignasses ont besoin de faire un effort. Ça fait autant de boulot en moins pour ceux qui passent derrière pour réparer les dégâts.

Personnellement, nous avons choisi la liaison tardive et la désactivation d'Option Strict.
Nous avons une application très complexe et la multiplication d'interfaces risquerait au contraire de compliquer la maintenance...

Je ne pense pas que le fait d'activer ou pas Option Strict est un quelquonque impact sur les bugs générés. Et cela ne les reduirait en rien car ce n'est pas la vrai source du problème du bug.

J'aurais tendance à dire que cette continuelle assistance de l'intégré de développement envers le développeur aurait tendance à l'abrutir...
Faites développer une classe à un développeur dans un textpad et vous verrez de quoi il est capable...

Maniak, le vrai problème que tu rencontres n'est pas du tout lié à un langage, une Option Strict ou quoi que ce soit...
Le problème est qu'il y a une recrudescence de personnes qui se prétendent développeur et qui, en fait, ne sont rien du tout dès qu'on leur demande de développer quelque chose sans assistance...

[Maniak]

Nous avons une application très complexe et la multiplication d'interfaces risquerait au contraire de compliquer la maintenance...

Pas convaincu mais curieux :)

Je ne pense pas que le fait d'activer ou pas Option Strict est un quelquonque impact sur les bugs générés. Et cela ne les reduirait en rien car ce n'est pas la vrai source du problème du bug.

Ça dépend de qui fait le code.

J'aurais tendance à dire que cette continuelle assistance de l'intégré de développement envers le développeur aurait tendance à l'abrutir...
Faites développer une classe à un développeur dans un textpad et vous verrez de quoi il est capable...

On est d'accord.

Le problème est qu'il y a une recrudescence de personnes qui se prétendent développeur et qui, en fait, ne sont rien du tout dès qu'on leur demande de développer quelque chose sans assistance...

On est d'accord aussi (malheureusement).

Maintenant pour ce qui est d'Option Strict, je reste persuadé à 200% que les faibles gains qu'on peut avoir sont négligeables en comparaison des problèmes que ça peut causer. Pour ne pas faire n'importe quoi sans Option Strict, il faut être sacrément rigoureux. Seulement je crains fort que l'essentiel des VBeux qui ne l'activent pas n'aient pas cette rigueur (pour les raisons que tu donnes plus haut, notamment :) et le fassent plus par fainéantise/ignorance qu'autre chose. C'est peut-être moi qui suit pessimiste, mais j'ai rarement vu de raisons d'être optimiste avec ça...

D'où mon insistance sur la nécessité de toujours activer cette option. Toujours. Jusqu'à ce qu'on maîtrise suffisamment la chose pour que la notion de 'toujours' devienne relative (valable pour n'importe quelle règle). Dans le cadre de dvpez.net, je préfère jouer les inflexibles. C'est trop facile de tirer la conclusion que si Option Strict désactivé peut être utile des fois, autant toujours le laisser désactivé, ça simplifie la vie. Sauf que non. Et quand on suit ce raisonnement, on crée des problèmes bien plus vicelards sans Option Strict qu'avec. Même si on est d'accord (encore), dans ces cas-là il y a de toute façon bien d'autres problèmes après. Tous les problèmes ne sont pas liés à l'absence d'Option Strict, mais tous les problèmes liés à l'absence d'Option Strict disparaissent si on l'active. C'est déjà ça de gagné pour tout le monde après.

(cela dit, je suis quand même curieux de voir un *vrai* cas où on aurait besoin de faire du late binding dans tous les sens avec .NET, parce que là tout de suite, je ne vois vraiment pas. ton appli m'intrigue :)

[Kelpan]

(cela dit, je suis quand même curieux de voir un *vrai* cas où on aurait besoin de faire du late binding dans tous les sens avec .NET, parce que là tout de suite, je ne vois vraiment pas. ton appli m'intrigue

Elle a de quoi intriguer ...

Quand, je suis arrivé sur le projet, la majeur partie avait été développé par une société offshore, car les développeurs n'avaient aucune connaissance du monde objet.
VB.NET a été choisi car, à l'origine, l'application devait être développé sous VB6 et avec la sortie de .NET VB.NET s'est imposé logiquement.
Le développement a duré 2 ans.

Comme, personne n'y connaissait rien, ils ont fait un peu confiance à cette société en ce qui concerne la structure et les composants de base du projet.

Quand, je suis arrivé sur le projet, je n'ai pu que constaté les dégats engendrés par cette équipe "offshorienne".
ex :
- Déclaration de variable en double pour des variables décimal(28,15) en SQL.
- Gestion des accès à la base de données à l'arrache...
- Création de classe de mappage de table incomplètes..
- Souces non commenté...

Bref, je m'éloigne du sujet, mais c'est pour te mettre un peu dans le contexte.
L'application comporte 30 projets, plus de 600 Mo de sources (+ de 3000 fichiers)

A ce stade, il est hors de question de revenir sur tout en même temps et il faut continuer à développer les spécifiques pour les clients.

Depuis, mon arrivée, j'ai rectifié le tir sur pas mal de chose, mais il reste malheureusement énormement de choses sur lesquels il faut revenir.
Et je peux t'assurer que pour pouvoir continuer à développer sans devoir modifier 200 classes, le late binding est le bienvenue...

[Maniak]

Et je peux t'assurer que pour pouvoir continuer à développer sans devoir modifier 200 classes, le late binding est le bienvenue...

Ok, là je comprends mieux (et je compatis :). Et donc c'est par nécessité, pas par choix. Quand il faut, il faut :)

Question subsidiaire : si tu pouvais bosser sur cette appli, mais depuis le début. Est-ce que tu choisirais de te reposer sur le late binding ou est-ce que tu ferais ton possible pour ne pas en avoir besoin ?

[SesechXP]

[/CODE], la ou en VB on peut faire du code très propre :

Code :

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

1
2
3
While I <> Array.length
  StringBuilder.Append(Array(I))
End While

Sauf que ça aussi tu peux le faire en C#, un Append d'un StringBuilder...

++