Discussion :

[marot_r]

Bonjour a tous et merci de votre temps et de vos avis.

En lisant un article sur MS SQL et comment proteger son code contre les modif, j'ai recoise la notion de parametres nommes qui existe aussi en VBA.
Et j'ai fait le test suivant :

Code :

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

1
2
3
4
5
6
7
Private Sub Test()
    Call aSub("T1", "T2")
 
    Call aSub(prm1:="T1", prm2:="T2")
 
    Call aSub(prm2:="T2", prm1:="T1")
End Sub

Code :

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

1
2
3
Private Sub aSub(prm1 As Variant, prm2 As Variant)
    Debug.Print "prm1="; prm1, "prm2="; prm2
End Sub

A+

Et obtenu le resutat suivant :

• prm1=T1 prm2=T2
• prm1=T1 prm2=T2
• prm1=T1 prm2=T2

Comme vous le voyez sur la derniere ligne de Test, les parametres nommes sont inverses par rapport a la signature.

Certe cela met le code a l'abris de changements du type :

Code :

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

Private Sub aSub(prm0 as varuiant, prm1 As Variant, prm2 As Variant)

mais quand on tape du code l'intellisens on va voir aSub(prm0, prm1, prm2) et je ne suis pas certain qu'on realisera que le 1er parametre est non seulement le 2ieme mais qu'il ne correspond pas au premier affiche par Intellisens.

Un des avantages colateral serait aussi le contournement de la limitation sur les parametres optionels qui doivent obligatoirement etre en dernier alosr que justement on souhaiterai que ce soit les derniers parametres qui soient obligatoires.

On pourrait avoir :

Code :

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

Public Function ConcatenatedTokenFromTo(prmSeparator As String, Optional prmStartIndex As Variant, Optional prmEndIndex As Variant) As String

et faire un appel du type :

Code :

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

ConcatenatedTokenFromTo(prmStartIndex:=2, prmEndIndex:=8, prmSeparator :=", ")

Code :

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

ConcatenatedTokenFromTo(prmStartIndex:=2, prmSeparator :=", ")

Code :

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

ConcatenatedTokenFromTo(prmEndIndex:=8, prmSeparator :=", ")

Car il est plus logique de specifier le separateur apres les bornes qu'avant.

Pensez-vous qu'on devrait encourager l'usage des parametres nommes pour un code plus resistant aux changements ?

A+

[pijaku]

Bonjour marot_r,

Un autre avantage, en faveur des arguments nommés, est la possibilité d'omettre les virgules si un ou plusieurs argument(s) facultatif(s) est omis.
C'est très pratique et plus lisible pour le cas ou ta fonction réclame beaucoup de paramètres facultatifs.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
Sub Appel()
Dim s As String, a As Variant, l As Long
   s = MaFunction(Arg1:=a, arg5:=l)
   ' au lieu de :
   's = MaFunction(a, , , , l)
End Sub
 
Private Function MaFunction(Arg1 As Variant, Optional arg2, Optional arg3, Optional arg4, Optional arg5 As Long, Optional arg6) As String
 
End Function

EDIT : Après réflexion...
Je reviens juste pour dire que, si l'on utilise un appel par paramètre nommé, cela sous-entend que le développeur de la fonction a nommé ses paramètres de manière explicite.
Ainsi, le code que je donne ci-dessus est une bouse...

Préférer une syntaxe claire et précise comme ceci (toujours par exemple) :

Code :

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

1
2
3
Private Function MaFunction(objListBox As Object, Optional Left As Double, Optional Top As Double, Optional Width As Double, Optional Height As Double, Optional List As Variant) As Boolean
 
End Function

[Invité]

Bonsoir,
Le problème des paramètres optionnel c'est justement qu'il sont optionnel.

Il faut soit évaluer tous les paramètres de la méthode soit donner des valeur par défaut.

Code :

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

1
2
3
4
5
6
sub mySub(optional param1 as string="toto",optional param2 as string ="titi")
Msgbox param1 &  " " & param2
End sub
Sub test()
mySub param2:="Cheval"
End sub

Inconvenant effectivement c'est que le optionnels sont obligatoirement en fin de paramètres.


Dommage qu'il n'est pas été envisager la surcharge de methode à l'époque de VB6 alors que le concept existait déjà

Ici pas optionnel on est obligé de respecter l'ordre des paramètre.

Code Méthodes surchargé VB.net :

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

1
2
3
4
5
6
sub mySub()
End sub
Sub mySub(param1)
End sub
Sub mySub(param1,param2)
End sub

https://www.developpez.net/forums/d1...s/#post8566702

[marot_r]

Merci dysorthographie de ta participation.

Mon interrogation principale est plus sur l'utilisation de parametres nommes que sur les parametres optionnels.
L'usage de parametres nommes pour contourner cette limitation est plus in effet de bord.

En matiere de possibilite, je reve du jour ou le VBA sera remplace par VB.Net mais je ne pense pas que ce sera pour demain, ni meme apres demain.

A+

[Invité]

Bonjour marot_r,
Il semblerait ( notes le conditionnel) que Microsoft se dirige vers une licence par abonnement et des fonctions toutes faites genre web service.

Le développement de nouvelles fonctions serraient dévolues à des développeur sous certification Microsoft à suivre!

Pour rappel Microsoft a abandonné VB6 et par extension VBA en 2003. Il a annoncé 4 ans plus qu'il ne le maintiendrait plus alors qu'il avait annoncé 8 ans en ne tenant pas compte de la législation française qui dit 20 ans!

J'espère me tromper et voir Vb.net remplacer VBA.