Convertrir Programme fr en anglais - Page 2

Tu veux vérifier ça caractère par caractère??? Et après vous me parlez de taille et de vitesse???
Try fait ça de manière nettement plus efficace...

[EDIT: Et c'est valable autant pour les entiers de Martial Demolins que pour les noms de variable de Vertyos.]

naPO :
Je suis pas Try-phobe

Exemple :

Input "Entre un nombre positif entier de 1 à 10",nbr
abs(int(nbr))->nbr

Picétou

Sauf que si je rentre x, ça plante.

Ta méthode, elle rame. Pourquoi pas utiliser Try tout simplement?

Vertyos
: Sinon quand on demande un nom de variable, une boucle qui vérifie la chaine et teste si il est valide, c'est pas bien compliqué...

Et si je te mets un nom réservé, par exemple expand?

...

Kevin, ce qu'on essaye de t'expliquer, c'est qu'on a rien contre les Try, mais les utiliser en quantité astronomique... pas glop, quoi.

Kevin Kofler :
Tu veux vérifier ça caractère par caractère??? Et après vous me parlez de taille et de vitesse???
Try fait ça de manière nettement plus efficace...

Je commence vraiment à me demander si tu sais programmer en basic ? Déjà, ce test ne sera fait que quand on demande à l'utilisateur de rentrer une chaine : le programme est donc en pause. On se fiche totalement de savoir si il y aura ou non un délai d'un 10ième de seconde après la boite de dialogue ou non, c'est le déroulement du programme qu'il faut accélerer...
Quant au try, c'est une solution de facilité pour ceux qui ne savent pas ou ont la flemme de faire autrement. Il est completement buggé, et à ne pas utiliser sauf quand il n'y a rien d'autre, c'est à dire dans un seul et unique cas : expr().

naPO
: Kevin, ce qu'on essaye de t'expliquer, c'est qu'on a rien contre les Try, mais les utiliser en quantité astronomique... pas glop, quoi.

D'où l'intérêt d'en utiliser un globalement autour du programme entier.

la programmation de porc...

Vertyos
: Quant au try, c'est une solution de facilité pour ceux qui ne savent pas ou ont la flemme de faire autrement.

Bah non, c'est une solution d'optimisation en taille comme en vitesse!

Vertyos :
la programmation de porc...

Bah pourquoi? Tu as tous les nettoyages concentrés en un endroit, et ensuite tu fais un PassErr pour que l'utilisateur voie ce qu'il y a eu comme erreur.

C'est une source de bugs, cf cas avec SendData... Et ton post une excuse pour continuer à l'utiliser, alors que des méthodes fiables existent
C'est bien joli de me parler de flemme quand je dis que la compatibilité avec la langue est inutile, mais tu fais bien pire.

Bon, Kevin, essaye ça :

Local a
Loop
InputStr "Entre un ordre",a
try
newfold #a
else
endtry
Endloop

Tu vois, ici le try, n'englobe pas le prog... Et je te mets au défi de le faire bugger.

[edit] : na

Kevin Kofler
:

Vertyos :
la programmation de porc...

Bah pourquoi? Tu as tous les nettoyages concentrés en un endroit, et ensuite tu fais un PassErr pour que l'utilisateur voie ce qu'il y a eu comme erreur.

ça se voit que tu sais pas programmer en basic...

Il me semble que ce genre de code bug sous certains AMS :

prgm test()
local a
"a"->a
goto #a
lbl a
endprgm

prgm bug()
try
test()
else
text "Bug de la fonction try()"
endtry
endprgm

Sous AMS 2.09, ça marche, et je n'ai rien d'autre pour tester, mais il me semble avoir déjà eu des problèmes avec ça.

AMS 2.05, ça marche ^^

Martial>

Bah sinon il y a le magnifique try:send a:endtry avec receive de l'autre coté, qui non seulement gele le programme mais empeche de le couper avec ON

Vertyos
: C'est une source de bugs, cf cas avec SendData...

Il suffit de ne pas mettre le Try dans une boucle.

Et ton post une excuse pour continuer à l'utiliser, alors que des méthodes fiables existent

Try est fiable si on l'utilise correctement.

C'est bien joli de me parler de flemme quand je dis que la compatibilité avec la langue est inutile, mais tu fais bien pire.

C'est bien joli de me parler de programmes gros et lents quand tu dis que la compatibilité avec la langue est inutile, mais tu fais bien pire.

Martial Demolins
: oué cool pour le débogage

Tu le mets pour le release seulement.

en plus s'il y a des vars globales créées de manière automatique (xx-> #(abc&y)),

Beurrrrrrrk!!!

naPO
: Tu vois, ici le try, n'englobe pas le prog... Et je te mets au défi de le faire bugger.

L'intérêt de faire un Try global est d'éviter d'en mettre un à chaque instruction, justement. D'autant plus qu'il est facile d'en oublier si on fait comme ça.

Martial Demolins
:

Kevin Kofler :
ensuite tu fais un PassErr pour que l'utilisateur voie ce qu'il y a eu comme erreur.

pas d'accord, ce n'est à priori pas à l'utilisateur final de voir tes saletés de programmation, il n'est qu'utilisateur et non programmeur #prog_crado spotted#

Alors tu affiches autre chose ou rien du tout. Le Try le permet, justement.

Vertyos :
Bah sinon il y a le magnifique try:send a:endtry avec receive de l'autre coté, qui non seulement gele le programme mais empeche de le couper avec ON

Seulement si tu le fais dans une boucle.

Et pour toi c'est pas un bug, ça ? FL avait déjà remarqué que la fonction try était codée n'importe comment quand il programmait FLib, faudrait voir sur son site si y'a des infos.

Vertyos
: Et pour toi c'est pas un bug, ça ?

Si tu utilises Try de la manière que je conseille, ce n'est pas dans une boucle, donc il n'y a pas de problème.

Martial Demolins :
et c'est incorrect de le faire (cf ./53) ????????????????????

Quoi? Les variables globales auto-générées? Variables globales = beurk...

Bon, on va faire encore joujou avec les cites

Kevin Kofler
:

Vertyos
: C'est une source de bugs, cf cas avec SendData...

Il suffit de ne pas mettre le Try dans une boucle.

Et ton post une excuse pour continuer à l'utiliser, alors que des méthodes fiables existent

Try est fiable si on l'utilise correctement.

Bah là, Vertyos utilise correctement Try, et il dit que ça bug

C'est bien joli de me parler de flemme quand je dis que la compatibilité avec la langue est inutile, mais tu fais bien pire.

C'est bien joli de me parler de programmes gros et lents quand tu dis que la compatibilité avec la langue est inutile, mais tu fais bien pire.

Intérêt ?

Martial Demolins
: oué cool pour le débogage

Tu le mets pour le release seulement.

Justement, NAN !

en plus s'il y a des vars globales créées de manière automatique (xx-> #(abc&y)),

Beurrrrrrrk!!!

Bof, ça me choque pas plusque ça, du moment qu'on sait pourquoi on fait ça.

naPO
: Tu vois, ici le try, n'englobe pas le prog... Et je te mets au défi de le faire bugger.

L'intérêt de faire un Try global est d'éviter d'en mettre un à chaque instruction, justement. D'autant plus qu'il est facile d'en oublier si on fait comme ça.

[/cite]
-> TU <- peux oublier.
Et puis c'est vrai qu'un Try est rudement conseillé pour des commandes du genre Disphome, Local, etc...

Martial Demolins
:

Kevin Kofler :
ensuite tu fais un PassErr pour que l'utilisateur voie ce qu'il y a eu comme erreur.

pas d'accord, ce n'est à priori pas à l'utilisateur final de voir tes saletés de programmation, il n'est qu'utilisateur et non programmeur #prog_crado spotted#

Alors tu affiches autre chose ou rien du tout. Le Try le permet, justement.

Nom de diouss, utiliser des Try à la toque pour une release finale, c'est porcasse...

Kevin Kofler :
Si tu utilises Try de la manière que je conseille, ce n'est pas dans une boucle, donc il n'y a pas de problème.

C'est comme ça que tu corriges un bug ? En évitant le cas où il se déclanche ?