N'attribuez jamais à la malice ce que l'incompétence explique !
Napoléon
Ce document est un plagiat de
How to write unmaintenable code ?
(par Roedy Green).
Je l'ai traduit et adapté à Magic (le document original est lié
à Java).
Principes généraux
Pour tromper le développeur qui maintiendra vos programmes, vous devez
comprendre comment il fonctionne. Il a entre ses mains votre immense
programme. Il n'a ni le temps ni l'envie de le lire en entier, encore
moins de le comprendre. Son objectif est de trouver rapidement l'endroit
à modifier, de le modifier, de sortir, sans que la modification n'entraîne
des effets de bord.
Il voit votre programme à travers le tube extrait d'un rouleau
de papier toilette. Il ne peut voir qu'un petit morceau de votre
programme à la fois. Vous voulez vous assurer qu'il ne peut pas
comprendre votre programme en faisant cela. Vous voulez rendre
aussi difficile que possible la découverte du bout de programme
recherché. Mais surtout, vous voulez être sur qu'il ne doit rien
ignorer dans votre programme pour pouvoir le modifier.
Techniques Spécifiques
-
L'opération '0' de Magic (les anciens magiciens utilisent
le numéro des opérations) est l'opération commentaire.
On vous obligera certainement à l'utiliser (le fait qu'utiliser
cette opération rend le CTL plus gros et les programmes moins
rapides est cependant une réalité qu'il convient de garder à l'esprit).
- La technique la plus efficace est de mentir subtilement dans
les commentaires : par exemple ne mettez pas à jour les commentaires
quand le programme est modifié.
- Mettez abondamment des commentaires inutiles : 'Lien sur le fichier
#####' pour citer l'exemple le plus rencontré.
- Commenter les choses évidentes, mais jamais les
choses complexes.
- Ne décrivez jamais ce que fait le programme dans sa globalité.
-
Arrangez vous pour que l'on doive modifier plusieurs programmes à plusieurs
endroits lorsqu'un paramètre change. Pour cela, le plus simple est
d'utiliser la technique qui suit.
-
Utilisez le Ctrl+R sans modération. Il est beaucoup plus efficace
(et bien moins long à écrire) de
partir d'un programme existant, d'effectuer les modifications
mêmes mineures, que de paramétrer le programme pour pouvoir
l'utiliser de 2 manières.
Par exemple si vous avez un
programme d'impression de facture, dupliquez-le pour chaque
client qui a besoin d'une information particulière ou juste
d'une autre fonte. N'oubliez pas que l'on mesure encore
parfois la productivité au nombre de programmes écrit.
-
Testez en fonction d'une valeur et non pas en fonction
d'une fonctionnalité. Par exemple si vous avez un type
de pièce, faites le test 'Suppression possible'
sur (Type=1 OR Type=4 OR Type=5 OR Type=20) au lieu d'ajouter
le champ logique 'Suppression possible' dans le fichier
des types de pièce. De cette manière, si un nouveau
type de pièce doit être ajouté, vous devrez modifier tous les
programmes où le type de pièce est testé.
-
Assurez vous que chaque programme en fasse un peu plus (ou un peut moins)
que son nom ne le suggère. Par exemple le programme "vérifie la valeur"
la modifie si celle ci n'est pas valide.
-
Ne mettez jamais de commentaire sur une virtuelle. Par exemple
si cette virtuelle est un paramètre, ne précisez jamais si une
valeur est modifiée, si on attend qu'elle soit renseignée
en entrée, ...
-
Utilisez des numéros au lieu d'un code.
Si par exemple un flag peut prendre 3 valeurs, utilisez un numérique
(1,2 et 4 par exemple) au lieu d'une valeur alphanumérique compréhensible
('C', 'B', et 'F' pour Commande,Bon de livraison,Facture mis
dans la colonne sélection). Ne mettez jamais en commentaire ce que
signifient ces valeurs 1, 2 et 4 (n'utilisez pas le 3 car dans ce cas
la suite ne serait pas aussi "logique" en binaire).
-
Compactez au maximum votre code. Par exemple, faites 1 opération
"Modifier" avec une expression avec des IF imbriqués plutôt
que 3 opérations conditionnées. Vous pourrez ainsi parfois
dépasser la limite ridiculement basse de 255 caractères pour une
expression.
-
Soyez créatif dans l'utilisation des abréviations, et utilisez
parfois le mot dans sa totalité :
code regroupement, cd regroup, code reg., cd_rgrp, cregroup,
CODE REG, ...
-
Dans le même ordre d'idée, variez l'utilisation des accents : parfois
avec, parfois sans. Comme ça, les recherches devront se faire en 2 fois.
-
Vous écrivez plusieurs langues, n'hésitez pas à les utiliser :
l'anglais, l'américain, le français, le breton, le verlan, le klingon, ...
mais aussi inventer vos propres mots (inutile de les définir).
L'orthographe est la science des imbéciles, ne soyez pas un imbécile :
soyez inventif.
-
N'hésitez pas à utiliser des synonymes, des libellés imprécis et
des mots abstraits.
Par exemple utilisez "éditer" au lieu de "imprimer", et utilisez
simultanément "éditer" pour les programmes de saisie de données.
-
Vous pouvez utilisez le même nom de variable plusieurs fois
dans un même programme. Par exemple, si vous avez un fichier
paramètre vous pouvez faire 10 liens dans un même programme,
et donc utilisez dans vos sous-tâches 10 champs 'Valeur'
tous différents. L'utilisation généralisée d'une table
"paramètre" (constituée par les champs : clef, valeur, texte)
permet de masquer efficacement à quoi servent ces champs
'valeur' ou 'texte' qui fleurissent dans les expressions.
-
Mentez dans les noms de champs : utilisez N° pour un code alphanumérique
et Code pour un numérique.
-
Utilisez des champs devenus inutiles (ou mieux, pas encore utilisés)
pour stocker d'autres informations. Cela vous permet de préserver
l'espace disque et d'éviter de changer la structure de la table
en question. Vous pouvez même stocker plusieurs champs dans un seul
et le découper plus tard avec la fonction MID.
-
Utilisez un stockage différent de celui
qui vient à l'esprit : par exemple utilisez un alphanumérique de 1 caractère
avec un choix possible 'O,N' au lieu d'utilisez un logique, ou
bien utilisez un champ alphanumérique pour y mettre les valeurs '1', '2' ou
'3' à l'exclusion de toute lettre.
-
Utilisez des unités de mesure variées : cette méthode a fait ses
preuves sur Mars, où une sonde s'est écrasée pour des problèmes
de conversion entre des mètres et des pieds.
Par exemple, utilisez au lieu d'un numérique 6.2 un numérique de 8 : cela
permet d'utiliser un entier au lieu d'un nombre à virgule.
Les calculs sur les entiers sont beaucoup plus rapides
(oubliez le fait que Magic utilise en interne des nombres
à virgule de toute façon).
-
Utilisez le maximum de valeurs en dur, oubliez les paramètres. Par
exemple mettez les chemins en dur, il n'y a pas de raison pour
que votre programme soit utilisé à en autre endroit. Par exemple
si une prestation dépend de l'âge à 16 ans, utilisez 'âge <= 16'
mais aussi 'âge < 15', 'not(âge > 17)', 'âge-15 < 0'.
-
Ne mettez pas de nom dans la colonne 'Nom DB'. Magic va générer lui même
un nom de fichier à partir du numéro du fichier. Cela
oblige aussi à toujours créer les nouveaux fichiers à la fin
du dictionnaire au lieu de ranger dans un ordre logique.
-
Utilisez les types de la bonne façon : regardez quels sont les
masques dont vous avez besoin, et créez un type pour chaque
masque : Type Numérique N10.2 (libellé : Numérique N10.2)
et Alpha 30 (libellé : Alpha 30).
-
Triez votre dictionnaire des types et des fichiers par ordre
alphabétiques : vous pouvez ainsi séparer 'Code Client' de
'Libellé Client' de 'Type Client'.
-
Mettez à jour souvent, sans documenter les changements. Forcez
vos utilisateurs à suivre les mises à jour, personne ne veux
utiliser un programme obsolète. Profitez en pour modifier
subtilement certaines parties de l'interface graphique : déplacer un bouton,
inverser l'ordre de saisie entre 2 champs, ...
-
Choisissez des noms de champ sans rapport avec leur libellé
affiché à l'écran : par exemple utiliser 'Collaborateur'
dans la base et 'Vendeur' à l'écran. Une manière extrême
est de numéroter les champs, mais même vous serez incapable
de maintenir votre propre code. De la même manière, utilisez un
nom différent entre le fichier ou la table et sa description dans Magic.
-
Gardez vos programmes ou vos tâches obsolètes, ils pourront
toujours resservir un jour. Ne précisez pas qu'ils ne sont
plus utilisés.
-
N'ayez jamais un ordre logique sur les paramètres d'un programme :
Par exemple si vous passez les paramètres 'Un' et 'Deux' dans cet
ordre, passez ces paramètres parfois dans l'ordre 'Deux' et 'Un'.
Plus subtil, trompez vous 2 fois dans l'ordre des paramètres : inversez
2 paramètres dans l'appel du premier programme, puis inversez les à nouveau
dans ce premier programme pour l'appel dans le second.
-
Les langages modernes bannissent l'utilisation des pointeurs, qui
sont des outils puissant mais dangereux dans les mains d'un
développeur non entraîné. Magic vous offre sa version des
pointeurs : les fonctions varset, varcurr, varinp, varattr, varmod, varname,
varprev. Utilisez les. Vous pouvez même utiliser le varset quand
vous n'en avez pas besoin (par exemple : varset('A'VAR, varcurr('B'VAR))).
-
Utilisez tous les trucs de programmation Magic avancée, sans jamais ni les
expliquer ni même les signaler : par exemple utilisez comme séparateur
la tabulation, quasi impossible à utiliser dans les programmes
d'importation de données. Saviez-vous qu'un programme en mode
suppression est plus rapide si le paramètre "Forcer la suppression"
est aussi à oui : il faut intervenir à 2 endroits pour que ce
programme ne supprime plus les enregistrements.
-
Si possible, n'utilisez pas de séparateurs dans les fichiers à plat
d'export/import de donnée : avec un séparateur, on peut lire
le fichier dans un tableur ou dans un éditeur de texte.
-
Laissez l'option 'Abandon de transaction' à oui dans les batchs.
Cela marche tant que l'utilisateur ne clique pas sur l'écran
pendant l'exécution du batch. L'illusion que le programme
marche bien peut durer longtemps.
-
Utilisez des fichier .bat. La syntaxe des commandes change
régulièrement avec les versions de Dos/Windows : xcopy, deltree, at
par exemple. En fonction du paramètre "Fermer en quittant"
des raccourcis MS-DOS, la fenêtre peut ne pas se fermer
du tout. Évitez aussi de générer dynamiquement ces .bat,
cela éviterai qu'ils se perdent.
-
Utilisez régulièrement des expressions du style : 'IF(A=0,'TRUE'LOG,'FALSE'LOG)',
ou bien une expression 'FALSE'LOG au lieu de simplement 'No'.
Cela montrera au correcteur qu'il est dans un programme écrit par un
débutant, ce qui ne peut que le rendre nerveux.
-
Faites un fichier des messages. Cela est très important dans le
cadre d'une traduction, et permet d'être cohérent dans les
libellés utilisés. Cela permet surtout de ne pas savoir
quel message est affiché quand on parcours le programme (à
moins d'avoir repris en commentaire le texte du message, mais
cela contredit la règle n°1).
-
Ne corrigez pas les bugs qu'une simple intervention manuelle
dans les tables peut corriger : cela contribue à vous rendre
indispensable.
-
Utilisez comme unité pour les écrans d'impression les
"unités de dialogue". Cela permet de changer la taille
des impressions en fonction de la taille de l'écran !
Changer aussi la police N°7 (police taille fixe par
défaut) en police à espacement proportionnel, cela oblige
à vérifier la taille de chaque contrôle dans ses propriétés.
-
Si deux techniques existent pour accomplir une fonction, il
faut utiliser ces 2 techniques en alternance, en les mixant
éventuellement dans le même programme. Par exemple pour faire
une entête de table avec des boutons de tri (pour trier la colonne),
vous pouvez utiliser des kbput, une clef temporaire sur une virtuelle,
une commande SQL directe, ... Si une technique est bien implantée dans
une application, utilisez-en une autre.
-
Ne rangez pas les colonnes selon l'index unique principal : celui-ci pourra
être champ17, champ01 et champ03 et champ02 par exemple, le programmeur
distrait pourra oublier le champ17.
Faites le test
Combien de ces techniques avez vous déjà utilisées ?
|