Discussion :

[PRomu@ld]

J'ai l'impression que vous refusez d'utiliser la syntaxe d'un langage connu

Absolument d'accord.

En revanche, la distinction français anglais me semble intéressante car elle limite l'effort cognitif, exprimer un algorithme dans sa langue maternelle peut-être un plus pour les débutants en algo (pour les autres je n'en suis pas aussi convaincu).

Par contre, pour les boucles pour, je rajouterai un mot clé :

POUR a=0 à 10 FAIRE
ce qui doit etre fait
FIN POUR

Ca permet une meilleur distinction entre les paramètres de la boucle et son corps.

[koala01]

Par contre, pour les boucles pour, je rajouterai un mot clé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
POUR a=0 à 10 FAIRE
ce qui doit etre fait
FIN POUR

Ca permet une meilleur distinction entre les paramètres de la boucle et son corps.

Le terme "mot clé" est fort mal choisi à mon gout...

Un mot clé ne devient mot clé que parce qu'il prend une signification particulière dans une situation et pour un langage particulier... Et comme un algorithme est, généralement, indépendant de tout langage de programmation

De plus, je suis d'avis qu'il est déjà suffisemment compliqué pour certains algorithmes de réfléchir à la logique à présenter sans, en plus, "engluer" la personne qui doit le faire dans des considérations trop rigides de la manière de représenter les choses

Je n'ai rien contre l'utilisation du verbe FAIRE, si tant est qu'elle (l'utilisation) apporte un avantage, ne serait-ce que dans la lecture:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
FAIRE
    ce qui doit etre fait
JUSQUE  test

ne me dérange absolument pas, mais la présence du verbe FAIRE n'ajoute aucune information dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
TANT QUE test  (FAIRE)
    ce qui doit etre fait
FIN TANT QUE

ou dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
POUR i= 1 a 10 (FAIRE)
    ce qui doit etre fait
FIN POUR

Sinon, on en vient rapidement à vouloir l'imposer dans toutes les strucures de controle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
SI test FAIRE
    ce qui doit etre fait
SINON FAIRE
    ce qui doit etre fait
FIN SI
SELON variable
    CAS valeur1 FAIRE
       ce qui doit etre fait
    FIN CAS
    CAS valeur2 FAIRE
        ce qui doit etre fait
    FIN CAS
FIN SELON
POUR chaque element dans tableau FAIRE
    ce qui doit etre fait
FIN POUR

ce qui aura pour conséquence directe de rendre l'écriture de l'algorithme beaucoup plus lourde à effectuer, sans apporter de réelle précision

[PRomu@ld]

Le terme "mot clé" est fort mal choisi à mon gout...

Un mot clé ne devient mot clé que parce qu'il prend une signification particulière dans une situation et pour un langage particulier... Et comme un algorithme est, généralement, indépendant de tout langage de programmation

N'aurais-tu pas un esprit de contradiction ?

Ici, il s'agit d'un mot clé dans la mesure où il fait parti de la structure de la boucle. J'aurai pu appeler ça mot réservé, le principe aurait été le même.

ce qui aura pour conséquence directe de rendre l'écriture de l'algorithme beaucoup plus lourde à effectuer, sans apporter de réelle précision

Elle structure l'écriture, marque une distinction nette entre définition de ta boucle et corps de la boucle.

C'est à mon avis presque aussi important que le FIN SI (ou FIN CAS). Pour tous les exemples que tu donnes, la structure de ta boucle est simple et loge sur une seule ligne, par conséquent, l'indentation (ici le retour à la ligne) te permet de distinguer les différentes composantes de ta boucle. Il arrive (bien souvent) que les conditions d'une boucle puissent occuper plusieurs lignes, dans ce cas je préfère ajouter FAIRE, ça permet d'avoir une distinction plus claire.

[koala01]

Autant je trouve cohérent d'utiliser les termes de la langue (considérée comme) maternelle de la personne qui va créer ou lire l'algorithme de préférence à tout autre, autant je ne vois pas réellement la valeur ajoutée par l'obligation d'ajouter un verbe qui, de toutes manières, n'apporte aucune précision...

D'autant plus que, parmis les langages que je connais - ancien basic, C, C++, VB et COBOL - il n'y a en définitive qu'en COBOL qu'il y ai un therme se rapprochant du FAIRE dans les boucles (sous la forme de PERFORM until test [with test after], PERFORM n times ou autres)

Meme si la boucle est importante, il est clair que l' (le groupe d') action(s) doit etre exécuté/effectué/fait et non "pisssé"

Maintenant, on peut tres bien en appeler à l'arbitrage des autres, je me plierai volontiers à la préférence générale, mais au moins, j'aurai donné mon avis

[PRomu@ld]

Autant je trouve cohérent d'utiliser les termes de la langue (considérée comme) maternelle de la personne qui va créer ou lire l'algorithme de préférence à tout autre, autant je ne vois pas réellement la valeur ajoutée par l'obligation d'ajouter un verbe qui, de toutes manières, n'apporte aucune précision...

Ca n'est pas une question de précision, c'est une question de séparation et de structuration de ton algorithme.

D'autant plus que, parmis les langages que je connais - ancien basic, C, C++, VB et COBOL - il n'y a en définitive qu'en COBOL qu'il y ai un therme se rapprochant du FAIRE dans les boucles (sous la forme de PERFORM until test [with test after], PERFORM n times ou autres)

Le terme n'est pas important, là n'est pas la question.

En C/C++/java/..., les paramètres d'une boucle for sont entourés d'une parenthèse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
for ( ... ; ... ; ... )

En ada, on utilise le terme loop, la majeure partie des langages de programmation reflètent ce découpage, ceci a une explication syntaxique car elle enlève les ambiguïtés.

Même s'il ne faut pas absolument vouloir coller aux langages de programmation, je reste convaincu que l'ajout d'un mot clé ( appelle ça comme tu le veux, le terme n'est pas important ) permet de limiter les ambiguïtés (exactement comme je l'ai dis dans une de mes précédentes interventions, comme le FIN SI)

[koala01]

Je suis désolé, mais je ne vois vraiment pas en quoi le fait d'écrire le mot FAIRE apporte quoi que ce soit au niveau de la structuration de l'algorithme qui ne serait pas apporté si on ne le mettait pas...

Le FIN SI, FIN POUR et autres permet de repérer plus facilement le groupe d'instruction à effectuer, mais le fait d'imposer la présence du mot FAIRE n'apporte rien de plus que ce qui est déjà écrit... Des lors, pourqoi le faire

EDIT De plus, si l'algorithme est correctement indenté, on pourrait presque se passer des FIN SI et similaire... Mais je suis d'avis qu'il vaut mieux les expliciter quand meme

[pseudocode]

En revanche, la distinction français anglais me semble intéressante car elle limite l'effort cognitif, exprimer un algorithme dans sa langue maternelle peut-être un plus pour les débutants en algo (pour les autres je n'en suis pas aussi convaincu).

??!!

Si les algo sont independants des langages de programmation, ils le sont également des langues parlées/écrites. Ou sinon il va falloir definir une "langue parlée/écrite commune" pour eviter les incomprehension... bref, une deuxieme difficulté pour la lecture/ecriture d'un algo.

Et puisque tu parles de "limiter l'effort cognitif", il est plus simple pour moi de lire un algo dans un langage de programmation que je connais, plutot que d'essayer de comprendre le "langage franco-programo-algoritmique" de chaque personne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
POUR CHAQUE element a DANS la liste [A] FAIRE
       AJOUTER f(a) a la fin de [A]
FIN POUR

est-ce une boucle infinie ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a -> suivant <- b -> precedent

est-ce plus simple que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a.next =  b.previous;

[koala01]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a -> suivant <- b -> precedent

est-ce plus simple que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a.next =  b.previous;

L'utilisation du point "."ou de la fleche droite "->" pour indiquer que l'on accede à un élément de structure, ainsi que je l'ai dit, m'indifère tout à fait...

Ce qui se passe, c'est qu'il faut, ainsi qu'il en a déjà été question plus haut, d'arriver à représenter l'assignation (a.next recoit la valeur de b.previous) différemment du test d'égalité (a.next est il égal à b.previous)

Pour donner des exemple dans les langages de programmation, vu que, malgré tout, un algorithme finira en une série d'instructions dans un langage particulier, en C et en C++, tu as une différence bien claire:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
a->next = b->previous; //affectation
a->next == b->previous;//test: renvoye un résultat booléen selon les valeurs
if(a->next=b->previous)//provoquera au minimum un avertissement:
                       //"attention affectation possible"

C'est, l'un des griefs que l'on peut faire au VB, par exemple, pour qui le signe "=" peut, selon le contexte, servir d'affectation et de test d'égalité, et dont la lisibilité peut rapidement devenir incertaine

Code VB :

Sélectionner tout - Visualiser dans une fenêtre à part

if( (a=b+c)=10)

signifiant "teste si a qui recoit la somme de b + c vaut 10"

[PRomu@ld]

Si les algo sont independants des langages de programmation, ils le sont également des langues parlées/écrites. Ou sinon il va falloir definir une "langue parlée/écrite commune" pour eviter les incomprehension... bref, une deuxieme difficulté pour la lecture/ecriture d'un algo.

Ecoute, moi je veux bien, mais si tu me donnes un algo écrit en allemand, je ne suis pas sur de pouvoir le comprendre. Nous sommes ici dans un forum français, par conséquent la majorité des personnes ici parlent et comprennent le français couramment, leur imposer une notation anglaise me déplaît un peu, mais bon, si je suis le seul dans ce cas, c'est pas grave . Si la source est dans une autre langue, je suis tout à fait d'accord et ça ne me pose pas de problème, mais si l'algo est fait par un francophone pour l'expliquer à un francophone, je ne vois pas pourquoi on passerait par une autre langue.

Et puisque tu parles de "limiter l'effort cognitif", il est plus simple pour moi de lire un algo dans un langage de programmation que je connais, plutot que d'essayer de comprendre le "langage franco-programo-algoritmique" de chaque personne:

Code :
POUR CHAQUE element a DANS la liste [A] FAIRE
AJOUTER f(a) a la fin de [A]
FIN POUR
est-ce une boucle infinie ?

L'écrire dans un langage de programmation ne devrait pas te servir beaucoup plus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
for( int i = 0 ; i < list.size() ; ++i )
{
     list.push_back( f(a) );
}

Pour moi c'est pareil, la notation ne me semble pas en cause.

En revanche, pour l'utilisation du point à la place de la flèche, je suis tout à fait d'accord. Encore que quelques fois, on utilise des fonction pour ceci.

Par exemple pour un arbre binaire, au lieu de faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
i = tree.fils_gauche;

on peut faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
i = FILS_GAUCHE( tree );

Ca permet de s'abstraire de la structure interne de la structure de donnée.

[PRomu@ld]

Ce qui se passe, c'est qu'il faut, ainsi qu'il en a déjà été question plus haut, d'arriver à représenter l'assignation (a.next recoit la valeur de b.previous) différemment du test d'égalité (a.next est il égal à b.previous)

Oui, il faut absolument résoudre ces problèmes d'ambiguité et donc utiliser deux symboles.

Par contre, pour ce qui est du nom d'affectation, il faudra prendre garde au contexte, dans un contexte de programmation fonctionnelle, on utilisera plutôt le terme de liaison, dans un contexte de programmation logique on utilisera le terme d'unification, ça n'a pas toujours la même signification. Mais en général, le contexte permet de résoudre ces problèmes.

[PRomu@ld]

Je suis désolé, mais je ne vois vraiment pas en quoi le fait d'écrire le mot FAIRE apporte quoi que ce soit au niveau de la structuration de l'algorithme qui ne serait pas apporté si on ne le mettait pas...

Visiblement tu n'as pas saisi ce que je disais (mais je me peut-être mal exprimé).

Imagine que tu as choisi une notation et que tu veux expliquer cette notation à quelqu'un, vient le moment d'expliquer la boucle for. Comment fait tu pour distinguer la fin de la définition de ta boucle du corps de cette boucle ? Tu as plusieurs solutions, soit tu raisonnes comme je le fait : dès que tu rencontre le mot FAIRE, tu as fini des définitions de ta boucle et vient ensuite le corps de la boucle. Dans les autres cas, comme tu le fais, ça se passe avec la fin de ligne, ceci oblige donc à avoir tout sur une même ligne. Il peut arriver des fois où le nombre d'opérations à faire après chaque itération de la boucle peut-être important et donc passer par une sépartion avec la fin de ligne impose une ligne très longue.

[koala01]

Ah, je crois entre appercevoir ce que tu veux dire...

Ce serait dans le cas où le test à effectuer lui meme serait imposant

Un peu comme dans une boucle dont la condition de sortie serait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
TANT QUE pas fin de fichier ET continent <> ctemp ET pays <> ptemp ET
         ville <> vtemp ET succursalle <> stemp ET vendeur <> vtemp ET
         jour <> jtemp FAIRE
    ce qui doit etre fait
 
 
 
FIN TANT

Dans ce cas, j'admet que le fait de rajouter FAIRE permet d'expliciter la fin de l'instruction, et je suis d'accord avec le fait que ce peut etre utile, pour ne pas dire nécessaire...
[EDIT] boucle que j'ai une fois du utiliser avec 7 niveaux d'imbrications, dans le cadre de gestion de ruptures
[/EDIT]
De là à le généraliser pour tout, y compris pour un simple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
POUR i=0 à 100 par pas de 2
 
FIN POUR

je trouve qu'il y a quand meme de la marge

[pseudocode]

Nous sommes ici dans un forum français, par conséquent la majorité des personnes ici parlent et comprennent le français couramment, leur imposer une notation anglaise me déplaît un peu, mais bon, si je suis le seul dans ce cas, c'est pas grave .

L'algorithme écrit en pseudocode () n'est generalement (jamais?) pas suffisant pour la comprehension. Il y a souvent (toujours?) un texte explicatif pour permettre de comprendre le procédé utilisé.

Vous pouvez regarder longtemps l'algorithme "ecrit en francais" du pivot de gauss, ce n'est pas pour cela que vous pigerez la technique d'elimination.

Donc, partant du principe qu'un pseudocode est accompagné d'une notice explicative, le "langage" du pseudocode n'a pas besoin d'etre rédigé dans la langue du lecteur. Seule la "notice explicative" a besoin d'etre traduite. Et c'est generalement ce qui se passe. Si un programmateur chinois invente un nouvel algo, il fera une publication en chinois avec du pseudocode C++/Basic. Ce papier sera a son tour traduit en anglais, en reprenant le meme pseudocode, et ainsi de suite...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
for( int i = 0 ; i < list.size() ; ++i )
{
     list.push_back( f(a) );
}

Pour moi c'est pareil, la notation ne me semble pas en cause.

Non, ce n'est pas pareil. Car dans ce langage (C) l'ambiguité est levée. La clause de sortie de la boucle for est évaluée a chaque début de boucle.

C'est, l'un des griefs que l'on peut faire au VB, par exemple, pour qui le signe "=" peut, selon le contexte, servir d'affectation et de test d'égalité, et dont la lisibilité peut rapidement devenir incertaine
Code VB :
if( (a=b+c)=10)
signifiant "teste si a qui recoit la somme de b + c vaut 10"

Comme tu le dis toi meme, il n'y a pas d'ambiguité. En Vb le signe "=" est un operateur contextuel. Dans ce cas c'est "teste si a qui recoit la somme de b + c vaut 10".

Tout l'avantage d'utiliser un langage connu et completement défini permet de lever toutes les ambiguités de ce type.

Après on peut discuter des avantages/inconvenients d'un langage par rapport a un autre, mais c'est un autre sujet. Il n' y a pas plus d'ambiguité en Vb qu''en C ou en Java (un chance pour le compilateur )

[koala01]

D'un autre coté, le problème se pose sytématiquement dés qu'une instruction est susceptible de devoir etre écrite sur plusieurs lignes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
/* quelle qu'en soit la raison on arrive au 10eme niveau d'imbrication */
                                        a <- b.truc.lafonction_qui_fait_machin.bidule.
                                            basard

Mais là, il serait *peut etre* intéressant de justement fournir un signe indiquant que

attention, cela continue à la ligne suivante

ou que

attention, c'est la continuité de la ligne suivante

[koala01]

L'algorithme écrit en pseudocode () n'est generalement (jamais?) pas suffisant pour la comprehension. Il y a souvent (toujours?) un texte explicatif pour permettre de comprendre le procédé utilisé.

Vous pouvez regarder longtemps l'algorithme "ecrit en francais" du pivot de gauss, ce n'est pas pour cela que vous pigerez la technique d'elimination.

Donc, partant du principe qu'un pseudocode est accompagné d'une notice explicative, le "langage" du pseudocode n'a pas besoin d'etre rédigé dans la langue du lecteur. Seule la "notice explicative" a besoin d'etre traduite. Et c'est generalement ce qui se passe. Si un programmateur chinois invente un nouvel algo, il fera une publication en chinois avec du pseudocode C++/Basic. Ce papier sera a son tour traduit en anglais, en reprenant le meme pseudocode, et ainsi de suite...

Ah, non, le pseudo code est indépendant de tout langage de programmation, sinon, c'est du code, et non plus du pseudo code...

Après on peut discuter des avantages/inconvenients d'un langage par rapport a un autre, mais c'est un autre sujet. Il n' y a pas plus d'ambiguité en Vb qu''en C ou en Java (un chance pour le compilateur )

Il n'y a peut etre pas d'ambiguité pour le compilateur, et un lecteur d'algorithme un tant soit peu aguerri (et pas trop distrait) sera en mesure de lever l'ambiguité mais...

Pour quelqu'un n'ayant pas une grande expérience algorithmique - ne serait-ce parce qu'il débute - l'ambiguité est potentielle...

Et on en revient au problème: l'algorithme doit etre compréhenible par tous, il faut donc lever toute ambiguité sur ce que l'on veut représenter...

[PRomu@ld]

Un peu comme dans une boucle dont la condition de sortie serait ...

C'est exactement ça.

De là à le généraliser pour tout, y compris pour un simple

C'est pour maintenir une cohérence de la notation. Même si je conçoit de temps en temps que l'on ait envie de simplifier les choses.

Comme tu le dis toi meme, il n'y a pas d'ambiguité. En Vb le signe "=" est un operateur contextuel. Dans ce cas c'est "teste si a qui recoit la somme de b + c vaut 10".

L'analyse tu code est beaucoup plus compliquée puisqu'elle nécéssite de connaître le contexte. Minimiser les ambiguïtés en ayant deux symboles différents peut-être un plus.

[koala01]

Il ne faut pas oublier que la difficulté majeure, au sein d'une équipe, a toujours été, et sera toujours la communication: entre les non dits (car jugés "allant de soi") et les interprétations, cela peut mener à de véritables drames...

Peut etre as tu joué, dans ta jeunesse au jeu du "téléphone sans fil"

Peut etre te souviens tu de l'hilarité générale lorsque tu comparais le message original au message final

Lorsque l'on travaille en équipe, il faut s'assurer que la communication passera en évitant toute interprétation ou modification par mécompréhension d'un bout à l'autre de la chaine...

Ayant été ambulancier pendant des années, je peux t'assurer que l'interprétation (souvent erronée) que l'on peut faire d'une information mal transmise peut mener à de véritables drames...

Dans un forum, tu ne peux préjuger de l'expérience de la personne qui te lira.

Tu dois donc veiller à ce que, tant tes explications que la logique que tu tentes de transmettre soient suffisemment claires et précises pour éviter à tous - et principalement aux moins habitués - la tentation d'interpréter tes écrits.

[millie]

L'analyse tu code est beaucoup plus compliquée puisqu'elle nécéssite de connaître le contexte. Minimiser les ambiguïtés en ayant deux symboles différents peut-être un plus.

Il arrive souvent dans les entreprises qu'il y ait quelques normes à suivre, on devrait faire deux même sur les deux cas suivant :

- Interdiction de mettre une affectation dans un test
- Interdiction de mettre deux affectations dans une seule ligne

Avec une notation C, le code suivant serait interdit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
if(c=a) 
  ....
 
 
int c = 3;
int a;
int b;
 
a = b =c;

Ce retirait naturellement beaucoup d'ambiguité.

[PRomu@ld]

Le problème est à mon avis, que la notation (ou la norme du langage) te le permet, si tu distingue par deux symboles différents l'affectation du test d'égalité tu lève cette ambiguïté.

[pseudocode]

Ah, non, le pseudo code est indépendant de tout langage de programmation, sinon, c'est du code, et non plus du pseudo code...

Mince alors.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
POUR i=0 à 100 par pas de 2
xxxx
FIN POUR

Si je crée un compilateur capable de compiler ce pseudo code, alors ca devient "magiquement" du code. Et donc tu te sentirais obligé de créer un nouveau pseudo langage, pour décrire ton algorithme ?

Je voudrais pas remettre en cause ton genie, mais je pense que pour définir la boucle itérative "POUR ... FIN POUR" tu t'es tres largement inspiré du langage basic (en le "francisant"). Donc visiblement ca te pose pas de probleme de creer un pseudolangage a partir d'un langage existant.

Par contre utiliser directement le langage (ou un subset) ca pose probleme ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
10 Rem ceci est du pseudocode façon basic TO7/70
20 for i = 0 to 100 step 2
30  xxxx
40 next i

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
// ceci est du pseudocode façon java
for(i=0: i<=100; i+=2) {
  xxxx
}

Et on en revient au problème: l'algorithme doit etre compréhenible par tous

Ah bon ? C'est ecrit où cette regle ???

Alors si je comprend pas un algo, c'est de la faute de l'auteur ?
Et si quelqu'un comprend pas un de mes algos, c'est de ma faute ?

Franchement, inventer un énieme langage (non compilable, faudrait pas que ca devienne du code !) pour expliquer un procédé destiné a être implémenté dans un autre langage (compilable cette fois), c'est une perte de temps.

Autant prendre un langage polyvalent existant, retirer toutes les "spécificités" du langage (afin de faciliter l'implémentation dans un langage légerement different) et ecrire l'algo dans ce sous-langage.

Evidemment, cela implique que l'algo ne sera pas décrit de maniere "universelle" et qu'il sera lié au type de langage utilisé. Mais de toutes facons, je ne pense pas qu'un algo decrit en "vb-like" soit facilement implementable en "matlab", et inversement.