Visual Basic n’est pas encore mort

Visual Basic n’est pas encore mort
Microsoft annonce les changements apportés à la version 14 du langage

Le premier langage de programmation qui nous passe par la tête quand on pense à la programmation .Net c’est le C#. Cependant, Visual Basic n’a pas encore été abandonné par Microsoft et pour cause, ce langage reste encore très utilisé dans les écoles, mais aussi par plusieurs développeurs qui ne veulent pas changer de langage, d’autant plus que côté performances il n’a rien à se reprocher par rapport à C#, puisqu’il utilise le même IDE et les mêmes binaires.

Hier, Microsoft a annoncé les nouveautés apportées à Visual Basic 14 (la version 13 ayant été ignorée pour rester dans le même numéro de version que l’IDE). Parmi ces nouveautés, on peut citer l’introduction de l’opérateur « ?. » dont le but est de vérifier si une variable, une propriété ou un objet est nul avant de tenter d’y accéder, ou aussi pour vérifier si on est en train d’invoquer une méthode d’une référence qui n’existe pas. Par exemple, le code suivant :

Code:

---

If customer IsNot Nothing AndAlso customer.Age > 100 Then

---

Deviendra :

Code:

---

If customer?.Age > 100 Then

---

Lucian Wischik explique sur MSDN que l'opérateur « ?. » est plus sûr puisque dans l’exemple « l’expression "customer?.Age" lit la variable customer dans une variable temporaire, vérifie si elle n’est pas nulle, puis récupère la propriété Age de cette variable temporaire. Ce qui est thread-safe même si customer est nul ».

Un autre changement qu’on peut citer aussi est que les propriétés en lecture seule (Readonly) peuvent désormais être déclarées et initialisées directement dans la même ligne, comme montré dans la figure suivante :

http://www.developpez.com/public/images/news/vb14.gif
Nouvelle manière d'initialiser les propriétés Readonly, Source : MSDN

Concernant les chaines de caractères, il n’est plus nécessaire d’ajouter des & à la fin de la ligne pour indiquer qu’elles s’étendent sur la ligne suivante, puisque le compilateur détecte cela automatiquement à présent. De plus, il existe une autre manière de les formater en utilisant l’interpolation de chaines (String Interpolation). Donc au lieu d’écrire :

Code:

---

String url = String.Format("http://{0}/{1}?query={2}", site, path, q) ;

---

On écrira :

Code:

---

String url = $"http://{site}/{path}?query={q}";

---

À noter que cette dernière fonctionnalité n’est pas encore disponible dans la preview de Visual Studio 2015, mais sera intégrée dans la version finale. Vous pouvez consulter ici la liste de tous les changements apportés jusqu’à maintenant et ceux qui vont venir.

Source : Blog MSDN

Et vous ?

:fleche: Qu’en pensez-vous ? Quelles nouveautés voulez-vous voir intégrées au langage ?

le ? c'est bien, avec copie thread safe c'est encore mieux, bien qu'il arrive qu'on ait plusieurs propriétés à tester dans un thread auquel cas une copie de toutes à un instant T puisse rester nécessaire

le readonly property en une seule ligne je me demandais pourquoi il ne l'ont pas mis en même temps que les properties en une seule ligne, cool aussi

le string sur plusieurs lignes à la facon d'sql server c'est bien aussi

concernant la fabrication de string, je reste plus sceptique, une variable en chaine de caractère ca reste caduque en terme de vérification à la compilation
je pense que dans ce cas il n'y a pas de vérification, mais ca reste possible donc s'ils l'ont mis c'est bien, mais ca reste une syntaxe que je n'utiliserais pas

j'ai regardé un peu la liste des nouveautés, j'aime bien le NameOf() qui est aussi un point sécuritaire plutot que de compiler un string qui peut être faux

content de voir que vb continue son chemin, par contre il reste à déplorer que ce n'est pas un langage prioritaire dans beaucoup de choses
à priori si j'ai bien suivi sur .net micro framework c# est arrivé en 1er, sur xamarin c'est pareil le c# est possible, mais pas vb.net
c'est un langage qui a une mauvaise réputation, comme sa communauté de développeur considérée comme débutante, alors que bien utilisé il n'a rien à envier à c# et je trouve ca vien d'avoir une alternative sur la syntaxe en gardant les bases de .net

Hello,

Pareil que Pol63 concernant les changements évoqués. Autant les premiers sont les bienvenus, autant le dernier concernant les chaînes de caractères me semble douteux. Je trouve quand même l'ancienne écriture bien plus lisible !

Ou alors il aurait fallu faire changer la couleur des noms de variables qui sont entre les accolades... Enfin ce n'est que mon avis.

Sinon, concernant le débat entre VB et C#, comme cela a déjà été dit, le VB n'a rien à envier au C# et le fait que VB soit délaissé pour pas mal de choses est vraiment regrettable.

A l'école, j'ai appris le VB6, quand je suis passé à .NET par curiosité avec le framework 1, je suis logiquement passé sur VB.NET et j'ai assez vite retrouvé mes jeunes.

Dernièrement je me suis mis à C# histoire de faire un petit projet perso avec XNA et franchement, je trouve le C# bien moins clair en lecture que le VB.NET. Un reproche qui est souvent fait à VB est d'être trop verbeux. Je trouve personnellement que c'est justement une qualité et pas un défaut.

C'est quand même beaucoup plus lisible d'avoir les End If, End While, End For, etc. au lieu d'une série d'accolade fermante "}". Et quand en plus VS n'indente pas les accolades correctement*, ça devient vite le bordel.

*J'ai d'ailleurs été très étonné qu'un truc aussi basic soit mal fait pour le C#. Une chose de ce genre ne m'est jamais arrivée en VB.NET. A moins que ce soit propre à l'utilisation de XNA ??

My 2 cents...

Bonjour,
depuis la version 3 Microsoft nous à vendu Vb comme un langage instinctif! comme si l'instinct était de mise en programmation professionnel!

des le début Vb avait de quoi devenir un grand langage, la notion de classe était embryonnaire mais présente; le Visuel Basic Application à compliqué la donne reléguant le Vb à un rôle de bidouillage de deuxième zone pour développeur spaghettis et/ou procédural!

cette mauvaise réputation est due en partie à cela mais également au recruteur qui déroule un discourt qui ne comprenne pas.

je suis un pur produit Vb et je suis ravis de voir que vb continue moi aussi!

Citation:

---

Envoyé par Amine Horseman

Visual Basic n’est pas encore mort

---

En même temps je ne crois pas avoir entendu qui que ce soit dire qu'il l'était ;)

Citation:

---

Envoyé par Pol63

concernant la fabrication de string, je reste plus sceptique, une variable en chaine de caractère ca reste caduque en terme de vérification à la compilation
je pense que dans ce cas il n'y a pas de vérification, mais ca reste possible donc s'ils l'ont mis c'est bien, mais ca reste une syntaxe que je n'utiliserais pas

---

Si, c'est vérifié par le compilateur. En fait, le compilateur transforme l'expression d'interpolation en un string.Format équivalent. Si tu écris ça :

Code:

---

String url = $"http://{site}/{path}?query={q}";

---

le compilateur le transforme en ça :

Code:

---

String url = string.Format("http://{0}/{1}?query={2}", site, path, q);

---

et vérifie normalement les expressions "path", "site" et "q"

Tu auras même l'intellisense dans ta string ;)

Je rejoins les avis précédent, particulièrement pour le ?. Le fameux IsNot Nothing de la variable c'était pas le top point de vue lisibilité du code.

Quand au débat c# et VB, je trouve qu'il n'a pas vraiment lieu d'être parce que c'est surtout une histoire de syntaxe.

Si c# a tendance a être plus proche de java, de faire du code condensé (d'un point de vue nombre de caractère) et en théorie d'avoir une meilleur productivité en écriture de code au kilomètre. J'aime beaucoup le coté verbeux de Visual Basic qui rend le code beaucoup plus human readable.

Je dois pas être fichu comme tout le monde parce que l'histoire du ? je suis pas 100% fan ; je comprends l'intérêt mais pour moi ça va créer des incohérences dans l'écriture pour la simple et bonne raison que ça marchera bien pour les éléments intermédiaires mais pour l'élément final on sera toujours dans la même situation qu'avant du coup on va se retrouver à faire des choses de ce style :

Code:

---

1 2	If customer?.Orders IsNot Nothing Then ' propriété If dict?(key) IsNot Nothing Then ' indexeur

---

le problème serait le même avec C# a priori (sauf si bien sûr j'ai loupé un détail et que ce genre de chose là est possible)

Code:

---

1 2	If customer?.Orders? Then If dict?(key)? Then

---

Mais dans un cas comme dans l'autre ça me laisse un brin perplexe ; dans le premier cas on se retrouve à miser les 2 façons et du coup ça peut être déstabilisant (pourquoi fait-on différemment ?) et dans le second je trouve ça peu lisible et c'est vite fait de louper ce ? final (le compilo nous le signalera vite mais quand même).

Pour l'interpolation de chaine ça me permettra au moins de ranger au placard mon FormatNamed "maison" :D

Quant à la productivité de l'un ou l'autre langage ; personnellement je pense que c'est plus une question d'IDE que de langage (et de ce point de vue là VS pour VB.Net complète suffisamment la "verbosité" pour éliminer totalement [si ce n'est inverser] les choses)

J'aurais quand même aimé avoir 2-3 petites choses qui n'y sont malheureusement pas (par exemple la possibilité d'activer/désactiver localement le late binding ou l'overflow check [resp. dynamic et checked/unchecked en C#] plutôt que d'avoir un réglage global au niveau du projet [à voir s'il y a quelque chose de dispo dans le principe du #pragma qui semble avoir été ajouté])

Il y a une compatibilité avec les "anciennes écriture" du code au niveau du compilateur ?
Le linker n'ayant pas besoin de savoir sa.

Bonjour à tous,

Je ne me suis pas encore documenté sur les versions à venir, mais je suis d'accord avec tout le monde, ces évolutions sont utiles et nécessaires.
Bien que je trouve que la syntaxe s'éloigne un peu du VB, mais bon, c'est pas génant et on s'y fait rapidement.

Je crois que le VB c'est comme la potion magique de Asterix, et nous sommes tous des Obelix... nous sommes tombés dedans étant petits...

Perso, j'ai commencé avec le ZX Spectrum en 86 ou 87 je crois (je sais ça ne me rajeuni pas) :D
si vous cliquez sur l'image vous verrez que chaque touche contient déjà des instructions en basic...

Je n'ai aucun problème à reprendre ou à faire une application en C# ou Java (notamment pour Android).
Mais à des moments donnés quand j'ai besoin de quelque chose bien spécifique, je me retrouve avec un bout de code en VB traduit en C#...

En parlant de Android, j'ai bien sur commencé en Java au début, bon, il faut se familiariser à la structure des applications etc.
Et puis, depuis quelques mois j'ai découvert Basic4android.
Un excellent travail de compilation VB/Java fait par Anywhere Software, depuis je n'utilise que ça, je viens d'équiper un amphithéâtre dans une université avec une tablette Android et une application en VB!...

Comme dit rdurupt, je suis ravis de voir que vb continue moi aussi!

A+

Bonjour, je suis moins pro que mes camarades au dessus concernant le VB.Net mais j'utilise en majorité ce langage, et ceux pour des raisons simples : il est clair et plein d'outils très utiles.
Je suis très content de voir qu'il y a une évolution du langage qui simplifie à la fois l'écriture et la lecture du code, en espérant que l'évolution se poursuive de façon active.

Citation:

---

Envoyé par ACIVE_CS

En parlant de Android, j'ai bien sur commencé en Java au début, bon, il faut se familiariser à la structure des applications etc.
Et puis, depuis quelques mois j'ai découvert Basic4android.

---

merci pour l'info

bonjour

L'amelioration concernant du test concernant les types references me parait etre une fausse amelioration ...
Jugez-en
En .Net 1.1 le malheureux codeur devait ecrire cette longue ligne (IsNot n'exisait pas) totalement incomprehensible :

Code:

---

1 2 3 4 5 6 7 8

Private cust As Customer Public Sub New()   If Not (cust Is Nothing) Then   End If End Sub

---

En .Net 2.0 ,l'operateur IsNot (la negation d'un type reference en c#) est "invente",un de plus...On est soulage:

Code:

---

1 2 3 4 5 6 7 8

Private cust As Customer Public Sub New()   If cust IsNot Nothing Then   End If End Sub

---

Maintenant ce qu'il faut c'est eliminer le AndAlso et avoir un seul And comme en c# qui fait le "court-circuit" pour les types references ...
on aurait bien aime ecrire comme en c# le code d'exemple cite :

Code:

---

1 2 3

If customer IsNot Nothing And customer.Age > 100 Then

---

....
Qu'en est-il de l'inconvenient "debile" de la declaration de tableaux comme l'as bien releve Tomlev ou vous specifier un tableau à 2 dimensions comme suit :

Code:

---

1 2	Private Customers(1) As Customer

---

La mise en conformite serait la bienvenue ... !!!

J'ai rien compris :aie:
Dire que Not cust Is Nothing est trop long est un non sens (ça ne fait qu'un seul caractère de moins que cust IsNot Nothing) pour la lisibilité en revanche je suis un peu d'accord c'est pas génial (c'est pas catastrophique non plus)
L'histoire sur le And et le AndAlso là je suis carrément paumé ; en C# on a aussi & et && donc je vois pas le souci à en avoir 2 ; leurs rôles respectif sont clairement définis.
Quant aux tableaux, je ne suis pas sûr d'avoir compris, si c'est le "problème" d'avoir à écrire 1 là où ça donne 2 éléments ; ce n'est pas près de changer ; il a toujours été précisé que ce qu'on donne sont les bornes des dimensions pas la taille de la dimension (après on aime ou on aime pas mais c'est comme ça et ça représenterait un trop gros breaking change pour que ça change un jour à mon avis)

Citation:

---

Envoyé par Sehnsucht

L'histoire sur le And et le AndAlso là je suis carrément paumé ; en C# on a aussi & et && donc je vois pas le souci à en avoir 2 ; leurs rôles respectif sont clairement définis.

---

les opérateurs AND et & (dont j'ignorais l'existence en tant qu'opérateur de test) ont l'inconvénient de systématiquement évaluer les 2 expressions de chaque coté de l'opérateur avant d'en déduire le résultat. Il faut donc prendre garde qu'elles soient toutes les 2 évaluables et donc multiplier les tests. Le AND est un héritage des anciens VB et surtout des Basic.

Les opérateurs ANDALSO et && sont les opérateurs de test ET LOGIQUE des langages à la syntaxe C like. Ici, la seconde expression n'est évaluée que et seulement que si l'évaluation de la première n'a pas permis de déterminer le résultat du test. C'est un fonctionnement qui beaucoup plus logique en informatique et en développement, et dans tout domaine de manière générale. Inutile de désosser le moteur de la voiture à partir du moment que l'on sait que la panne est due à un réservoir vide.

L'opérateur AND (et donc maintenant & en C#) est une aberration en soi dans nos programmations modernes. Je fais parti des fervent militants (même déjà au temps de VB6) pour l'abandon pur et simple de cet opérateur.
Il en va de même pour l'opérateur OR qui devrait être abandonné au profit du ORELSE (ainsi que de la boucle FOR qui devrait fonctionner comme dans les langages C like)

Citation:

---

Envoyé par MABROUKI

L'amelioration concernant du test concernant les types references me parait etre une fausse amelioration ...
Jugez-en
En .Net 1.1 le malheureux codeur devait ecrire cette longue ligne (IsNot n'exisait pas) totalement incomprehensible :

Code:

---

1 2 3 4 5 6 7 8

Private cust As Customer Public Sub New()   If Not (cust Is Nothing) Then   End If End Sub

---

En .Net 2.0 ,l'operateur IsNot (la negation d'un type reference en c#) est "invente",un de plus...On est soulage:

Code:

---

1 2 3 4 5 6 7 8

Private cust As Customer Public Sub New()   If cust IsNot Nothing Then   End If End Sub

---

Maintenant ce qu'il faut c'est eliminer le AndAlso et avoir un seul And comme en c# qui fait le "court-circuit" pour les types references ...
on aurait bien aime ecrire comme en c# le code d'exemple cite :

Code:

---

1 2 3

If customer IsNot Nothing And customer.Age > 100 Then

---

---

And et AndAlso n'ont pas le même sens, et changer And pour qu'il fasse la même chose que AndAlso serait une très mauvaise idée (ça pourrait casser du code existant).

Sinon, j'ai l'impression que tu n'as pas bien compris le but de cette amélioration... Ce sera peut-être plus clair avec un exemple plus extrême ; tu préfères écrire ça :

Code:

---

1 2 3 4

Dim city As String = "(unknown)" If order IsNot Nothing AndAlso order.Customer IsNot Nothing AndAlso order.Customer.Address IsNot Nothing AndAlso order.Customer.Address.City IsNot Nothing Then city = order.Customer.Address.City End If

---

ou ça ?

Code:

---

Dim orderCity As String = If (order?.Customer?.Address?.City, "(unknown)")

---

En ce qui me concerne, le choix est vite fait...
(c'est également plus performant, car chaque propriété n'est évaluée qu'une seule fois)

Citation:

---

Envoyé par MABROUKI

Qu'en est-il de l'inconvenient "debile" de la declaration de tableaux comme l'as bien releve Tomlev ou vous specifier un tableau à 2 dimensions comme suit :

Code:

---

1 2	Private Customers(1) As Customer

---

La mise en conformite serait la bienvenue ... !!!

---

Oui, c'est un des trucs qui m'énervent en VB... mais malheureusement ça ne changera pas, puisque ce serait un breaking change.

Citation:

---

Envoyé par sevyc64

les opérateurs AND et & (dont j'ignorais l'existence en tant qu'opérateur de test) ont l'inconvénient de systématiquement évaluer les 2 expressions de chaque coté de l'opérateur avant d'en déduire le résultat. Il faut donc prendre garde qu'elles soient toutes les 2 évaluables et donc multiplier les tests. Le AND est un héritage des anciens VB et surtout des Basic.

Les opérateurs ANDALSO et && sont les opérateurs de test ET LOGIQUE des langages à la syntaxe C like. Ici, la seconde expression n'est évaluée que et seulement que si l'évaluation de la première n'a pas permis de déterminer le résultat du test. C'est un fonctionnement qui beaucoup plus logique en informatique et en développement, et dans tout domaine de manière générale. Inutile de désosser le moteur de la voiture à partir du moment que l'on sait que la panne est due à un réservoir vide.

L'opérateur AND (et donc maintenant & en C#) est une aberration en soi dans nos programmations modernes. Je fais parti des fervent militants (même déjà au temps de VB6) pour l'abandon pur et simple de cet opérateur.
Il en va de même pour l'opérateur OR qui devrait être abandonné au profit du ORELSE (ainsi que de la boucle FOR qui devrait fonctionner comme dans les langages C like)

---

Les opérateurs And, Or, & et | ont aussi leur utilité.

D'abord pour un cas d'usage où il 'y a pas d'alternative : les opérations de combinaisons de bits. Par exemple :

Code:

---

1 2	// prend les 2 octets de poids faible de y int x = y & 0x0000FFFF;

---

Ensuite parce qu'il peut y avoir des cas où tu veux évaluer les deux opérandes :

Code:

---

if (DoSomething() & DoSomethingElse())

---

Il est tout à fait légitime de vouloir exécuter les 2 opérations et tester si les deux ont renvoyé true. Maintenant, j'admets volontiers que ce n'est pas la façon la plus naturelle et la plus lisible de faire ça... d'ailleurs si je voyais un truc comme ça pendant une relecture de code, je demanderais certainement à l'auteur de le changer.

Enfin, on peut faire &=, ce qui est parfois utile, mais pas &&=...

Déjà je pense que pour la "suppression" c'est surtout concernant les vers logiques de ces opérateurs pas leurs versions numériques.
Après j'étais en train de rédiger grosso modo la même chose que tomlev (avec un joli If Foo () And Bar () Then en exemple :aie:) à laquelle j'allais quand même dire qu'à choisir je préfèrerais une approche de ce type :

Code:

---

1 2 3

Dim fooRes = Foo () Dim barRes = Bar () If fooRes AndAlso barRes Then

---

Comme quoi les "grands" esprits se rencontrent :haha:

Salut,

Moi aussi, mais tanpis, je poste quand même :D

----------------------------------------------------

Citation:

---

Envoyé par sevyc64

les opérateurs AND et & (dont j'ignorais l'existence en tant qu'opérateur de test) ont l'inconvénient de systématiquement évaluer les 2 expressions de chaque coté de l'opérateur avant d'en déduire le résultat. Il faut donc prendre garde qu'elles soient toutes les 2 évaluables et donc multiplier les tests. Le AND est un héritage des anciens VB et surtout des Basic.

Les opérateurs ANDALSO et && sont les opérateurs de test ET LOGIQUE des langages à la syntaxe C like. Ici, la seconde expression n'est évaluée que et seulement que si l'évaluation de la première n'a pas permis de déterminer le résultat du test. C'est un fonctionnement qui beaucoup plus logique en informatique et en développement, et dans tout domaine de manière générale. Inutile de désosser le moteur de la voiture à partir du moment que l'on sait que la panne est due à un réservoir vide.

L'opérateur AND (et donc maintenant & en C#) est une aberration en soi dans nos programmations modernes. Je fais parti des fervent militants (même déjà au temps de VB6) pour l'abandon pur et simple de cet opérateur.
Il en va de même pour l'opérateur OR qui devrait être abandonné au profit du ORELSE (ainsi que de la boucle FOR qui devrait fonctionner comme dans les langages C like)

---

Citation:

---

Envoyé par D'après les spec VB 11.0

Or : le bit de résultat est 1 si l'un des deux bits est 1 ; sinon, le bit de résultat est 0.
And : le bit de résultat est 1 si les deux bits sont 1 ; sinon, le bit de résultat est 0.
AndAlso et OrElse :Les opérateurs AndAlso et OrElse sont les versions « court-circuit » des opérateurs logiques And et Or. Du fait de leur comportement de court-circuit, le deuxième opérande n'est pas évalué au moment de l'exécution si le résultat de l'opérateur est connu après l'évaluation du premier opérande.
Les opérateurs logiques de court-circuit sont évalués de la façon suivante :
Si le premier opérande d'une opération AndAlso a la valeur False ou retourne True à partir de son opérateur IsFalse, l'expression retourne son premier opérande. Autrement, le deuxième opérande est évalué et une opération And logique est effectuée sur les deux résultats.

Si le premier opérande d'une opération OrElse a la valeur True ou retourne True à partir de son opérateur IsTrue, l'expression retourne son premier opérande. Autrement, le deuxième opérande est évalué et une opération Or logique est effectuée sur ses deux résultats.

---

Un petit test sur un champs de bit:

Code:

---

1 2 3 4 5 6 7 8

Enum BitField As Integer A = 0 ' 0000 B = 1 ' 0001 C = 2 ' 0010 D = 4 ' 0100 E = 8 ' 1000 End Enum

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Sub Main()   Dim Res(0 To 1) As Integer   ' ' A priori : 0000 ' OR 0001 ' = 0001 ' = 1 Res(0) = BitField.A Or BitField.B ' J'ai mis Option Strict Off pour l'opérateur OrElse Res(1) = BitField.A OrElse BitField.B   Res(0) = 0 : Res(1) = 0 ' ' A priori : 0001 ' OR 0001 ' = 0001 ' = 1 Res(0) = BitField.B Or BitField.B Res(1) = BitField.B OrElse BitField.B   Res(0) = 0 : Res(1) = 0   ' ' A priori : 0010 ' = 2 ' OR 1000 ' = 8 ' = 1010 ' = 10 Res(0) = BitField.C Or BitField.E Res(1) = BitField.C OrElse BitField.E

---

un modo peut supprimer les 5 posts qui flood à propos de and et andalso ? ^^

Citation:

---

Envoyé par Nouveau2

' J'ai mis Option Strict Off pour l'opérateur OrElse

---

Ça me rassure de voir que OrElse n'est pas autorisé sur des entiers en mode strict, parce que ça n'a pas vraiment de sens... OrElse et AndAlso ne fonctionnent qu'avec des opérandes booléens.

En mode non strict, si c'est des entiers, ils sont implicitement convertis en Boolean (False si c'est 0, sinon True). Et comme tu affectes le résultat à un entier, c'est reconverti implicitement en entier (-1 pour True, 0 pour False). Donc dans ton exemple, les résultats sont toujours 0 ou -1 avec l'opérateur OrElse...