propriété par défaut

bonjour,

Je vois souvent sur le forum des codes dans lesquels les propriétées des objets (controls ,cells,etc) ne sont pas nommées (propriété par défaut).

Certain developpeurs estiment que l implementation est plus propre , cependant il ne me semble pas que tous les objets renvoie une propriété par défaut, ce qui peut en ometant ces propriété génerer des erreurs de compilation.

Existe t il une liste ou un site pour voir les propriété par défaut des objets
A part l aide en ligne bien sûr.

Bonjour,

un seul conseil, ne serait-ce que pour faciliter la tâche de VB et celle de celui qui assurerait la maintenance de l'application : toujours spécifier la propriété à utiliser...

Citation:

---

Envoyé par ucfoutu

Bonjour,

un seul conseil, ne serait-ce que pour faciliter la tâche de VB et celle de celui qui assurerait la maintenance de l'application : toujours spécifier la propriété à utiliser...

---

+1, même si je le fais rarement dans mes réponses sur le forum...

[EDIT]
Illustration:

Code:

---

1 2 3 4 5

Dim a As Variant   a = Range("a1") Set a = Range("a1")

---

Les deux parties à droite du signe "=" sont identiques, pourtant celle de la première ligne renvoie la valeur de la cellule, et celle de la deuxième renvoie la cellule elle-même (objet Range). Même si le code présenté ici n'est pas optimal (utilisation de As Variant au lieu de As Range sur la deuxième ligne), il illustre la confusion possible lorsque l'on utilise la propriété par défaut.

L'avantage supplémentaire d'utiliser les propriétés à tous les coups est que la lecture et la compréhension sont plus aisées pour une autre personne qui ne connaitrait pas les propriétés par défaut.
[/EDIT]

Bonjour,

Cette fois, nous n’avons pas le même avis:(

Je trouve au contraire superflu l’indication explicite de la propriété par défaut .Value, pour des objets comme Range, TextBox, ListBox ou Combo.

Il existe quelques circonstances particulières où c’est nécessaire. Dans tous les autres cas, je trouve le code plus agréable à lire quand les .Value sont omis.

De même modifier le texte apparaissant sur un objet Label, .Caption ne me semble nullement nécessaire.

Je ne trouve justifié de toujours indiquer explicitement la propriété par défaut que pour les objets qu’on utilise peu fréquemment, et que donc l’on connaît moins bien.

Cordialement,

Citation:

---

Envoyé par ucfoutu

Un seul conseil : toujours spécifier la propriété à utiliser...

---

Bonjour

Pour connaitre les valeurs par défaut il faut regarder dans l'explorateur d'objets (F2 dans l'éditeur VBE), ce sont celles qui ont un point bleu.

Bigalo Je suis de l'avis de Pierre Fauconnier, systématiquement je mets toutes les propriétés par défaut, et je ne trouves pas que cela alourdi le code, mais les choses sont plus précises, et on sait de quoi on parle.

Starec

En effet, Starec...

Mais également : en omettant de préciser d'emblée la valeur, on force VB a aller rechercher lui-même (en fonction du contrôle) celle qui est à appliquer par défaut. Il est vrai que ce temps n'est perdu qu'à la compilation, sous VB6...
Mais la compilation se fait, sous VBA, à chaque exécution ...

Re,

Je suis près à parier que la différence en temps d’exécution est inférieure à 1 %.

Par ailleurs, je vous rappelle que je suis sur Mac, où IntelliSense n’existe pas. Tous les caractères doivent donc être entrés à la main.

L’indication explicite de la propriété par défaut représente un surcroît de rigueur, ce qui est une bonne chose, et avec certains langages c’est probablement fondamental. D’après mon expérience perso, cela ne l’est pas en VBA.

Citation:

---

Envoyé par ucfoutu

Mais la compilation se fait, sous VBA, à chaque exécution ...

---

Citation:

---

Envoyé par Starec

Pour connaitre les valeurs par défaut il faut regarder dans l'explorateur d'objets, ce sont celles qui ont un point bleu.

---

Je n’ai jamais vu ce point bleu dans l’explorateur de fichiers

Citation:

---

Je mets toutes les propriétés par défaut, et je ne trouve pas que cela alourdi le code, mais les choses sont plus précises, et on sait de quoi on parle.

---

Question de point de vue, ou simplement d’habitudes personnelles. Je trouve déjà VBA trop verbeux. .Value ne me paraît pas nécessaire pour savoir de quoi on parle, c’est suffisamment évident sans.

Bonsoir, bigalo .

Citation:

---

Je suis près à parier que la différence en temps d’exécution est inférieure à 1 %.

---

Dire 1% ou 2 % ou 0.5% ne signifie pas grand chose.... Le pourcentage dépendra tout simplement du nombre des propriétés par défaut utilisées....
Imagine une macro utilisant un très grand nombre de textboxes dont tu récupèrerais la valeur en écrivant nom_de_la_textbox sans préciser la propriété... C'est sur une telle macro que l'utilisation d'un bon chrono te permettra de faire la comparaison entre préciser et non préciser la propriété par défaut.

Je ne savais pas que Mac n'offrait pas l'intellisense !... je compatis donc...

Citation:

---

Envoyé par Bigalo

Cette fois, nous n’avons pas le même avis:(

<<SNIP>>

Je ne trouve justifié de toujours indiquer explicitement la propriété par défaut que pour les objets qu’on utilise peu fréquemment, et que donc l’on connaît moins bien.

---

Je ne partage pas non plus ton point de vue, mais tends plutôt à me joindre à ucfoutu et Pierre Fauconnier et Starec à ce niveau.
Ne serait-ce que pour un point, issu de ta propre remarque :
Et le jour où TON code est lu par un NOVICE ?
Lui, il ne les connait sûrement pas les propriétés par défaut.
En agissant ainsi, tu ne te préoccupe donc que de l'instant présent dans la vie de ton code, et pas de sa pérennité au-delà de toi-même.
C'est dommage je trouve :(

Citation:

---

Pour connaitre les valeurs par défaut il faut regarder dans l'explorateur d'objets (F2 dans l'éditeur VBE), ce sont celles qui ont un point bleu.

---

pour le voir , créer un userform puis ouvrir l explorateur d objet (msforms)
et la :lol: les propriété par defaut sont "surligné " d un point bleu.

attention : tous les objets n ont pas forcement de propriété par défaut

SAlut
Pour ma part je pense que VBA est tres flexible dans son utilisation en general, il offre c'est vrai la possibilité de ne pas marquer .Value par exemple. Mais perso je trouve que se manque de rigueur peu se payer, tout comme le faite de faire des transtypage implicite

Code:

---

1 2 3 4

Dim Str As String   Str = 1

---

J'ai commencer la programation avec VB4 et bien sur je ne faisait jamais de transtypage Str = CInt(1) (ok mon exemple est con...mais bon) et il m'est arrivé plusieur fois de le payer et de chercher l'erreur...
Depuis je suis passé sous Delphi, et la .... ben la rigueur n'est plus la meme du tout et je trouve au final que, comme dis plus haut, le faite d'avoir un code plus rigoureux aide beaucoup a la comprehension de celui ci, audela meme de toute recherche de performance.
A++
Qwaz

bonjour,

dans le même ordre d'idée, lorsqu'une méthode comporte plusieurs arguments optionnels préférez-vous écrire :

Code:

---

1 2	X = Classe.Methode ( , , ,1)

---

ou

Code:

---

1 2	X = Classe.Methode (Arg4:=1)

---

Merci,

Philippe

ucfoutu,

Pour éviter de continuer à faire des suppositions, j’ai fait quelque tests :

J’ai créé un classeur, auquel j’ai ajouté un UserForm avec 100 TextBoxes (créées par Copier/Coller successifs, je te rassure), et 1 CommandButton.

On est dans un cas particulièrement défavorable pour ma chapelle conviens-en :)

Voici le code :

Initialisation des 100 TextBoxes avec une valeur de 1 à 100. C’est instantané

Code:

---

1 2 3 4 5 6

Private Sub UserForm_Initialize() Dim i As Integer For i = 1 To 100 Controls("TextBox" & i) = i Next End Sub

---

Ensuite, le code associé au bouton reporte en ligne le contenu des 100 TextBoxes, et l’opération est répétée sur les 100 premières lignes de la feuille active.

Variante 1 sans .Value

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

Private Sub CommandButton1_Click() Dim Debut As Date, i As Integer, j As Integer Debut = Now With Range("A1") For i = 0 To 99 For j = 0 To 99 .Offset(i, j) = Controls("TextBox" & i + 1) Next j Next i End With MsgBox (Now - Debut) * 86400 Unload Me End Sub

---

Variante 2 sans .Value, mais avec une conversion en numérique : sans .Value, le contenu du TextBox est reporté comme du texte, et aligné à gauche dans les cellules d’Excel. C’est un des cas, où je trouve normal d’utiliser .Value, pour éviter la conversion.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

Private Sub CommandButton1_Click() Dim Debut As Date, i As Integer, j As Integer Debut = Now With Range("A1") For i = 0 To 99 For j = 0 To 99 .Offset(i, j) = CInt(Controls("TextBox" & i + 1)) Next j Next i End With MsgBox (Now - Debut) * 86400 Unload Me End Sub

---

Variante 3 avec .Value

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

Private Sub CommandButton1_Click() Dim Debut As Date, i As Integer, j As Integer Debut = Now With Range("A1") For i = 0 To 99 For j = 0 To 99 .Offset(i, j).Value = Controls("TextBox" & i + 1).Value Next j Next i End With MsgBox (Now - Debut) * 86400 Unload Me End Sub

---

J’ai fait tourner les 3 variantes 3 fois chacune. Now - Debut renvoie une fraction de journée, convertie en secondes en multipliant cette fraction par 86 400, le nb de secondes par jour (24 * 60 * 60).

Tous les résultats ont varié entre 21 et 25 secondes (maximum avec .Value : 24 secondes). Les conditions de test sont loin d’être parfaites : cela a été fait sous Excel 2007 sur un Mac où XP est installé via Parallels, un logiciel de virtualisation. D’autres classeure étaient ouverts, et je n’ai pas quitté Excel après chaque test.

Pour des résultats plus fins, on pourrait boucler sur 1 000 à 5 000 lignes au lieu de 100, mais je n’en ai pas eu la patience.

Cela semble confirmer que l’écart en temps d’éxécution (dans des conditions défavorables, puisqu’un traitement se contente rarement de seulement alimenter des cellules à partir de TextBoxes), est faible. Plus ou moins de 1 %, je l’ignore, mais non significatif.

Après cela, j’ai fait un dernier essai en passant en calcul manuel pendant le traitement, alors même qu’en principe aucun calcul n’est effectué sur l’unique feuille du classeur.

Variante 4 où l’on passe en calcul manuel

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Private Sub CommandButton1_Click() Dim Debut As Date, i As Integer, j As Integer Application.Calculation = xlManual Debut = Now With Range("A1") For i = 0 To 99 For j = 0 To 99 .Offset(i, j).Value = Controls("TextBox" & i + 1).Value Next j Next i End With MsgBox (Now - Debut) * 86400 Application.Calculation = xlAutomatic Unload Me End Sub

---

Le temps d’exécution a alors varié entre 6 et 8 secondes, soit une accélération d’un facteur 3 !

Cela semble bien démontrer qu’en terme de vitesse l’important n’est pas lié à l’indication explicite de la propriété par défaut, et que d’autres facteurs (la qualité de l’analyse et des algorithmes, par exemple) sont bien + importants.

Cordialement,

Maxence,

Citation:

---

Envoyé par Maxence HUBICHE

En agissant ainsi, tu ne te préoccupe donc que de l'instant présent dans la vie de ton code, et pas de sa pérennité au-delà de toi-même.
C'est dommage je trouve :(

---

J’ai cité principalement 4 objets, Range, TextBox, ListBox et ComboBox, pour lesquels, à de rares exceptions près, il me paraît superflu d’écrire .Value

J’ai du mal à croire que cela puisse poser un problème à quelqu’un qui devrait prendre la suite sur un de mes développements, non ? :)

Citation:

---

Envoyé par philben

bonjour,

Code:

---

1 2	X = Classe.Methode ( , , ,1)

---

ou

Code:

---

1 2	X = Classe.Methode (Arg4:=1)

---

Merci,

Philippe

---

Pour ma part, sans hésiter, je préfère les arguments nommés, à tous les coups. Pas forcément lorsque je n'utilise que le premier (mais très souvent quand même), et à quasi tous les coups dès que j'en utilise 2, même s'ils se suivent.

Philben,

Code:

---

1 2	X = Classe.Methode (Arg4:=1)

---

J’ignore pourquoi, mais j’ai toujours trouvé hideuse la succession d’un nom d’argument, de 2 symboles de ponctuation et d’une variable, sans le moindre espace, que l’on récupère couramment lors d’un enregistrement automatique.

Je ne n’écris jamais un truc pareil.

Il m’arrive parfois d’employer l’enregistrement auto pour un tri, parce que je ne connais pas par cœur l’ordre des arguments et les différentes constantes, et si je suis pressé de laisser le code obtenu tel quel, mais c’est rare.

Également pour des raisons de préférence typographique (rien avoir avec la programmation, plutôt avec l’esthétique), dans une formule Excel j’écrirai

Code:

---

=SI(MaVar < 100;...

---

et jamais

Code:

---

=SI(MaVar<100;...

---

Pour en revenir aux éléments non indiqués explicitement, j’écris en général

Code:

---

c.offset(1)

---

plutôt que

Code:

---

c.offset(1, 0)

---

Par contre, j’écris

Code:

---

c.offset(0, 1)

---

plutôt que

Code:

---

c.offset(, 0)

---

car je trouve que la virgule collée à la parenthèse nuit à une bonne lisibilité.

Cordialement,