Sommaire: Programmation FORTRAN
1Introduction
2Règles retenues
2.1 Présentation
2.2 Norme ANSI
2.3 Exceptions à la norme
2.4 Éléments lexicaux
2.5 Objets du langage
2.6 Initialisation – assignation
2.7 Structures de contrôle
2.8 Unités de programme
2.9 Entrées – sorties
2.10 Problèmes d’inter-compilation
3 Quelques explications
3.1 Alphabet
3.2 Déclaration des types flottants
3.3 Fonctions intrinsèques
3.4 COMMON
3.5 Entrées – Sorties
Bibliographie
Extrait du cours programmation FORTRAN
Introduction
Le but de ce document est de présenter l’ensemble des règles retenues par l’équipe de Développement d’Aster (EDA) pour l’écriture des routines FORTRAN du code.
Le respect de ces règles a deux objectifs :
• assurer une bonne portabilité du code,
• assurer une bonne lisibilité (et donc maintenabilité) des sources.
Il est évident qu’il ne suffit pas de respecter ces règles pour atteindre le deuxième objectif. Celui-ci nécessite également des règles de présentation [D9.03.01] et surtout des efforts de la part de chaque programmeur pour se faire comprendre.
Remarques :
Il est tout aussi clair que ces règles ne concernent que les aspects du langage utilisé et que d’autres règles doivent être appliquées concernant la programmation (émission des messages d’erreur, utilisation de JEVEUX , usage des structures de données, etc.) ou le développement (présentation, documentation, validation, etc.). Ces règles sont présentées dans le Manuel de Descriptif Informatique et le Manuel d’administration.
Notons tout de suite le caractère impératif de ces règles. Il ne s’agit pas de conseils vertueux. Chaque règle est écrite de façon à ce que l’on puisse dire sans ambiguïté si elle est respectée ou non : il n’y a rien de qualitatif. Les développeurs du code Aster doivent les respecter. Nous verrons que la première règle énoncée (la plus importante) est le respect de la norme ANSI. L’outil de compilation actuel d’Aster (ifort) permet de vérifier facilement son application. D’autres règles sont vérifiées par l’AGLA [D2.01.02] nous indiquerons systématiquement entre parenthèses le code-retour émis lorsqu’il est non nul (2 ou 4). Le code retour (2) permet à l’administrateur des sources d’Aster (ASA) de contrôler les exceptions aux règles. Le code retour (4) interdit la restitution des sources . Pour les règles dont la vérification automatique est moins facile, la “sanction” se fera a posteriori : la procédure d’évolution des sources permet en effet de retrouver facilement l’identité d’un éventuel développeur négligent.
Le livre qui nous a servi de base pour ce document est le livre “FORTRAN77 Guide pour l’écriture de programmes portables” [1] réalisé sous la direction de F. FICHEUX-VAPNE. Nous en avons conservé le plan : éléments lexicaux, …, entrées-sorties. Nous avons retenu :
• 18 conseils de portabilité,
• 22 conseils méthodologiques.
Le respect de la norme, que nous avons institué en règle n° 1 remplace 33 conseils du livre.
Les conseils du livre ont été érigés en règles, parfois en modifiant leur énoncé : “utiliser … avec prudence” → “ne pas utiliser …”.
A ces règles, nous avons ajouté quelques règles qui nous sont propres et qui résultent de l’expérience acquise par l’équipe de Développement pendant les cinq premières années du Projet.
Dans ce document, nous avons essayé d’expliquer (au moins partiellement) les raisons du choix de ces règles. Ceci n’est pas toujours facile à faire. Pour cela, nous renvoyons à [1] pour les règles provenant de ce livre, et nous faisons des renvois à certains paragraphes d’explication pour les règles qui nous sont propres.
Terminons cette introduction en disant que, contrairement à une idée répandue, FORTRAN n’est pas un langage “évident”. Certains éléments du langage sont des “survivances” d’anciennes versions du langage. Ces éléments ne sont souvent plus compris des “jeunes” programmeurs. Le lecteur curieux pourra lire avec profit le livre “Fortran 77” de H. KATZAN [3] pour bien comprendre ce qu’est le FORTRAN77 de la norme ANSI.
……..
