Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Visual Basic Valeur retournée par une fonction

Valeur retournée par une fonction

8 réponses
Avatar
teddy
Bonjour,

J'ai crée des fonctions qui agissent sur des BASES ou des Objets et qui ne
retournent rien d'utile.

Je voudrais leur faire retourner le Err.Number par exemple ou bien la chaîne
"OK" pour que le programme appelant sache simplement si la fonction a marché ou
bien si elle a "planté".

Bien sûr, dans d'autres cas, si la fonction retourne une valeur utilisable par
le programme appelant, la question ne se pose pas. La valeur retournée doit être
d'un type attendu et pas un autre.

Dans le cas où on n'exploite pas forcément la valeur retournée, je voudrais donc
savoir si on privilégie le retour d'un Integer pour des raisons d'optimisation
ou de "règle de l'art ou d'habitude de programmation" plutôt qu'un String ou
bien si c'est sans aucune importance ?
Merci pour votre avis.

Ted
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Christian Hubert-Hugoud
Bonjour,

Pour des raison de performances, on retourne des valeurs numériques, zéro si
la fonction est OK. Le type à recommander pour les PC 32 bits (il n'y a plus
que cela) est le long, pas l'integer. Le long ne nécessite qu'un cycle
processeur.

Christian

" teddy" a écrit dans le message de news:
e$
Bonjour,

J'ai crée des fonctions qui agissent sur des BASES ou des Objets et qui ne
retournent rien d'utile.

Je voudrais leur faire retourner le Err.Number par exemple ou bien la
chaîne "OK" pour que le programme appelant sache simplement si la fonction
a marché ou bien si elle a "planté".

Bien sûr, dans d'autres cas, si la fonction retourne une valeur utilisable
par le programme appelant, la question ne se pose pas. La valeur retournée
doit être d'un type attendu et pas un autre.

Dans le cas où on n'exploite pas forcément la valeur retournée, je
voudrais donc savoir si on privilégie le retour d'un Integer pour des
raisons d'optimisation ou de "règle de l'art ou d'habitude de
programmation" plutôt qu'un String ou bien si c'est sans aucune importance
?
Merci pour votre avis.

Ted



Avatar
LE TROLL
Salut,

Tu dis "J'ai crée des fonctions.... retourner rien d'utile", lol !
La fonction n'est pas native du Basic, à 99% on peut écrire sans aucune
fonction... Tout peut passer par procédures, variables locales et globales...
Avec un standard qui dépasse un peu le demi giga octet de RAM et un processeur à
400 Mhz, mettre 1 ou 2 ko de plus ou de moins en variables globales n'a aucune
importance généralement...
---------------


" teddy" a écrit dans le message de news:
e$
Bonjour,

J'ai crée des fonctions qui agissent sur des BASES ou des Objets et qui ne
retournent rien d'utile.

Je voudrais leur faire retourner le Err.Number par exemple ou bien la chaîne
"OK" pour que le programme appelant sache simplement si la fonction a marché
ou bien si elle a "planté".

Bien sûr, dans d'autres cas, si la fonction retourne une valeur utilisable par
le programme appelant, la question ne se pose pas. La valeur retournée doit
être d'un type attendu et pas un autre.

Dans le cas où on n'exploite pas forcément la valeur retournée, je voudrais
donc savoir si on privilégie le retour d'un Integer pour des raisons
d'optimisation ou de "règle de l'art ou d'habitude de programmation" plutôt
qu'un String ou bien si c'est sans aucune importance ?
Merci pour votre avis.

Ted



Avatar
scraper
Bonjour teddy, dans le message
news:e$
tu disais :


Bonjour,

J'ai crée des fonctions qui agissent sur des BASES ou des Objets et
qui ne retournent rien d'utile.



à mon humble avis, si ta fonction ne retourne rien d'utile (rien tout court
?) transforme la en Sub ;-)




--

Adresse invalide
Merci de répondre sur le forum ...
http://scraper.chez.tiscali.fr

scraper
Avatar
jean-marc
" teddy" wrote in message
news:e$
Bonjour,

J'ai crée des fonctions qui agissent sur des BASES ou des Objets et qui ne
retournent rien d'utile.

Je voudrais leur faire retourner le Err.Number par exemple ou bien la


chaîne
"OK" pour que le programme appelant sache simplement si la fonction a


marché ou
bien si elle a "planté".

Bien sûr, dans d'autres cas, si la fonction retourne une valeur utilisable


par
le programme appelant, la question ne se pose pas. La valeur retournée


doit être
d'un type attendu et pas un autre.

Dans le cas où on n'exploite pas forcément la valeur retournée, je


voudrais donc
savoir si on privilégie le retour d'un Integer pour des raisons


d'optimisation
ou de "règle de l'art ou d'habitude de programmation" plutôt qu'un String


ou
bien si c'est sans aucune importance ?



Hello,

une bonne habitude est de faire retourner une
valeur numérique (un long, comme le dit Christian
est la meilleure option).
On peut adopter les conventions que l'on veut,
par exemple 0 = OK, 1 = PAS OK

Si on a besoin de connaitre des choses additionnelles en
cas d'erreur, on renseigne des paramètres ByRef.

Voici un exemple de bonne pratique:

' 8<--------------------------------------

Option Explicit

Const ERR_DIV_BY_ZERO As Long = -1
Const RET_ERR As Long = 1
Const RET_OK As Long = 0

Private Sub Command1_Click()
Dim status As Long
Dim err_code As Long
Dim err_msg As String
Dim n1 As Double, n2 As Double, result As Double
Dim dbg As String

status = DivisePar(n1, n2, result, err_code, err_msg)
If status = RET_OK Then
' tout va bien, on continue
MsgBox "OK"
Else
' tout va mal
dbg = "erreur dans DivisePar()" & vbCrLf
dbg = dbg & "Code erreur : " & err_code & vbCrLf
dbg = dbg & "Description erreur : " & err_msg
MsgBox dbg
End If

End Sub

'
' Calcule div/dvd, met le résultat dans result
' En cas d'erreur, retourne RET_OK (0) sinon retourne RET_ERR (1)
' En cas d'erreur, on renseigne errCode et errMsg
Public Function DivisePar(ByVal div As Double, _
ByVal dvd As Double, _
ByRef result As Double, _
ByRef errCode As Long, _
ByRef errMsg As String) As Double

If dvd = 0 Then ' division par zero demandée
errCode = ERR_DIV_BY_ZERO
errMsg = "Division par zero"
DivisePar = RET_ERR
Else
result = div / dvd
DivisePar = RET_OK
End If
End Function

' 8<------------------------------------

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
ng
Salut,

Salut,

Tu dis "J'ai crée des fonctions.... retourner rien d'utile", lol !
La fonction n'est pas native du Basic, à 99% on peut écrire sans
aucune
fonction... Tout peut passer par procédures, variables locales et
globales... Avec un standard qui dépasse un peu le demi giga octet de RAM
et un processeur à 400 Mhz, mettre 1 ou 2 ko de plus ou de moins en
variables globales n'a aucune importance généralement...
---------------



Oui mais c'est moins propre et apres on ne s'y retrouve plus.



--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
Avatar
LE TROLL
Salut,

C'est pareil, question de goût, faut arrêter d'imposer un critère quand il y
en a plusieurs possible, liberté...

De balader tes variables entre fonctions, ça bouffe plus de code en fait,
plus de temps à écrire, et quand on veut tester ailleurs, ben on n'a aucune
valeur puisque c'est local... C'est un choix perso !

C'est pas toi qui avait dit "+1" en parlant de moi ???

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


"ng" a écrit dans le message de news:
%23ILi$
Salut,

Salut,

Tu dis "J'ai crée des fonctions.... retourner rien d'utile", lol !
La fonction n'est pas native du Basic, à 99% on peut écrire sans
aucune
fonction... Tout peut passer par procédures, variables locales et
globales... Avec un standard qui dépasse un peu le demi giga octet de RAM
et un processeur à 400 Mhz, mettre 1 ou 2 ko de plus ou de moins en
variables globales n'a aucune importance généralement...
---------------



Oui mais c'est moins propre et apres on ne s'y retrouve plus.



--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/


Avatar
LE TROLL
Pleins d'allusions, tu dis "bonne pratique"...

Y a pas de bonne pratique tant que ça fonctionne et que ça reste raisonnable
!
C'est même uniquement une question de mode (gosub, goto, function, sub)...
On laisse les gens libres, y en a qui ont de bonne pratique comme tu dis, mais
qui font des programmes nuls!
Le résultat prime tout, on n'est pas en philosophie...
------------------


"jean-marc" a écrit dans le message de news:
43183917$0$6578$
" teddy" wrote in message
news:e$
Bonjour,

J'ai crée des fonctions qui agissent sur des BASES ou des Objets et qui ne
retournent rien d'utile.

Je voudrais leur faire retourner le Err.Number par exemple ou bien la


chaîne
"OK" pour que le programme appelant sache simplement si la fonction a


marché ou
bien si elle a "planté".

Bien sûr, dans d'autres cas, si la fonction retourne une valeur utilisable


par
le programme appelant, la question ne se pose pas. La valeur retournée


doit être
d'un type attendu et pas un autre.

Dans le cas où on n'exploite pas forcément la valeur retournée, je


voudrais donc
savoir si on privilégie le retour d'un Integer pour des raisons


d'optimisation
ou de "règle de l'art ou d'habitude de programmation" plutôt qu'un String


ou
bien si c'est sans aucune importance ?



Hello,

une bonne habitude est de faire retourner une
valeur numérique (un long, comme le dit Christian
est la meilleure option).
On peut adopter les conventions que l'on veut,
par exemple 0 = OK, 1 = PAS OK

Si on a besoin de connaitre des choses additionnelles en
cas d'erreur, on renseigne des paramètres ByRef.

Voici un exemple de bonne pratique:

' 8<--------------------------------------

Option Explicit

Const ERR_DIV_BY_ZERO As Long = -1
Const RET_ERR As Long = 1
Const RET_OK As Long = 0

Private Sub Command1_Click()
Dim status As Long
Dim err_code As Long
Dim err_msg As String
Dim n1 As Double, n2 As Double, result As Double
Dim dbg As String

status = DivisePar(n1, n2, result, err_code, err_msg)
If status = RET_OK Then
' tout va bien, on continue
MsgBox "OK"
Else
' tout va mal
dbg = "erreur dans DivisePar()" & vbCrLf
dbg = dbg & "Code erreur : " & err_code & vbCrLf
dbg = dbg & "Description erreur : " & err_msg
MsgBox dbg
End If

End Sub

'
' Calcule div/dvd, met le résultat dans result
' En cas d'erreur, retourne RET_OK (0) sinon retourne RET_ERR (1)
' En cas d'erreur, on renseigne errCode et errMsg
Public Function DivisePar(ByVal div As Double, _
ByVal dvd As Double, _
ByRef result As Double, _
ByRef errCode As Long, _
ByRef errMsg As String) As Double

If dvd = 0 Then ' division par zero demandée
errCode = ERR_DIV_BY_ZERO
errMsg = "Division par zero"
DivisePar = RET_ERR
Else
result = div / dvd
DivisePar = RET_OK
End If
End Function

' 8<------------------------------------

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;





Avatar
teddy
Il me semblait bien que le code retourné par une fonction était généralement un
numérique de type long comme dans tous les exemples de code que j'ai pu
consulter.

Il est vrai aussi que j'aurais pu utiliser des procédures SUB mais les fonctions
sont bien pratiques pour la réutilisation dans divers programmes.

Merci pour vos réponses.

Ted


"jean-marc" a écrit dans le message de news:
43183917$0$6578$
" teddy" wrote in message
news:e$
Bonjour,

J'ai crée des fonctions qui agissent sur des BASES ou des Objets et qui ne
retournent rien d'utile.

Je voudrais leur faire retourner le Err.Number par exemple ou bien la


chaîne
"OK" pour que le programme appelant sache simplement si la fonction a


marché ou
bien si elle a "planté".

Bien sûr, dans d'autres cas, si la fonction retourne une valeur utilisable


par
le programme appelant, la question ne se pose pas. La valeur retournée


doit être
d'un type attendu et pas un autre.

Dans le cas où on n'exploite pas forcément la valeur retournée, je


voudrais donc
savoir si on privilégie le retour d'un Integer pour des raisons


d'optimisation
ou de "règle de l'art ou d'habitude de programmation" plutôt qu'un String


ou
bien si c'est sans aucune importance ?



Hello,

une bonne habitude est de faire retourner une
valeur numérique (un long, comme le dit Christian
est la meilleure option).
On peut adopter les conventions que l'on veut,
par exemple 0 = OK, 1 = PAS OK

Si on a besoin de connaitre des choses additionnelles en
cas d'erreur, on renseigne des paramètres ByRef.

Voici un exemple de bonne pratique:

' 8<--------------------------------------

Option Explicit

Const ERR_DIV_BY_ZERO As Long = -1
Const RET_ERR As Long = 1
Const RET_OK As Long = 0

Private Sub Command1_Click()
Dim status As Long
Dim err_code As Long
Dim err_msg As String
Dim n1 As Double, n2 As Double, result As Double
Dim dbg As String

status = DivisePar(n1, n2, result, err_code, err_msg)
If status = RET_OK Then
' tout va bien, on continue
MsgBox "OK"
Else
' tout va mal
dbg = "erreur dans DivisePar()" & vbCrLf
dbg = dbg & "Code erreur : " & err_code & vbCrLf
dbg = dbg & "Description erreur : " & err_msg
MsgBox dbg
End If

End Sub

'
' Calcule div/dvd, met le résultat dans result
' En cas d'erreur, retourne RET_OK (0) sinon retourne RET_ERR (1)
' En cas d'erreur, on renseigne errCode et errMsg
Public Function DivisePar(ByVal div As Double, _
ByVal dvd As Double, _
ByRef result As Double, _
ByRef errCode As Long, _
ByRef errMsg As String) As Double

If dvd = 0 Then ' division par zero demandée
errCode = ERR_DIV_BY_ZERO
errMsg = "Division par zero"
DivisePar = RET_ERR
Else
result = div / dvd
DivisePar = RET_OK
End If
End Function

' 8<------------------------------------

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;