……..
1. Introduction
Après avoir, dans cette introduction, justifié une telle partie, situé les enjeux et illustré notre propos de deux exemples, un bon et un mauvais, nous présentons quelques normes de programmation qu’il nous parait judicieux de respecter. L’instruction COPYest ensuite étudiée.
La structure de ce chapitre est la suivante :
1.1 Essai de définition
Selon Ian SOMMERVILLE (auteur d’un ouvrage fameux Le génie logiciel, paru dans sa version française en octobre 1992, aux éditions ADDISON-WESLEY France -ISBN n° 2-87908-033-9), le terme de génie logiciel a été introduit à la fin des années soixante… Le génie logiciel (nous citons toujours SOMMERVILLE) ne concerne pas seulement la réalisation de produits, mais surtout la façon la plus efficiente de les produire. Nous faisons notre cette définition et considérons que le génie logiciel se préoccupe d’industrialisation du processus de fabrication des programmes et, encore plus précisément, de production de programmes fiables, économiques…toute propriété que l’on associe généralement à la notion de qualité.
1.2 Essai de justification
Lors de la conception de ce module, nous avons absolument tenu à glisser ce chapitre dans le plan. « Apprendre à programmer en COBOL » n’est pas un objectif suffisant pour nous. Nous voulons y ajouter le mot « bien », pour le transformer en « Apprendre à bien programmer en COBOL ». Bien programmer, en effet, doit être l’objectif de tout informaticien et ce quel que soit le langage utilisé. Dans le cadre qui est le notre actuellement, COBOL, cet objectif est encore plus prioritaire. Ce langage a, rappelons-le, été conçu pour être standard et appliqué à la gestion.
La création d’une application est une activité coûteuse et l’entreprise doit planifier cette activité en termes d’investissements et de retour sur investissements. Plus l’application sert, plus le retour sera important. Les informaticiens, d’un autre côté, ne se consacrent pas qu’à une seule série de programmes. Durant leur vie professionnelle, ils vont créer, reprendre, modifier, adapter… des programmes.
1.3 À propos de normes
Par tradition, les français n’aiment pas trop les normes trop strictes. Par habitude, les étudiants programmeurs relèguent ces normes au second plan (cela est sans doute dû au fait que leur premier objectif est d’abord de faire tourner ce f… programme ; alors, pensez, bien programmer…). Vouloir initier les étudiants programmeurs français aux normes de programmation est donc une vraie gageure. Pour autant est-ce nécessaire. Nous sommes convaincus du fait que, par delà la définition précise des normes, l’existence même de celles-ci prime sur le reste.
Lorsqu’on est dans une société de services, on applique les normes en vigueur dans celle-ci. Si l’on change de société, il y a de grandes chances qu’elles changent également. Malgré cela, il faudra appliquer ces nouvelles normes. Nous considérons donc qu’il y a une norme, qu’elle est discutable mais que, comme toute autre, elle ne doit pas être discutée mais appliquée. Nous allons, sur ce point, jusqu’à considérer comme nul (et donc lui attribuer un zéro) un programme qui tourne mais qui ne respecte pas les normes. Radical, mais efficace.
1.4 Exemple et contre-exemple
La meilleure illustration que nous puissions fournir de la justesse de nos propos précédents réside dans un programme rédigé de deux façons, sans norme et avec. Une simple lecture de ces deux versions (elles sont présentées ci-après) suffit à convaincre les plus réticents.
………
