Que pensez vous du goto

Je ne vais pas dire que je suis un pro mais dans tous les programmes que j'ai eu à faire(dans ma carrière professionel autant que pour le loisir) je n'ai jamais ressentie un besoin de gotos alors après je ne sais pas je n'ai pas experimenter toutes les utilisations du C mais..... Les gotos ne m'on jamais servis après peut être certains cas exigent des gotos bien que je sois daccord sur le fait qu'a mon avis il éxiste toujours une alternative aux gotos, maius cette alternative est peut être moins atrayantes et moins simple que d'utiliser des gotos et qu'ainsi certains programmeurs se laissent tenter quitte à rendre leurs programmes ilisibles.

C'est un choix que chaque programmeur et libre de prendre.

J'ai fait le choix du non-gotoïsme mais certaines personnes on peut être choisis l'autre "voix".

je n'épiloguerais pas puisque déjà dscuté à maintes reprises, et encore une fois Emmanuel a bien résumé la situation.

Je rajouterais juste que pour de vraies applications embarquées de grande taille (je pense à la station spatiale ou aux navettes spatiales) la NASA est très claire dessus. Ils ont un document de "Guide de programmation dans tous les langages", et non seulement ils stipulent qu'une fonction ne doit pas contenir plus d'un if, d'un while, etc.. (une seule instruction à branchement), mais qu'en plus le goto est prohibé.

Je pourrais vous retrouver la réfrence si ça vous intéresse, mais les arguments cités plus hauts dans le thread devrait suffire à convaincre...

Exceptionnellement utilisable. Très fortement déconseillé..

C'est compréhensible mais tout le monde ne programme pas des appli embarquées pour la NASA mais il est vrai que dans le milieu professionel(en général) les gotos et les insrtuctions a branchements DEVRAIT être utilisé le moins possible.

je répète, pour terminer (la norme de la NASA est à mon avis bien trop stricte), mais comme déjà dit X fois, les programmeurs expérimentés ont cette devise en ce qui concerne le goto :

Exceptionnellement utilisable. Très fortement déconseillé..

Point final.

On ne va pas discuter 107 ans... tous les arguments ont déjà été évoqués..

Ah, souviron, cela m'intéresse grandement... si je suis le seul à y trouver un quelconque intéret, cela peut se faire par MP ;)

Citation:

---

Envoyé par souviron34

[...] Je pourrais vous retrouver la réfrence si ça vous intéresse [...]

---

Oui.

Citation:

---

Envoyé par David.Schris

Oui.

---

C'est ça ?

http://www.spinroot.com/p10/

A part la règle 3, évidemment, ça me va tout à fait. Je fais du 'nasa' sans le savoir ...

C'est pas très éloigné des règles MISRA. Tout ça, ce n'est finalement que du bon sens...

Leurs régles sont tout de même srtricte :cry: mais il est vrai que je fais pas de l'embarqué pour la NASA :P.
Leurs régles sont adaptées a leurs postes et à leurs travail, mais un programmeur même professionel peut garder un peu de libertée dans son code tant qu'il est pas illisible.

OK c'est un document de 80 pages, donc je ne le copierais pas ici (en plus je l'ai sur papier). Ceux qui sont intéressés peuvent m'envoyer un MP, et si j'ai assez de demandes je le scannerais et l'enverrais par MP.

Je ne sais pas (je ne crois pas) si il est disponible sous format électronique quelque part.

La référence est :

Citation:

---

SCI 84001A

SO-08

STUDIES AND ANALYSES
SPACE TELESCOPE SCIENCE INSTITUTE
SOFTWARE PROGRAMMING PRACTICES,
STANDARDS AND CONVENTIONS

Number M-1

10 February 1984

Prepared for NASA
By
S.T.S.I

---

En gros, voici un mini-résumé des principales grandes lignes :

Citation:

---

CONVENTIONS :

Objectives for programming standards and conventions are to :

• ensure reliability and fault tolerance
• maximize readability and understandability of the program
• promote uniformity of software presentation
• simplify maintenance and achieve portability for elements which may reside in multiple environments.
• assure efficiency

The basic techniques available to achieve these objectives are :

• avoidance of unnecessary complexity
• restriction to "safe" structure and language features
• uniformity and consistency of structure and presentation
• neat and clear arrangements of the comments and the code
• inclusion of features necessary for test and monitoring

---

Citation:

---

A structured programming is based on the mathematically proven Structure Theorem which states that any proper program (a program with one entry and one exit) is equivalent to a program that contains as logic structure only :

• sequences of two or more operations
• conditionnal branch to one of two operations ( if y then b else c)
• repetition of an operation while a condition is true (do..while)

A large and complex program may be developed by the appropriate sequencing and nesting of these three basic structures within each other. The logic flow of such a program always proceed from the beginning to the end without arbitrary branching. Where only these simple structures are used in the programming, there are no unconditional branches and statement labels to which to branch.

---

Citation:

---

Module coupling :

The degrees of module coupling are divided into six levels, which are, from worst (least independent) to best (most independent): [adapted from MYERS]

• content coupling (worst)
• common coupling
• external coupling
• control coupling
• stamp coupling
• data coupling (best)

If a module

• changes a statement within another module, or
• refers to or alters local data of another module, or
• branches into another module and the statement branched to is not an entry point, or
• shares content (e.g. is contained within) with another module

then its coupling is CONTENT coupling. Such a module has low independence from other modules, high susceptibility to errors, low usability in other programs, and low extensibility.

---

Citation:

---

Control constructs

Many people wrongly equate the term "structured programming" with "GO TO-less code", or even worse, programs from which GO TO's have been eliminated after the fact. This is probably a result of the wide reference to a famous letter by Edsger Dijkstra to the editor of the CACM entitled "Go To Statement Considered Harmful". In this letter the point is made that the quality (by his definition) of a piece of software is a decreasing function of the number of GO TO's used. In actual fact, Bohm and Jacobini's paper on control constructs published in 1966 is more properly considered the original contribution to the discipline of stuctured programming. The points to be made here are that :

• 1 A well structured program contains few or no GO TO statements
• 2 Condition 1 is a necessary, but not sufficient definition of a well structured program, and
• 3 Structured programming is almost half as old as the field of computer science itself.

The basic approach to well behaved control flow within modules is to use only sequential flow or block constructs (such as do-while, do-until, if-then-else, case). Block structures control constructs have single entry points (to the block) and single exit points (from the block).

---

Appendice sur le langage C :

Citation:

---

EXPRESSION TYPES

• ENCOURAGED The IF....ELSEIF..ENDIF is preferable to the CASE statement when different condition types must be tested. The CASE is preferable when a single variable must be tested for content.
  
• PROHIBITED GOTO should not be used, nor the labels to which they refer.

---

Voilà..

ça résume en gros ce qu'on a dit plus haut..

:mrgreen:

Citation:

---

Envoyé par Shugo78

Leurs régles sont tout de même srtricte :cry:

---

D'un côté si ton PC coute plusieurs millions de dollars et qu'il risque d'exploser à chaque ligne de code, on ferait peux être un peu plus attention au code que l'on écrit :mouarf:

Citation:

---

Envoyé par gege2061

D'un côté si ton PC coute plusieurs millions de dollars et qu'il risque d'exploser à chaque ligne de code, on ferait peux être un peu plus attention au code que l'on écrit :mouarf:

---

:mrgreen: très bon

Citation:

---

• L'exception logiciel interne du SRI s'est produite pendant une conversion de données de représentation flottante à 64 bits en valeur entière 16 bits. Le nombre en représentation flottante qui a été converti avait une valeur qui était supérieure à ce que pouvait exprimer un nombre entier à 16 bits. Il en est résulté une erreur d'opérande. Les instructions de conversion de données (en code Ada) n'étaient pas protégées par le déclenchement d'une erreur d'opérande bien que d'autres conversion de variables comparables présentes à la même place dans le code aient été protégées ;
  
• l'erreur s'est produite dans une partie du logiciel qui n'assure que l'alignement de la plate-forme intertielle à composants liés. Ce module de logiciel calcule des résultats significatifs avant le décollage seulement. Dès que le lanceur décolle, cette fonction n'est plus d'aucune utilité ;

---

Sur qu'on regarde ses cast deux fois plutôt qu'une dans ce cas.

Citation:

---

Envoyé par gege2061

D'un côté si ton PC coute plusieurs millions de dollars et qu'il risque d'exploser à chaque ligne de code, on ferait peux être un peu plus attention au code que l'on écrit :mouarf:

---

oui disons que ça me motiverais pour ne pas le planter tout de suite :mouarf:

Citation:

---

Envoyé par kromartien

Sur qu'on regarde ses cast deux fois plutôt qu'une dans ce cas.

---

Et on fait quoi s'il est physiquement impossible que le cast échoue avec les trajectoires pour lesquelles le système a été écrit? On conlu a une erreur hard et on passe au double. Et on fini par tout faire sauter en l'air (pour éviter l'écrasement sur terre qui risque d'introduire des dégats encore pire) quand le même problème se produit sur le double. Exactement ce qui s'est produit.

Le problème principal d'Ariane V, c'était un problème de non vérification que les hypothèses conscientes ayant présidés à la conception d'un sous-système tiennent toujours quand on réutilise ce sous-système dans un autre contexte. Cette non vérification était consciente -- les tests d'intégration étaient sensés suffire. Puis les tests n'ont pas été fait pour je ne sais plus quelle raison (j'ai envie d'écrire financières mais je ne suis pas sûr, j'ai un souvenir de problèmes pratiques également).

Il n'y avait rien à changer dans la conception du sous-système, il y avait des choses à changer dans sa réutilisation.

Ils font toujours (comprendre : aujourd'hui) de la redondance sur Ariane V ?

Bon nous dérivons fortement, là.. Cette discussion aurait plus à voir sur le forum méthodes...


Mais juste pour répondre sur le côté pratique :

oui les normes "une fonction par module", "50 lignes par fonction", etc.. sont trop strictes.

Il est des cas où il est impossible de faire autrement, et d'autre part je n'ai jamais été convaincu de l'utilité de la première, car en maintenance c'est un casse-tête (14 000 fichiers pour 14000 fonctions ???? :aie: ).

J'ai violé moi-même quelques unes de ces règles (module de 25 000 lignes, fonction de 1000, etc..).

Cependant ces normes strictes sont, comme toutes les normes, à ne pas prendre au pied de la lettre et à adapter à chaque projet, sa taille, sa destination, etc...

Mais, comme toutes les normes, elles fournissent un bon cadre de développement. Et fournissent également, pour le cas où on ne s'y conforme pas, un argumentaire auquel il faut répondre avant de les violer. Ce qui est un point central, car on fait ces choix en conscience... (et non pas sur des "convictions", croyances, cours, etc..)

Et autant les normes sus-dites sur la "manière de découper" peuvent être absurdement strictes (mais pas forcément dans leur cadre : ces systèmes sont développés sur une dizaine d'années, par des programmeurs de dizaines de pays simultanément, et ont une durée de vie prévue de l'ordre de la 40 aine d'années, avec donc des contraintes de débuggage ou améliorations par quelqu'un dans 40 ans..) , autant sur les conseils et les diagnostics de certains comportements de programmation (voir ci-dessus pour les goto) elles sont utiles, car le nombre de gens expérimentés ayant particpé à leur élaboration, ainsi que justement leur cadre d'application sensible, en font un domaine de test privilégié.... et donc de conclusions privilégiées et étayées.

D'où les remarques sur les goto (je rappelle : prohibé en C .. ;) )..

Citation:

---

Envoyé par Jean-Marc.Bourguet

Et on fait quoi s'il est physiquement impossible que le cast échoue avec les trajectoires pour lesquelles le système a été écrit? On conlu a une erreur hard et on passe au double.

---

Ce que vous dites est stupide. Comment envisager de faire décoller une fusée qui contiendrait des microprocesseurs physiquement défectueux ?

C'est certainement à cause d'erreurs de jugement aussi grossières que ce genre de catastrophe se produit, ça je suis d'accord.

Je me demande à quel point ces normes à la con sont un gage de maintenabilité... on peut, théoriquement, toujours s'en sortir avec ces méthodes, mais là où les choses se corcent, c'est lorsqu'un algorithme naturellement et lisiblement implantable en violant ces règles doit impérativement être remanié pour tenir dans les "canons de la bonne programmation".

De la discipline oui, mais de la programmation débile non.

C'est comme tout : il faut être raisonnable.

Si certains ici mettaient leur nez dans le noyau Linux...

Citation:

---

Envoyé par kromartien

Ce que vous dites est stupide. Comment envisager de faire décoller une fusée qui contiendrait des calculateurs physiquement défectueux ?

---

Non, non, non : c'est ce qui s'est réellement passé avec Ariane 501... le calculateur a déduit à un moment une erreur de hard, à cause d'un buffer overflow je crois, et a fait exploser le merdier.

D'un autre côté, ça les apprendra à foutre les plans de vol d'Ariane IV sur Ariane V (pas la même bestiole, hein !).

Citation:

---

Envoyé par InOCamlWeTrust

Je me demande à quel point ces normes à la con sont un gage de maintenabilité... on peut, théoriquement, toujours s'en sortir avec ces méthodes, mais là où les choses se corcent, c'est lorsqu'un algorithme naturellement et lisiblement implantable en violant ces règles doit impérativement être remanié pour tenir dans les "canons de la bonne programmation".

De la discipline oui, mais de la programmation débile non.

C'est comme tout : il faut être raisonnable.

Si certains ici mettaient leur nez dans le noyau Linux...

---

Oui, les normes de programmation à mon avis sont une façon de assurer la lisibilité du code et sont volontairement strictes parce que ce n'est pas trois barbus dans leur coin qui programment, mais bien une méthode de développement assurée par le respect de ce genre de normes.

Après, l'essentiel pour moi est que la lecture cursive permette de comprendre le code.

Pour le noyau Linux, non, je n'ai jamais essayé, mais c'est un sujet à part, il faut des connaissances sur l'agencement des modules, les communications propres au noyau pour s'y retrouver je pense.

Je crois bien que ce n'était pas une erreur hard, mais bien une erreur soft. C'est pourquoi les deux calculateurs (redondances) ont lancé simultanément une exception.

Si j'ai bien compris le texte dont un lien avait été posté il y a un moment, les calculateurs ont sorti les données de l'exception, que le module suivant a pris pour les paramètres de vol qu'il attendait. D'où changement brusque de trajectoire, déchirement de l'appareil, détection du déchirement et auto-destruction.