Bug ou non bug ?

Salut tout le monde.

Dans mon post ‘Si ceci n’est pas un bug, alors je ne comprends plus rien !’ dans la rubrique ‘Un bug dans PANORAMIC?’,

Jack a écrit:

Quand je vois "bug" dans le titre d'un message, je sursaute et j'essaye de voir immédiatement de quoi il s'agit.

Alors, pour ne pas faire sursauter Jack, je reporte ici la question, en espérant déclencher une discussion autour de cette question qui n’est pas un problème en soi, mais simplement un point de vue.

JL35 a écrit:

Appeler une variable for c'est vraiment chercher les embêtements.

Je ne cherche absolument pas les embêtements. Mais je constate un fait.
Je n’utilise jamais des mots réservés comme noms de variables.
D’ailleurs, dans les programmes que j’ai postés sur le FORUM, j’ai toujours utilisé des noms de variables assez parlants qui indiquent clairement leur sens.

Un langage de programmation doit faire éviter au programmeur de s’induire en erreur et ceci avec une syntaxe rigide qui ne souffre aucune exception.
Dans le code suivant

Code:

Dim for
For= 1
Print for

A l’exécution le résultat est 1 (et je ne dis pas si c’est correct ou non)
Mais ce code

Code:

Dim for
For = 1
Print for

Le système répond par un message d’erreur ‘ (10) More For than Next’
A mon humble avis, ceci manque de rigueur : pourquoi c’est correct dans le 1er cas et non correct dans le second ?


Pour voir un peu clair, j’ai testé quelques langages de programmations et voici le verdict.

QB64 :

Code:

DIM FOR
FOR = 1
PRINT FOR

A l’execution, message d’erreur ---> ‘Name already in use on line 1’

FREEBASIC:

Code:

DIM FOR
FOR = 1
PRINT FOR

A l’execution, message d’erreur --->‘Duplicated definition, Found ’for’ in ‘dim for’
Expected identifier, found ‘=’ in ‘for = 1’
Expected End-of-line, found ‘for’ in ‘ print for’

Play Basic

Code:

Dim for
For = 1
Print for

A l’execution, message d’erreur ---> ‘Error string: the Variable/Array Name is already reserved Command Name’

TPW et Virtual Pscal

Code:

Var for : integer;
Begin
     For := 1;
   Writeln(for);
End.

A la compilation ---> message d’erreur ‘ Error 2 : Identifier expected’

YABASIC

Code:

For = 1

Ça ne vous permet même pas de continuer votre code et (au niveau de l’éditeur) message d’erreur ---> ‘ Error in standard input,line1 : Parse error at " ="

ABASIC

Code:

DEFNUM FOR
LET FOR = 1
WIN 0 0 400 400 WS_CAPTION “ESSAI”
PRINT 100 100 FOR

Alors là : EXECUTION SANS PROBLEME.

BASIC256

Code:

FOR = 1
PRINT FOR

A l’exécution, message d’erreur ---> ‘ syntax error on line 1 around column 4’


Après tous ces tests, je constate que la plupart des langages (au moins ceux ci-haut testés) n’autorisent pas l’utilisation des mots réservés comme noms de variables.
Est-ce ceci une rigidité ou une souplesse ? C’est à vous de voir.

@Cosmos70
Toi, qui utilise Autoit (moi je ne connais pas ce langage) : est-ce qu’il permet ou non d’utiliser des mots réservés comme noms de variables ?
@Klaus
Tu utilise DELPHI (je crois qu’il a la même syntaxe que Turbo Pascal ? je me trompe peut-être). Quel est le comportement de DELPHI ?


En définitive, je ne cherche pas les embêtements et je n’utilise jamais les mots réservés comme identificateurs.
Mais je constate un phénomène curieux selon moi. Vous avez certainement un autre point de vue différent. Et ça ne peut qu’enrichir la discussion et augmenter le savoir de tous.




JE SOUHAITE SINCEREMENT QUE PANORAMIC SOIT UN LANGAGE PARFAIT QUI NE SOUFFRE D’AUCUNE IMPERFECTION.

Certes papydall, tu as raison dans l'absolu et Panoramic devrait comporter les tests qui empêcheraient (ou au moins signaleraient) les anomalies que tu rapportes.
Mais les choses étant ce qu'elles sont, et la mise en oeuvre de ces tests semblant assez complexe d'après ce que j'ai lu, ce n'est pas trop contraignant pour nous de faire attention à ne pas faire les confusions.
Mais attention, ce n'est que mon seul point de vue à moi et qui n'engage que moi, n'ayant a priori jamais été confronté à ce genre de problème, ou si oui j'ai dû trouver rapidement le remède.

On peut aussi considérer ceci:
Lors de la saisie intentionnelle d'un mot-clé, la coloration syntaxique s'applique, et on voit immédiatement si l'on a fait une faute de frappe ou pas.
De même, lors de la saisie d'un nom de variable, la coloration ne s'applique pas. Et si elle survient, on sait qu'on a saisi un mot-clé réservé, et on peut alors décider si on le garde ou pas.
Je pense que c'est assez clair. De toutes manières, ce problème risque d'être dépassé avec la nouvelle version.

Bug ou non bug ? la réponse est non, vu qu'il s'agit d'un choix...

Pour ce qui concerne la rigueur, c'est aussi celle du programmeur qui est engagée.
Finalement, comme le précise Klaus, la coloration syntaxique a le mérite de nous avertir... donc on peut toujours changer le nom de la variable pour éviter tout problème.

Cela m'est arrivé récemment en voulant créer une variable "date1" qui c'est colorée en bleu ??? Ce mot-clé n'existe pas, mais j'ai , par prudence, abandonnée cette variable. Je n'ai pas jugé bon de faire un topic pour cela car il s'agit peut-être de mots-clé futurs ou abandonnés.

@Papydall, ton message a le mérite de montrer la chose, mais nous n'avons pas à faire un service du style Microsoft (Jack est seul), pour cela je pense qu'il ne faut pas être trop exigeant.

Et comme dit Klaus, attendons la prochaine version et nous verrons.

A+

Citation :

De toutes manières, ce problème risque d'être dépassé avec la nouvelle version.

Tout à fait.

Salut tout le monde.

Le problème, selon mon point de vue, n’est pas la coloration syntaxique.
Par exemple, la fonction modulo qui s’écrit mod(a,b) et qui retourne le reste de la division entière de a par b, ne possède pas encore la coloration (parce qu’elle a été ajouté ultérieurement.
Supposons que je ne sais pas qu’il s’agit d’un mot réservé. Je peux donc utiliser une variable vecteur mod(10).
Panoramic ne me signale pas qu’il s’agit d’un mot réservé. J’écris donc mon programme (beaucoup plus important que ce code)

Code:

dim mod(10)
mod(3)= 20
print mod(3)

J’exécute mon programme tout content de moi et ….. oups ! un message d’erreur ‘(29) Not correct arithmetic expression. Line : 3’
J’en conclus que la 1ere ligne est correcte : j’ai déclaré une variable et il n’y a pas de problème !
La seconde ligne est également correcte : j’ai affecté une valeur à ma variable et tout est bien qui finit bien
Je me demande donc, le plus candidement du monde, pourquoi cette 3ème ligne est-elle incorrecte ? Et là, je n’arrive pas à expliquer la chose (n’oubliez pas que je suis supposé ne pas savoir qu’il s’agit d’un mot réservé).
Je peux donc passer des heures, des jours ou même des mois à déboguer mon programme (qui est sensé être beaucoup plus important) sans y parvenir.
Je laisse tomber ce programme. Je peux, même me désintéresser du langage et de la programmation tout court.

Ceci est une situation imaginaire, mais pourquoi ne serait-elle pas réelle ?
Morale de l’histoire :
Si le système a refusé dès le début l’utilisation des mots réservés comme identificateurs, en signalant clairement qu’il s’agit d’un mot réservé, on gagnerait beaucoup de temps dans la mise au point des programmes, en productivité, en aisance de programmation etc.…
Et le néophyte que j’ai joué son rôle ne se désintéresse pas de la programmation.

Jean Claude a écrit:

@Papydall, ton message a le mérite de montrer la chose, mais nous n'avons pas à faire un service du style Microsoft (Jack est seul), pour cela je pense qu'il ne faut pas être trop exigeant.

Je ne suis pas trop exigeant. Je sais que Jack est seul et il a un immense mérite de nous avoir fait un si bon cadeau.
J’ai rapporté une constatation qui, d’après moi, doit être signalée. Je n’exige rien et Jack est libre à lui d’en tenir ou ne pas tenir compte.
Mon souhait, (je l’ai déjà dis)
QUE PANORAMIC SOIT UN LANGAGE PARFAIT QUI NE SOUFFRE D’AUCUNE IMPERFECTION.

Les tests que j’ai fais avec les autres langages ont montré qu’ils signalent(en général) une erreur si on tente d’utiliser un mot clé comme identificateur.
Je ne compare pas PANORAMIC avec ces langages. A chaque langage sa philosophie et son domaine d’action.
Mais la découverte de ce non-problème m’a fait réagir. J’ai donné mon point de vue, c’est tout.

Dernière suggestion.
Il est sans doute compliqué de trouver une ‘solution’ à ce ’non-problème’ et Jack investit son temps à des choses beaucoup plus importantes.
Mais je pense (et je peux me tromper) qu’une modification au niveau des messages d’erreurs est chose relativement simple : modifier le message d’erreur ci-haut décrit ‘(29) Not correct arithmetic expression. Line : 3’ par un message plus explicite. Par exemple ‘This function requires two arguments. Line : 3’ ou quelque chose d’approchant.
Alors, ce simple message d’erreur explicite apporte à lui seul une immense aide.

A bon entendeur, Salut.

Salut jack.

J’ai vu ton message après avoir posté le mien.
Tu me rassure, donc.
Sincèrement merci de tout mon cœur.