Fork me on GitHub

Forme de LMDZ, style de programmation

Ci-dessous un tableau des modifications de forme ou de style de programmation envisagées pour LMDZ. (Nous avons considéré hors sujet le problème de la méthode de compilation et le problème de la documentation extérieure au programme.) À certaines de ces modifications sont accolées une ou plusieurs des lettres A, D, C, T. La signification de ces lettres est la suivante :

A
Le changement peut être fait automatiquement avec un logiciel comme NAGWare f95 Tools (que nous avons sur certaines machines au LMD).
D
Le changement affecte une grande partie des lignes du programme. La comparaison entre des versions avant et après le changement avec des utilitaires comme diff devient très difficile.
C
Modification relativement complexe. Demande une analyse au cas par cas. Ou bien demande une vision globale du fonctionnement du programme.
T
Modification à faire sur tout le programme. Supporte mal d'être fait sur une partie des fichiers seulement.

Le tilde indique une qualification mitigée.

Nous souhaitons encore comparer avec les conventions adoptées pour OPA et celles du CNES.

Nous proposons de commencer par les modifications marquées « D », de les appliquer sur tout le programme, dès que nous aurons précisé ces modifications.

Vous pouvez cliquer sur certaines modifications proposées pour voir un exemple ou une argumentation.

Forme

A D Passage au format libre
A D Choix de casse ? Faut-il mettre à part les mots-clefs de Fortran ? Les noms de procédures ?
A D Choix de règles d'indentation ? (Y compris pour les continuations de lignes.)
A Choix d'une longueur maximale pour une ligne. La norme Fortran 95 limite la longueur à 132 caractères. Faut-il choisir une longueur inférieure ?
A Regroupement des déclarations d'attributs pour un même objet en une seule instruction.
A Utilisation du séparateur :: dans les déclarations ?

Style de programmation

C Utilisation systématique de l'attribut intent.
T~ Choix entre l'anglais et le français pour les commentaires et les noms de variables. (Josefine, Yann et Lionel votent pour l'anglais.) À faire plutôt sur tout le programme pour les noms de variables. Pas forcément sur tout le programme pour les commentaires.
Insertion des procédures dans des modules. Il n'y aurait plus de procédure externe.
C Déclarations des arguments muets tableaux avec profil transmis. Pas d'arguments pour la taille des tableaux arguments.
C Utilisation de l'interface Fortran 90 de NetCDF.
C T Refonte de l'architecture. Choix des variables de modules. Regroupement sémantique des variables de module et des procédures.
C Utilisation de tableaux entiers ou de sections de tableaux dans les expressions au lieu de boucles sur les éléments ?
A~ ? C~ ? Suppression des instructions pour le préprocesseur et suppression des instructions include de Fortran. Relativement complexe si le préprocesseur est utilisé pour choisir entre des configurations avec ou sans parallélisation, INCA, Orchidée etc. Relativement simple si le préprocesseur est utilisé pour régler la quantité de sorties du programme. Remplacement en particulier de la combinaison include – common par un module. C'est une fonctionnalité annoncée par NagWare f95 tools mais il est possible que des cas particuliers ne soient pas traités au mieux automatiquement, et soient à revoir. Cf. le cas de comgeom.h et comgeom2.h : un même bloc, les tableaux sont tantôt déclarés à une dimension, tantôt à deux dimensions.
C Utilisation des instructions forall et where.
Utilisation de noms de variables suffisamment significatifs.
Insertion de commentaires avec les déclarations des variables. Explication du nom lorsque c'est une abréviation. Indication de l'unité.
Insertion de commentaires en tête de procédure. (Autres que les noms des auteurs et les dates de modification. Mais sans tomber dans l'excès inverse : une partie de la documentation doit être extérieure au programme, et la redondance entre documentations interne et externe doit être faible. En particulier, les explications qui nécessitent des schémas ont vocation à se trouver dans la documentation externe. Éviter les schémas par alignement de caractères ASCII.)
A Remplacement des déclarations de sous-type avec * (par exemple real*4) (hors-norme Fortran 77, hors-norme Fortran 90 et 95) par des déclarations avec kind. Ou suppression du sous-type ? Ou utilisation systématique de déclarations comme real(kind=wp), avec une valeur wp spécifiée dans un module.

Exemple de regroupement des déclarations d'attributs (entity-oriented declarations) :

Avant Après 
real x
dimension x(20)
save x

real, dimension (20), save:: x

links

social