Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je veux que ma procédure
me retourne quelque chose, je peux faire une fonction qui me retourne une
valeur OU BIEN faire tout simplement un sub dont je vais passer la valeur
par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence (ByRef) car je ne
vois pas vraiment d'avantage à utiliser plutôt FUNCTION à la place de SUB...
Je suis juste curieux de voir comment vous procédez.
tu peux utiliser aussi Property Get dans une classe ou une form
houbahop2003
Franchement, ca n'a pas d'importance d'utiliser des Fonctions ou des subs avec un paramétre byref; les deux marchent bien.
Personellement, j'aime bien utiliser les fonctions quand c'est pour retourner une valeur une valeur booleenne, ou meme si ce n'est pas un booleen et que je dois tester le retour.
Je préfére écrire (et lire )
if CompterRouesVoiture(MaVoiture)="4" then .... traitement ... end if
que:
dim l_iNombreRoues as integer call CompterRouesVoiture(l_iNombreRoues) if l_iNombreRoues = 4 then ... Traitement ... end if
D.
"+The_Taco+" a écrit dans le message de news:
Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je veux que ma
procédure
me retourne quelque chose, je peux faire une fonction qui me retourne une valeur OU BIEN faire tout simplement un sub dont je vais passer la valeur par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence (ByRef) car je ne vois pas vraiment d'avantage à utiliser plutôt FUNCTION à la place de
SUB...
Je suis juste curieux de voir comment vous procédez.
Bonne journée à tous!
Franchement, ca n'a pas d'importance d'utiliser des Fonctions ou des subs
avec un paramétre byref; les deux marchent bien.
Personellement, j'aime bien utiliser les fonctions quand c'est pour
retourner une valeur une valeur booleenne, ou meme si ce n'est pas un
booleen et que je dois tester le retour.
Je préfére écrire (et lire )
if CompterRouesVoiture(MaVoiture)="4" then
.... traitement ...
end if
que:
dim l_iNombreRoues as integer
call CompterRouesVoiture(l_iNombreRoues)
if l_iNombreRoues = 4 then
... Traitement ...
end if
D.
"+The_Taco+" <dominic.feron@dessausoprin.com> a écrit dans le message de
news: eLVqSWMnEHA.3712@TK2MSFTNGP15.phx.gbl...
Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je veux que ma
procédure
me retourne quelque chose, je peux faire une fonction qui me retourne une
valeur OU BIEN faire tout simplement un sub dont je vais passer la valeur
par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence (ByRef) car je ne
vois pas vraiment d'avantage à utiliser plutôt FUNCTION à la place de
SUB...
Je suis juste curieux de voir comment vous procédez.
Franchement, ca n'a pas d'importance d'utiliser des Fonctions ou des subs avec un paramétre byref; les deux marchent bien.
Personellement, j'aime bien utiliser les fonctions quand c'est pour retourner une valeur une valeur booleenne, ou meme si ce n'est pas un booleen et que je dois tester le retour.
Je préfére écrire (et lire )
if CompterRouesVoiture(MaVoiture)="4" then .... traitement ... end if
que:
dim l_iNombreRoues as integer call CompterRouesVoiture(l_iNombreRoues) if l_iNombreRoues = 4 then ... Traitement ... end if
D.
"+The_Taco+" a écrit dans le message de news:
Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je veux que ma
procédure
me retourne quelque chose, je peux faire une fonction qui me retourne une valeur OU BIEN faire tout simplement un sub dont je vais passer la valeur par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence (ByRef) car je ne vois pas vraiment d'avantage à utiliser plutôt FUNCTION à la place de
SUB...
Je suis juste curieux de voir comment vous procédez.
Bonne journée à tous!
Eric
+The_Taco+ brought next idea :
Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je veux que ma procédure me retourne quelque chose, je peux faire une fonction qui me retourne une valeur OU BIEN faire tout simplement un sub dont je vais passer la valeur par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence (ByRef) car je ne vois pas vraiment d'avantage à utiliser plutôt FUNCTION à la place de SUB... Je suis juste curieux de voir comment vous procédez.
Bonne journée à tous!
Bonsoir, Cela dépend de ce que tu veux. Tu peux très bien aussi passer une valeur par un évenement. Par exemple dans le cas d'un développement com+.
@+ Eric
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
+The_Taco+ brought next idea :
Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je veux que ma procédure
me retourne quelque chose, je peux faire une fonction qui me retourne une
valeur OU BIEN faire tout simplement un sub dont je vais passer la valeur
par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence (ByRef) car je ne
vois pas vraiment d'avantage à utiliser plutôt FUNCTION à la place de SUB...
Je suis juste curieux de voir comment vous procédez.
Bonne journée à tous!
Bonsoir,
Cela dépend de ce que tu veux. Tu peux très bien aussi passer une
valeur par un évenement. Par exemple dans le cas d'un développement
com+.
@+ Eric
--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je veux que ma procédure me retourne quelque chose, je peux faire une fonction qui me retourne une valeur OU BIEN faire tout simplement un sub dont je vais passer la valeur par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence (ByRef) car je ne vois pas vraiment d'avantage à utiliser plutôt FUNCTION à la place de SUB... Je suis juste curieux de voir comment vous procédez.
Bonne journée à tous!
Bonsoir, Cela dépend de ce que tu veux. Tu peux très bien aussi passer une valeur par un évenement. Par exemple dans le cas d'un développement com+.
@+ Eric
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
mousnynao
Bonjour,
Voici une opinion très différente et qui n'engage que moi. Dans mes premier cours d'informatique, il y a de cela près de 20 ans aujourd'hui, la différence était énorme à cause de la vitesse des machines.
En fait, une fois interprété en assembleur, on pouvait voir que lors de l'appel d'une SUB, tous les registres étaient sauvegarder avant l'exécution d'une SUB.
Par opposition, lors de l'appel d'une fonction, seulement le "compteur de programme était sauvegarder". Par conséquent le choix était fondé sur la neccesssité de la rapidité.
Ayant moi-même conçu un convertisseur analogue/digital de 12 bits à l'époque (hardware et software), je puis vous dire que les millisecondes gagnées en remplaçant une SUB par une FUNCTION était très importantes.
Toujours selon la théorie qui me fut enseigné, une fonction représentait une procédure ne contenant pas plus de 5 lignes de code, par opposition à une procédure qui pouvait en contenir 15 lignes (sur un total de 26 lignes à l'écran).
Par souci de convivialité, une procédure se devait d'être visible complètement sur un écran, d'où le 15 lignes de codes, plus les lignes d'informations statiques (commentaires).
Bien entendu, l'évolution des processeur d'aujourd'hui a quelque peu altéré ces raisons.
mousnynao!
-----Message d'origine----- Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je
veux que ma procédure
me retourne quelque chose, je peux faire une fonction qui
me retourne une
valeur OU BIEN faire tout simplement un sub dont je vais
passer la valeur
par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence
(ByRef) car je ne
vois pas vraiment d'avantage à utiliser plutôt FUNCTION à
la place de SUB...
Je suis juste curieux de voir comment vous procédez.
Bonne journée à tous!
.
Bonjour,
Voici une opinion très différente et qui n'engage
que moi. Dans mes premier cours d'informatique,
il y a de cela près de 20 ans aujourd'hui, la différence
était énorme à cause de la vitesse des machines.
En fait, une fois interprété en assembleur, on pouvait
voir que lors de l'appel d'une SUB, tous les registres
étaient sauvegarder avant l'exécution d'une SUB.
Par opposition, lors de l'appel d'une fonction, seulement
le "compteur de programme était sauvegarder". Par
conséquent
le choix était fondé sur la neccesssité de la rapidité.
Ayant moi-même conçu un convertisseur analogue/digital
de 12 bits à l'époque (hardware et software), je puis
vous dire que les millisecondes gagnées en remplaçant
une SUB par une FUNCTION était très importantes.
Toujours selon la théorie qui me fut enseigné, une
fonction
représentait une procédure ne contenant pas plus de 5
lignes
de code, par opposition à une procédure qui pouvait en
contenir 15 lignes (sur un total de 26 lignes à l'écran).
Par souci de convivialité, une procédure se devait d'être
visible complètement sur un écran, d'où le 15 lignes de
codes, plus les lignes d'informations statiques
(commentaires).
Bien entendu, l'évolution des processeur d'aujourd'hui
a quelque peu altéré ces raisons.
mousnynao!
-----Message d'origine-----
Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je
veux que ma procédure
me retourne quelque chose, je peux faire une fonction qui
me retourne une
valeur OU BIEN faire tout simplement un sub dont je vais
passer la valeur
par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence
(ByRef) car je ne
vois pas vraiment d'avantage à utiliser plutôt FUNCTION à
la place de SUB...
Je suis juste curieux de voir comment vous procédez.
Voici une opinion très différente et qui n'engage que moi. Dans mes premier cours d'informatique, il y a de cela près de 20 ans aujourd'hui, la différence était énorme à cause de la vitesse des machines.
En fait, une fois interprété en assembleur, on pouvait voir que lors de l'appel d'une SUB, tous les registres étaient sauvegarder avant l'exécution d'une SUB.
Par opposition, lors de l'appel d'une fonction, seulement le "compteur de programme était sauvegarder". Par conséquent le choix était fondé sur la neccesssité de la rapidité.
Ayant moi-même conçu un convertisseur analogue/digital de 12 bits à l'époque (hardware et software), je puis vous dire que les millisecondes gagnées en remplaçant une SUB par une FUNCTION était très importantes.
Toujours selon la théorie qui me fut enseigné, une fonction représentait une procédure ne contenant pas plus de 5 lignes de code, par opposition à une procédure qui pouvait en contenir 15 lignes (sur un total de 26 lignes à l'écran).
Par souci de convivialité, une procédure se devait d'être visible complètement sur un écran, d'où le 15 lignes de codes, plus les lignes d'informations statiques (commentaires).
Bien entendu, l'évolution des processeur d'aujourd'hui a quelque peu altéré ces raisons.
mousnynao!
-----Message d'origine----- Salut les mecs, une petite question de philosophie.
Dans VB, on peut faire des SUB et des FUNCTION. Si je
veux que ma procédure
me retourne quelque chose, je peux faire une fonction qui
me retourne une
valeur OU BIEN faire tout simplement un sub dont je vais
passer la valeur
par référence dont je veux le résultat.
Moi je suis plutôt du type SUB avec valeur par référence
(ByRef) car je ne
vois pas vraiment d'avantage à utiliser plutôt FUNCTION à
la place de SUB...
Je suis juste curieux de voir comment vous procédez.
Bonne journée à tous!
.
abcd
Je dirais comme d'autres que cela peut dépendre de l'usage.
Typiquement il est agréable de pouvoir utiliser une fonction dans une formule. Exemple: tu as créé une fonction qui formate une entrée texte. Tu peux appeler les choses de cette façon: Texte= "abc" & modif(entrée) & "." La chose devient plus lourde sans fonction.
De plus, il est parfois risqué de modifier des arguments selon les routines... (si son but est explicitement de passer des modifications, on s'en souvient, mais parfois, on pourrait risquer de changer une variable de façon non attendue).
Enfin selon l'application cela peut changer des choses: exemple sous excel: une fonction ne peut modifier de cellule, par contre peut être appelée depuis une cellule. (une sous-routine c'est l'inverse)
Je dirais comme d'autres que cela peut dépendre de l'usage.
Typiquement il est agréable de pouvoir utiliser une fonction dans une
formule.
Exemple: tu as créé une fonction qui formate une entrée texte.
Tu peux appeler les choses de cette façon: Texte= "abc" & modif(entrée) &
"."
La chose devient plus lourde sans fonction.
De plus, il est parfois risqué de modifier des arguments selon les
routines... (si son but est explicitement de passer des modifications, on
s'en souvient, mais parfois, on pourrait risquer de changer une variable de
façon non attendue).
Enfin selon l'application cela peut changer des choses: exemple sous excel:
une fonction ne peut modifier de cellule, par contre peut être appelée
depuis une cellule. (une sous-routine c'est l'inverse)
Je dirais comme d'autres que cela peut dépendre de l'usage.
Typiquement il est agréable de pouvoir utiliser une fonction dans une formule. Exemple: tu as créé une fonction qui formate une entrée texte. Tu peux appeler les choses de cette façon: Texte= "abc" & modif(entrée) & "." La chose devient plus lourde sans fonction.
De plus, il est parfois risqué de modifier des arguments selon les routines... (si son but est explicitement de passer des modifications, on s'en souvient, mais parfois, on pourrait risquer de changer une variable de façon non attendue).
Enfin selon l'application cela peut changer des choses: exemple sous excel: une fonction ne peut modifier de cellule, par contre peut être appelée depuis une cellule. (une sous-routine c'est l'inverse)
Patrice Henrio
L'intérêt d'une fonction c'est aussi la composition.
Supposons un jeu qui à partir d'une position donnée renvoie une liste de coups possibles et une autre qui à partir d'une listes de coups renvoie le "meilleur" et enfin une troisième qui à partir d'une position et d'un coup renvoie une nouvelle position
On écrira simplement Position=NouvellePosition(meilleurCoup(ListeDeCoups(position)),Position)
Le jeu entier pourrait être
Position=PositionInitiale While Position<>PositionBloquée Position=NouvellePosition(meilleurCoup(ListeDeCoups(position)),Position)
Wend
"abcd" a écrit dans le message de news: %
Je dirais comme d'autres que cela peut dépendre de l'usage.
Typiquement il est agréable de pouvoir utiliser une fonction dans une formule. Exemple: tu as créé une fonction qui formate une entrée texte. Tu peux appeler les choses de cette façon: Texte= "abc" & modif(entrée) & "." La chose devient plus lourde sans fonction.
De plus, il est parfois risqué de modifier des arguments selon les routines... (si son but est explicitement de passer des modifications, on s'en souvient, mais parfois, on pourrait risquer de changer une variable de façon non attendue).
Enfin selon l'application cela peut changer des choses: exemple sous excel: une fonction ne peut modifier de cellule, par contre peut être appelée depuis une cellule. (une sous-routine c'est l'inverse)
L'intérêt d'une fonction c'est aussi la composition.
Supposons un jeu qui à partir d'une position donnée renvoie une liste de
coups possibles et une autre qui à partir d'une listes de coups renvoie le
"meilleur" et enfin une troisième qui à partir d'une position et d'un coup
renvoie une nouvelle position
On écrira simplement
Position=NouvellePosition(meilleurCoup(ListeDeCoups(position)),Position)
Le jeu entier pourrait être
Position=PositionInitiale
While Position<>PositionBloquée
Position=NouvellePosition(meilleurCoup(ListeDeCoups(position)),Position)
Wend
"abcd" <anonymous@discussions.microsoft.com> a écrit dans le message de
news: %23h3z21RnEHA.3628@TK2MSFTNGP09.phx.gbl...
Je dirais comme d'autres que cela peut dépendre de l'usage.
Typiquement il est agréable de pouvoir utiliser une fonction dans une
formule.
Exemple: tu as créé une fonction qui formate une entrée texte.
Tu peux appeler les choses de cette façon: Texte= "abc" & modif(entrée) &
"."
La chose devient plus lourde sans fonction.
De plus, il est parfois risqué de modifier des arguments selon les
routines... (si son but est explicitement de passer des modifications, on
s'en souvient, mais parfois, on pourrait risquer de changer une variable
de
façon non attendue).
Enfin selon l'application cela peut changer des choses: exemple sous
excel:
une fonction ne peut modifier de cellule, par contre peut être appelée
depuis une cellule. (une sous-routine c'est l'inverse)
L'intérêt d'une fonction c'est aussi la composition.
Supposons un jeu qui à partir d'une position donnée renvoie une liste de coups possibles et une autre qui à partir d'une listes de coups renvoie le "meilleur" et enfin une troisième qui à partir d'une position et d'un coup renvoie une nouvelle position
On écrira simplement Position=NouvellePosition(meilleurCoup(ListeDeCoups(position)),Position)
Le jeu entier pourrait être
Position=PositionInitiale While Position<>PositionBloquée Position=NouvellePosition(meilleurCoup(ListeDeCoups(position)),Position)
Wend
"abcd" a écrit dans le message de news: %
Je dirais comme d'autres que cela peut dépendre de l'usage.
Typiquement il est agréable de pouvoir utiliser une fonction dans une formule. Exemple: tu as créé une fonction qui formate une entrée texte. Tu peux appeler les choses de cette façon: Texte= "abc" & modif(entrée) & "." La chose devient plus lourde sans fonction.
De plus, il est parfois risqué de modifier des arguments selon les routines... (si son but est explicitement de passer des modifications, on s'en souvient, mais parfois, on pourrait risquer de changer une variable de façon non attendue).
Enfin selon l'application cela peut changer des choses: exemple sous excel: une fonction ne peut modifier de cellule, par contre peut être appelée depuis une cellule. (une sous-routine c'est l'inverse)
