La crypto-programmation ou l'art de coder en codé. par Bugbert

Contact : gengis.scann@free.fr

Résumé

Malgré les progrès supposés des environnements de programmation, il est toujours aussi difficile de relire un programme. Et si c'était voulu ?

Bugbert a travaillé dans deux  sociétés de services informatiques avant d'entrer dans un centre de recherches. Les exemples illustrant cet article ont  une forte coloration calcul scientifique. On peut sans crainte les généraliser et les appliquer à d'autres situations.

Sommaire
 

Introduction (aspect paléontologique)
Pourquoi d'abord (aspect économique)
Psychologie du programmeur (aspect ..... humain)
Que fait la qualité ?
Du bon usage des commentaires
Y a-t-il une doc ?
Conclusion

Introduction (aspect paléontologique)

Toute personne amenée à relire des programmes constituant  les logiciels, peut constater qu'ils sont plus proches d'un sabir que d'une suite logique d'instructions, et ceci quel que soit le langage utilisé, et quelle que soit la complexité du problème traité.

Les langages de programmation existent pourtant depuis les années 50 : FORTRAN pour le calcul  scientifique, COBOL pour la gestion. La programmation est tour à tour devenue structurée, modulaire, abstraite, et objet. Des thèses se sont succédées sur la linguistique informatique, sur la preuve de programmes, etc... Les algorithmes actuels permettent de résoudre 99 % des problèmes courants.  On peut réutiliser de nombreux composants logiciels, outils, bibliothèques de programmes gratuits ou payants. Les ordinateurs et les logiciels ont fait les progrès phénoménaux. Les systèmes, multiples au départ ont convergé vers deux familles. L'effort fourni par les entreprises en matière de Qualité du Logiciel montre leur désir de mieux maîtriser le processus de programmation. Les programmeurs ne mordent presque plus quand on leur exhibe les normes ISO 9000  et AZ 67 130.

Après 50 ans de progrès dans l'environnement de programmation, et dans le niveau d'abstraction des langages, on devrait n'écrire que des programmes clairs, lisibles, structurés, faciles à comprendre pour un débutant. Avec l'expérience accumulée par la relecture de ces millions de lignes,  et un minimum de professionnalisme, tout ce qui est source d'erreur, d'incompréhension, tout ce qui fait que, même si on a la compétence requise,  on perd un temps fou à "entrer" dans un logiciel devrait avoir été identifié et éliminé.

Il faut donc se rendre à l'évidence. Ce type de codage ne peut résulter ni de la négligence, ni de l'incompétence des programmeurs qui sont parfois les plus brillants ingénieurs issus des  plus brillantes écoles.  Il résulte d'une démarche délibérée que l'on nommera ici la crypto-programmation.

Notons que l'on parle ici de codage des programmes et non d'écriture. Un peu comme si l'intention n'était pas, au départ, de décrire des tâches, mais peut-être aussi de cacher la façon dont on s'y prend. Ce terme est d'ailleurs repris par  les normes.

Pourquoi (aspect économique)

Un logiciel crypto-programmé est conforme avant tout à une logique économique.

Il est plus rapide à développer : l'instinct prend le pas sur le formalisme. On perd donc moins de temps à réfléchir, organiser, lire des ouvrages, ou  rendre les programmes  présentables et réutilisables. La puissance des environnements actuels compense d'ailleurs le manque d'élaboration.

Comme on le verra plus loin, la formation du programmeur est relativement aisée. Contrairement à d'autres métiers pour lesquels la formation d'un ingénieur débutant dure 6 mois, un programmeur est immédiatement opérationnel.  Des stagiaires, ou des ingénieurs chimistes sortis d'école deviennent de bons programmeurs. Des sociétés de service les proposent même en tant qu'experts à leurs clients. Attention cependant, cela ne doit pas être trop voyant : " Dochpy est furieux, CRYPTECH avait promis des ingénieurs expérimentés en Ada, finalement c'était des débutants qu'il a fallu former et qui sont partis chez TOPKON au bout d'un an !"

Le code produit est plus volumineux, du fait de l'utilisation systématique du copier/adapter/oublier (CAO en abrégé). En général les chefs attachent une importance au nombre de lignes écrites. Ce critère valorise le logiciel qui passe pour une application sérieuse : "Tu te rends compte, FONEBONE IV fait quand même 200000 lignes !". De son côté, le programmeur peut mettre en avant sa productivité : "Albinoni est une bête, il a écrit 800 lignes en 2 jours !".

Un logiciel crypto-programmé ou non doit être maintenu. Évidemment, le codage rapide laisse passer (provoque ?) quelques bugs. Relativement peu par rapport au nombre de lignes écrites. L'obligation de maintenance pérennise le service informatique de l'entreprise ou améliore le chiffre d'affaire d'une société prestataire en même temps qu'elle justifie le budget du service prescripteur. La prestation de maintenance étant évaluée au moyen du nombre de fiches d'anomalie traitées, leur absence serait dommageable.

Le niveau de cryptage (appelé aussi niveau d'imbitablité) est limité par la durée de garantie. En principe, le crypto-programmeur doit pouvoir relire ce qu'il a codé dans les 6 mois écoulés.

La durée de vie d'un logiciel est conditionnée par son utilité (ou plutôt l'existence d'utilisateurs), et par sa conformité vis à vis d'un environnement fluctuant (machine, système, composants logiciels externes). Tous ces facteurs peuvent favoriser des évolutions. Les utilisateurs peuvent réclamer des améliorations, parfois inspirées par leur ordinateur familial. L'effet de mode, ou simplement la curiosité incite à utiliser des composants logiciels récents (donc instables) ou leurs fonctionnalités les plus originales (donc risquées), histoire de joindre l'utile à l'agréable. Il est probable qu'un de ces éléments tombe en obsolescence et nécessite un portage donc un nouveau contrat.

Un code bien pâteux, constitué de plusieurs couches sédimentaires décourage la concurrence : Un simple examen des sources montre que l'effort de décodage initial à produire est assez conséquent : "Le Centre a lancé un appel d'offre pour la maintenance de FONEBONE.  Comme TOPKON S.I. exigeait une pré étude de 3 mois, c'est CRYPTECH qui a conservé le marché". Dans un autre registre, on peut aussi diffuser les sources d'un logiciel sur le Net sans dévoiler son savoir faire.

A plus ou moins long terme (cela dépend de la qualité de l'encodage) on peut réaliser un ou plusieurs  audits, faire intervenir des consultants.  Dans les cas extrêmes on peut envisager une rétro conception. C'est à dire rédiger le document qui décrit la structure du logiciel à partir du code. C'est un peu comme remettre le dentifrice dans un tube.

Le stade ultime étant le redéveloppement : "FONEBONE III était en Fortran, FONEBONE IV sera en C++" Ce qui constitue un progrès indéniable.  Retour à la case départ.
 

Psychologie du programmeur (aspect néanmoins humain)

En fait, on devrait parler des programmeurs. Ils sont regroupés dans différentes tribus qui cherchent toutes à se singulariser dont certaines s'apprécient autant que les supporters du PSG et de l'OM. Pour les unixiens Windows est un système conçu pour les secrétaires et testé en laboratoire sur des singes. Pour les windowsers, Unix est un anachronisme. Autre exemple : le clivage client/prestataire. Pour le prestataire, le client est sûrement compétent dans son métier, mais possède quelques lacunes en informatique, c'est d'ailleurs pour cela qu'il fait appel à lui. Il bénéficie d'un statut  plus avantageux que lui (nul + planqué, quoi).  Pour le client,  le prestataire, qui n'a pu se faire embaucher que par une société de services, est  là pour faire le travail qu'il n'a pas envie de faire (nul + grouillot, quoi).

La crypto-programmation :

• Valorise le programmeur.  La complexité apparente du code le fait  même passer pour quelqu'un de savant.  Personne ne peut critiquer ses choix. Il faudrait d'abord décoder ses programmes.
• Sécurise le programmeur qui devient indispensable : " Si Albinoni quitte CRYPTECH, le Centre  peut arrêter  FONEBONE !". Assure même sa promotion : "Albinoni est embauché par le Centre pour s'occuper de FONEBONE IV". Ce n'est pas sans risque, les logiciels ne sont pas immortels. Mais rien n'empêche de s'occuper de plusieurs logiciels.
         .
La crypto-programmation renforce l'esprit de corps
• La crypto-programmation est l'un des signes distinctifs des communautés de programmeurs, au même titre que l'habillement. Si le programmeur C utilise d'une façon aussi intense toutes les spécificités du langage qui rendent son texte illisible sans rien apporter au programme, c'est qu'il a trop peur d'être confondu avec un  programmeur Pascal, ou pire de pouvoir être relu par un programmeur Fortran. Idem pour un programmeur C++ vis à vis d'un programmeur C.
• Le novice assimile rapidement les habitudes de ses congénères. La fierté d'entrer dans une confrérie ou alors la peur d'être différent. Voir l'article "Le théorème du singe"
  
• Le langage devient d'ailleurs la spécialité du programmeur. On ne dit pas : "Albinoni est spécialiste en graphique" mais "Albinoni fait du C++".

Comment y parvenir  ? (formation du crypto-programmeur)
• Un codage hermétique peut être réalisé rapidement par un non spécialiste. La démarche est naturelle : on écrit ce que l'on pense au fur et à mesure. Le challenge est d'écrire le plus vite possible sans montrer le moindre effort de réflexion.
• L'apprentissage s'appuie essentiellement sur l'exemple. En général le premier programme est celui d'un collègue qu'il faut adapter. Au départ, il peut y avoir un choc; l'apprenti peut même montrer quelques signes de défaillance en voyant l'étendue de l'encodage. Il peut même proposer sa démission : "Je ne suis ni Mac Gyver ni Gérard d'Aboville !".  Heureusement le chef de projet lui montre le paquet d'instructions qu'il faut copier et comment il doit l'adapter. Il n'a peut-être pas entièrement compris à quoi servaient les instructions incriminées, mais il est heureux d'avoir réussi son boulot. La suite se déroule dans le même style.
• La programmation est en soi une activité attrayante pour un débutant (voir l'article programmation and sex) . Il est naturellement attiré par les instructions les plus ésotériques et les plus équivoques. Les formateurs leur accordent toujours une place privilégiée. Très vite il se sent aussi fort qu'Albinoni qui a pourtant fait des études d'informatique.
• Une connaissance approfondie des algorithmes ou des systèmes n'est pas indispensable. Créer un logiciel est un travail collectif. En cas de problème, on peut toujours l'exposer à un membre de l'équipe. Si personne n'a l'information on improvise. Il se peut que la solution fasse 2000 lignes alors que 300 auraient suffi si la bonne technique avait été utilisée. En général personne ne s'en aperçoit. Justement par ce qu'il n'y a pas de spécialiste. L'empirisme compense l'absence de bagage théorique initial.
• Autre avantage : un non spécialiste n'a pas l'esprit déformé par des considérations théoriques sur la programmation. Il n'a pas été formé par des professeurs qui sont de farouches opposants à la programmation instinctive. Il n'émet pas de jugement critique sur le type de travail qu'on lui demande et qui pourraient indisposer le chef de projet : "C'est pas possible, il a écrit ça avec les pieds, Albinoni ! Il n'a jamais appris à programmer un automate ?".
• L'apprentissage se termine quand il est capable d'inventer ses propres astuces de programmation. Une "astuce de programmation" consiste à exploiter un phénomène mal connu, si possible non documenté, pour  déclencher un effet qui n'a rien à voir avec ce qui est écrit. A l'"astuce" du développeur correspond la "bidouille" du maintenicien. Pour lui, il s'agit de contourner un dysfonctionnement du programme par un moyen non orthodoxe qui a le mérite d'une part de minimiser le nombre de lignes modifiées, d'autre part d'embrouiller encore plus son successeur.
• La plupart des ouvrages  (les manuels de programmation en X11/Motif pour le C) ou les codes récupérés sur le Net  donnent un bon aperçu de ce que peut être la crypto-programmation.

Contrer les réactions négatives :
• Il se peut que même s'il pratique le même style de codage, votre entourage professionnel soit confronté à vos programmes et vous fasse part de son émotion.
• Dans tous les cas, vous pouvez vous justifier par le manque de temps. Les programmeurs sont toujours en retard.  "C'est vrai que c'est un peu bâclé, mais il fallait livrer avant-hier, alors on a fini à la truelle ...".
• D'ailleurs, si vous codez suffisamment vite, inutile de vous justifier, personne n'osera émettre la moindre critique. Même s'il est évident que ce que vous écrivez est irrécupérable et coûtera dix fois plus de temps au malheureux qui devra le modifier ...
        .
Face à un collègue :
• Il est peu fréquent qu'un collègue critique la qualité de votre codage. Esprit de corps oblige il le fait rarement en votre présence,  et il doit sûrement coder aussi bien que vous.
• Première parade : "Ne m'embête pas, cela marche, au moins !". Vous le traitez ainsi de perfectionniste (c'est une insulte pour un crypto-programmeur) et vous lui rappelez au passage que ses programmes plantent  parfois.
• Regardez le d'un air étonné et dites lui : "Mais c'est comme cela qu'on fait !". En principe il doit imaginer qu'il a des lacunes et cela doit le mettre mal à l'aise.

Comment gérer les prestataires qui s'émeuvent de la qualité du codage ?
•  Si vous êtes l'auteur du délit, vous pouvez dire d'un air détaché "Oh, moi, tu sais, je ne suis pas informaticien". Cela coupe court à toute forme de conseil de programmation rébarbatif. Vous pouvez alors finir de coder le  programme qu'il va maintenir le mois suivant. L'écriture est plus valorisante que la maintenance. Profitez en pour lui glisser quelques astuces de programmation au passage. Cela lui apprendra.
• La réponse la plus fréquente : "Cela a été développé par un stagiaire" et prenez un air compatissant.
• Jouez la carte de la solidarité :  "Cela a été développé par Marmolle, il est dans ta boîte". Son devoir est de ne pas insister.

Comment gérer le client qui ne comprend rien à ce que vous écrivez ?
• Ne lui dites pas :  "A toi je peux bien le dire : c'est voulu".
• Le mensonge le plus fréquent : "Ce n'est pas très lisible, mais il fallait optimiser". Le client ignore que depuis 20 ans, les compilateurs optimisent le code de façon bien plus efficace que les pauvres acrobaties stylistiques du programmeur.
• Montrez lui que votre code est suffisamment commenté (Voir ce paragraphe)
• Ou montrez lui le seul programme clair que vous ayez rédigé (c'est toujours bon d'en avoir un).
• Sinon dites "C'est pour mettre en place un couplage heuristique optimal sur un graphe biréparti. C'est vrai que c'est un peu technique. Tu veux que je t'explique ? ". En principe, il répond non, prétextant qu'il connaît déjà.
          .
Enfin en vrac, quelque pathologies liées au métier de programmeur :
• Tendances maniaques : un programmeur est esclave de ses habitudes, même si elles pénalisent le projet. Il est dangereux de le contrarier.
• Mimétisme : le débutant reproduit parfaitement le style des programmes qu'il lit, même (surtout) s'il ne comprend rien.
• Tendance paranoïaque : le programmeur se méfie des qualiticiens, des commerciaux, des utilisateurs, des clients et de la direction de son entreprise. Il est aussi un peu macho. Mais est-ce vraiment une pathologie ?
• Autisme : face à un écran, le programmeur perd la notion du temps. Le monde peut s'écrouler autour de lui, il ne s'en apercevra pas. Rentré chez lui il peut rester le regard vague et immobile devant le dîner qui brûle, malgré les hurlements de sa tendre épouse.
• Tendances schizophréniques :  Le programmeur C++ ne programme pas, il fait de l'objet. Le chercheur, même s'il passe 6 heures par jour à programmer, n'est pas un informaticien. Le prestataire ne cesse de critiquer l'entreprise de son client,  pourtant (à partir d'un certain âge) il rêve d'y entrer.
• Cas d'amnésie : une fois embauché, l'ex-prestataire oublie qu'il l'a été un jour.
• Et tant qu'on est au niveau comportemental, et même si l'on ne peut forcément parler de pathologie, voir l'article programmation and sex.

Que fait la Qualité ?

Qu'est-ce que la Qualité, avec une majuscule ?  :  Pour un restaurant,  il existe un certain nombre de critères qualité comme la température des frigos, la présence (absence?)  de bactéries, les dates de fraîcheur des aliments. Les critères qualité doivent être respectés, ce qui ne change rien au caractère insipide du burger que l'on vous sert. Pour le logiciel c'est un peu pareil. Sauf que les critères sont peut-être un peu plus difficiles à définir et encore plus à mesurer.

Aspect méthodologique : Concernant le développement logiciel, MAC CALL a défini un certain nombre de facteurs qualité qui sont les caractéristiques du logiciel vues par un utilisateur : par exemple l'efficacité, la maintenabilité et la facilité d'emploi, etc ...  A chaque facteur , correspondent des critères (caractéristique internes). Par exemple si un utilisateur souhaite disposer d'un logiciel facilement maintenable, le code doit être modulaire, lisible, structuré, auto-documenté etc.. . Ensuite, il convient de définir les actions et les règles à mettre en oeuvre  pour que chaque critère soit effectif. Comment rendre un code lisible, par exemple... Il est clair que si de telles actions étaient effectivement mises en oeuvre, la crypto-programmation serait en danger. Et si de telles actions avaient existé un jour, cela se saurait.

Aspect normatif : Les normes ISO9000 (norme générale internationale) et AZ 67 130 (norme française dédiée au développement logiciel) ont défini quelques règles concernant les étapes d'un développement logiciel. En un premier lieu on décrit le logiciel tel que le verrait l'utilisateur (spécifications) puis on dit comment on va le réaliser (conception) puis, l'artiste programmeur entre en scène (codage).  Après quelques tests,  cela se termine par l'acceptation du client (recette finale). Les normes disent comment valider chaque étape. En gros, à chaque réunion on écrit un compte-rendu et on le signe, à chaque étape on livre un document ou un logiciel, à chaque livraison on signe un procès-verbal.

  Ingénieur Qualité et autres vérificateurs : Le rôle de l'ingénieur qualité est de vérifier si les documents sont bien livrés et bien signés. Donc, rien de bien méchant, il ne s'agit que d'une démarche procédurale qui ne concerne pas directement le programmeur. Mais attention, si on ne lui donne pas ses documents à temps, Mlle Parker peut mordre. Le vérificateur est un collègue qui relit vos propres documents s'ils sont jugés trop techniques pour le qualiticien. Si vous n'avez jamais rien dit de méchant sur les siens, il se montre assez cool. Il se borne à signaler les fautes d'orthographe qu'il est capable de trouver, à aligner les listes à puces et vérifier si les en-têtes ont bien été mises à jour. Il ne critique pas le fond du document, la lecture étant déjà une épreuve, il ne va pas en plus essayer de le comprendre, et aussi car les fiches de relecture sont assez pénibles à rédiger. Car Mlle Parker n'aime pas le surligneur Ce serait trop facile.

Les problèmes surviennent quand le qualiticien décide de vérifier l'application du Plan Qualité ou des règles de codage (voir documents) . C'est seulement à ce moment que l'on s'aperçoit à quel point elles sont inapplicables. Manque de chance, Mlle Parker n'est pas du genre à abandonner. Le clash avec Albinoni, dont la diplomatie est connue, aurait mérité d'être relaté, mais ceci ne concerne pas la crypto-programmation.

Finalement, à quoi sert la qualité ? : Avant tout à rassurer la hiérarchie. Peu lui importe l'aspect méthodologique, c'est surtout le côté bureaucratique qui est ici le plus intéressant. L'existence d'une procédure destinée à industrialiser le développement du logiciel  fait croire à la hiérarchie qu'elle maîtrise quelque chose. Et aussi que le processus de développement dépend moins de ces êtres bizarres et incontrôlables que sont les programmeurs. Il n'est pas non plus inutile de leur réclamer régulièrement leur Fiche d'Avancement des Tâches, histoire de leur montrer qui est le chef, quoi. Dans les relations client/prestataire, la proposition commerciale précise que le prestataire s'engage à suivre une démarche qualité rigoureuse lors de la réalisation de ce contrat. Cela fait sérieux.

Moralité : Si le programmeur est payé à la ligne, le qualiticien est payé à la page. L'assurance qualité ne constitue pas un obstacle pour la crypto-programmation.

Retour au sommaire
 

Du bon usage des commentaires
 

A propos de l'utilité des commentaires, je me permets de citer un article de Jacques-André Laneyrie paru dans la revue de l'AFCET en 1991. En premier lieu il évoque les commentaires dans les programmes des autres.

Quand je reprends un programme, j'ignore systématiquement les commentaires. Si je suis obligé de reprendre un programme, c'est que le programmeur a fait des erreurs. Comment se fier à ses commentaires ? Car le commentaire, par définition échappe à la syntaxe du compilateur considéré. Donc il n'est jamais vérifié, donc potentiellement faux. (...) J'ai perdu de nombreuses heures en m'aventurant sur de fausses pistes sur la foi de commentaires tendancieux. (...) Dans un cas, il s'agissait de mes propres programmes où j'avais oublié non seulement le sens de ce que je voulais faire  mais encore ce que mon commentaire voulait dire. (...) Quelqu'un qui a du mal à s'exprimer en COBOL ne saura jamais s'exprimer en français (....)

  Toujours du même auteur qui parle des commentaires dans ses propres programmes :

Si je commente un programme, ce n'est pas pour moi car en principe je sais ce que j'écris. J'agis donc par altruisme. Or cette attitude ne peut me valoir que des ennuis : D'abord cela prend du temps et cela fait baisser ma performance. Ensuite cela aide les autres, ce qui améliore leur performance. Si mon commentaire est bon, le camarade qui l'utilise n'en soufflera mot. Si par contre il est mauvais, il le hurlera dans les couloirs (mais à voix basse pour que je ne l'entende pas), au moins autant que si je n'en mets pas (ne serait-ce que par ce qu'il n'en met pas non plus).
Un programme clair, lisible, aéré structuré, commenté et documenté est un programme que n'importe qui (par exemple la petite soeur du directeur financier) peut reprendre facilement. A ma place. Dans mon fauteuil. Sur mon bureau. Pendant que je pointe à l'ANPE.

Moralité :
Un programmeur à l'esprit ordonné écrit des instructions limpides. Un programmeur à l'esprit embrouillé fait d'obscurs commentaires. C'est l'instruction qui paye, le commentaire conseille. Le conseilleur n'est pas le payeur.

On peut donc considérer que les commentaires ne constituent pas une gêne pour le crypto-programmeur.

Si Mlle Parker, Ingénieur Qualité du Centre l'exige, un code peut être abondamment commenté. Il suffit de paraphraser ses propres instructions. S'il existe des outils pour mesurer le taux de commentaires dans un programme, leur pertinence n'est pas quantifiable. Ni leur véracité, d'ailleurs. Cependant, la conscience professionnelle des programmeurs les empêche de mentir autrement que par omission.

Notons que les commentaires en anglais améliorent le niveau d'imbitabilité du programme.
 

  Y a-t-il une doc ?
 

A quoi sert la documentation ?  : Avant tout à contenter l'ingénieur qualité, tout heureux d'archiver une trace écrite de la structure du logiciel. Accessoirement à guider les programmeurs dans le développement. En dernier lieu à assister le maintenicien lorsqu'il prend le code en main. A condition qu'elle soit à jour, et plus lisible que le code.

A quoi reconnait-on une bonne documentation ? : A son épaisseur. Un document bien épais limite le zèle des lecteurs et évite ainsi des remarques désagréables. Un document à caractère technique autorise l'usage d'un français approximatif et du copier/adapter. Il n'est vraiment relu que par les programmeurs s'il leur est utile et s' ils y accèdent avant le codage. Après le développement, il a moins de chances d'être relu que les programmes qui eux sont  maintenus.

Remarque : Tout ce qui a été dit sur les commentaires peut aussi être appliqué à la documentation.

Le Plan Qualité : En début de projet, le chef de projet doit exposer dans un document  les méthodes de travail qui seront mises en oeuvre. C'est le  Plan Qualité du Logiciel (ou PQL les qualiticiens adorent les majuscules et les sigles). Pour aller plus vite, on reprend celui d'un autre projet. Qui avait peut-être été trouvé dans une brocante. On peut aussi prendre le plan type en vigueur chez CRYPTECH (qui lui aussi venait d'un autre projet) . Comme le chef de projet a autre chose à faire qu'à s'occuper de cette paperasse, et qu'il y a le mot "Qualité" dans son intitulé,  c'est le plus souvent le qualiticien qui rédige, pardon copie et adapte ce qui doit être un document de travail. En gros il change les entêtes, le nom du projet (FONEBONE III par FONEBONE IV), le nom du prestataire (Cryptech Ingénierie par CRYPTECH SA), le nom du chef de projet (Albinoni par Marmolle), vérifie si on ne fait pas référence à un dérouleur de bande ou à un lecteur de cartes perforées et place le nouveau logo. Le contenu n'a que peu d'importance, il n'est jamais appliqué, ne serait-ce que parce que celui qui l'a rédigé n'a jamais programmé.

Les règles de codage : Un document qui qui les répertorie est  parfois exigé par le client. Qui rédige ce document ? Un expert qui va reprendre un ou deux autres guides de programmation et qui va les adapter (changement d'en-têtes et de logos). L'expert peut être un consultant ou un stagiaire ou un qualiticien, rarement un programmeur car il cumule deux handicaps : il est en bas de la chaîne de l'évolution et il manque de temps, vu qu'il est trop pris par la relecture de codes imbitables. Elles rappellent quelques traditions dont certaines sont devenues sans objet  (en C les constantes sont en majuscules, en Fortran les entiers commencent par i,j,k,l,m ou n). Parfois un comité Théodule se réunit pour aborder des problèmes importants : par exemple s'il faut mettre un blanc avant un point virgule ou si les indentations sont de 3 ou 4 espaces. De toutes façons pour changer les habitudes d'un programmeur, il faut se lever de bonne heure.

Dossier de conception  : Prévu avant le codage pour renseigner les programmeurs de l'équipe. Souvent rédigé après coup. Parfois pas du tout. Pas vraiment indispensable si le programmeur est seul ou pour certaines applications. On peut parfois passer directement du manuel utilisateur à la programmation. Ce n'est reculer que pour mieux sauter, car la Qualité réclame son dû. Alors il faut en catastrophe rédiger un document (qui ne servira sûrement  à rien) en fin de projet. On peut échapper à ce pensum si on est soi même le client, ou par des artifices comme la génération automatique de documentation à partir du code.

Conclusion
 

Tu es sérieux quand tu écris tout cela ?? On n'arrive pas à savoir si tu es pour ou contre ...