Programmation C-C++/Écrire du code illisible

Un livre de Wikilivres.
En cours d'importationlink={{{link}}}

Ce livre est en cours de copie depuis le site http://casteyde.christian.free.fr/cpp/cours/online/book1.html qui le fournit sous licence GFDL.

Cours de C/C++
Le langage
Première approche
Les structures de contrôle
Types avancés
Pointeurs et références
Le préprocesseur
Modularité et compilation
Écrire du code illisible
C++ : La couche objet
C++ : Les exceptions
Identification des types
Les espaces de nommage
Les templates
La bibliothèque standard
Notions de base
Les types complémentaires
Les flux d'entrée / sortie
Les locales
Les conteneurs
Les algorithmes
Conclusion
Priorités des opérateurs
Draft Papers
Bibliographie

Livre original de C. Casteyde
Modifier le modèle

Il est facile, très facile, de faire des programmes illisibles en C ou en C++. Il existe même un concours du code le plus obscur ! Cela dit, deux choses peuvent être dites à ce propos :

  1. Ça n'accroît pas la vitesse du programme. Si l'on veut aller plus vite, il faut revoir l'algorithme ou changer de compilateur (inutile de faire de l'assembleur : les bons compilateurs se débrouillent mieux que les êtres humains sur ce terrain. L'avantage de l'assembleur est que là, au moins, on est sûr d'avoir un programme illisible.).
  2. Ça augmente les chances d'avoir des bogues.

Si vous voulez malgré tout vous amuser, voici quelques conseils utiles :

  • écrivez des macros complexes qui font des effets de bords insoupçonnés et qui modifient des variables globales ;
  • abusez de l'opérateur ternaire ?: et surtout de l'opérateur virgule ,. Utilisez les opérateurs d'incrémentation et de décrémentation à outrance, en version préfixée et suffixée, tout spécialement dans des expressions utilisant des pointeurs ;
  • placez ces opérateurs dans les structures de contrôles. Notamment, utilisez l'opérateur virgule pour faire des instructions composées dans les tests du while et dans tous les membres du for. Il est souvent possible de mettre le corps du for dans les parenthèses ;
  • si nécessaire, utilisez les expressions composées ({ et }) dans les structures de contrôle ;
  • choisissez des noms de variable et de fonction aléatoires (pensez à une phrase, et prenez les premières ou les deuxièmes lettres des mots au hasard) ;
  • regroupez toutes les fonctions dans un même fichier, par ordre de non-appariement ;
  • inversement, dispersez les définitions des variables globales dans tout le programme, si possible dans des fichiers où elles ne sont pas utilisées ;
  • faites des fonctions à rallonge ;
  • ne soignez pas l'apparence de votre programme (pas d'indentation ou, au contraire, trop d'indentations), regroupez plusieurs instructions sur une même ligne ;
  • rajoutez des parenthèses là où elles ne sont pas nécessaires ;
  • rajoutez des transtypages là où ils ne sont pas nécessaires ;
  • ne commentez rien, ou mieux, donnez des commentaires sans rapport avec le code.

Exemple 7-1. Programme parfaitement illisible[modifier | modifier le wikicode]

/* Que fait ce programme ? */
#include <stdio.h>
int main(void)
   {
int zkmlpf,geikgh,wdxaj;
    scanf("%u",&zkmlpf);for (wdxaj=0,
   geikgh=0;
      ((wdxaj+=++geikgh),geikgh)<zkmlpf;);
   printf("%u",wdxaj); return 0;
}

Vous l'aurez compris : il est plus simple de dire ici ce qu'il ne faut pas faire que de dire comment il faut faire. Je ne prétends pas imposer à quiconque une méthodologie quelconque, car chacun est libre de programmer comme il l'entend. En effet, certaines conventions de codages sont aussi absurdes qu'inutiles et elles ont l'inconvénient de ne plaire qu'à celui qui les a écrites (et encore...). C'est pour cette raison que je me suis contenté de lister les sources potentielles d'illisibilité des programmes. Sachez donc simplement que si vous utilisez une des techniques données dans ce paragraphe, vous devriez vous assurer que c'est réellement justifié et revoir votre code. Pour obtenir des programmes lisibles, il faut simplement que chacun y mettre un peu du sien, c'est aussi une marque de politesse envers les autres programmeurs.