Codage en dur.

Le codage en dur est la pratique de développement logiciel consistant à intégrer des données directement dans le code source d'un programme ou d'un autre objet exécutable, au lieu de les obtenir à partir de sources externes ou de les générer à l'exécution.

Les données codées en dur ne peuvent généralement être modifiées qu'en éditant le code source et en recompilant l'exécutable, même si elles peuvent être modifiées en mémoire ou sur le disque à l'aide d'un débogueur ou d'un éditeur hexadécimal.

Les données codées en dur conviennent le mieux à des informations immuables, telles que les constantes physiques, les numéros de version et les éléments de texte statiques.

Les données à codage souple, en revanche, encodent des informations arbitraires via les saisies utilisateur, les fichiers texte, les fichiers INI, les réponses de serveur HTTP, les fichiers de configuration, les macros de préprocesseur, les constantes externes, les bases de données, les arguments de ligne de commande, et sont déterminées à l'exécution.

Le codage en dur impose de modifier le code source du programme chaque fois que les données d'entrée ou le format souhaité changent, alors qu'il pourrait être plus pratique pour l'utilisateur final de modifier ce détail par un moyen extérieur au programme.

Le codage en dur est souvent nécessaire, mais peut aussi être considéré comme un anti-patron. Les programmeurs n'ont peut-être pas encore mis au point de solution d'interface utilisateur dynamique pour l'utilisateur final, mais doivent tout de même livrer la fonctionnalité ou publier le programme. Cela est généralement temporaire, mais résout, à court terme, la pression liée à la livraison du code. Plus tard, le codage souple est mis en place pour permettre à un utilisateur de transmettre des paramètres qui donnent à l'utilisateur final un moyen de modifier les résultats ou l'issue.

Le terme « codé en dur » a d'abord été utilisé par analogie avec le câblage en dur des circuits, et visait à exprimer le manque de souplesse qui résulte de son usage dans la conception et l'implémentation logicielles. Dans le contexte des environnements de développement collaboratifs extensibles à l'exécution tels que les MUD, le codage en dur désigne aussi le développement du moteur central du système chargé des tâches de bas niveau et de l'exécution des scripts, par opposition au codage souple qui consiste à développer les scripts de haut niveau interprétés par le système à l'exécution, avec des valeurs provenant de sources externes, telles que les fichiers texte, les fichiers INI, les macros de préprocesseur, les constantes externes, les bases de données, les arguments de ligne de commande, les réponses de serveur HTTP, les fichiers de configuration et les saisies utilisateur. Dans ce cas, le terme n'est pas péjoratif et désigne le développement en général, plutôt que l'intégration spécifique de données de sortie.

Coder en dur des identifiants est un moyen répandu de créer une porte dérobée. Les identifiants codés en dur ne sont généralement pas visibles dans les fichiers de configuration ni dans la sortie des commandes d'énumération de comptes, et ne peuvent être facilement modifiés ou contournés par les utilisateurs. Si elle est découverte, un utilisateur peut désactiver une telle porte dérobée en modifiant et en reconstruisant le programme à partir de son code source (si la source est disponible publiquement), en le décompilant, ou en faisant de la rétro-ingénierie du logiciel, en éditant directement le code binaire du programme, ou en instaurant un contrôle d'intégrité (tel que des signatures numériques, des protections anti-altération et anti-triche) pour empêcher l'accès inattendu, mais de telles actions sont souvent interdites par un contrat de licence utilisateur final.

À titre de mesure de gestion des droits numériques (DRM), les développeurs de logiciels peuvent coder en dur un numéro de série unique directement dans un programme. Il est aussi courant de coder en dur une clé publique, créant ainsi un DRM pour lequel il est impossible de créer un keygen.

À l'inverse, un cracker de logiciels peut coder en dur un numéro de série valide dans le programme, ou même empêcher l'exécutable de le demander à l'utilisateur, permettant ainsi de redistribuer des copies non autorisées sans avoir à saisir de numéro valide, partageant donc la même clé pour chaque copie, si elle a été codée en dur.

Si un programme Windows est conçu en supposant qu'il est toujours installé dans C:\Program Files\Appname et que quelqu'un tente de l'installer sur un autre lecteur pour des raisons d'espace ou d'organisation, il peut échouer à s'installer ou à s'exécuter après l'installation. Ce problème peut ne pas être repéré au cours du processus de test, car l'utilisateur moyen installe sur le lecteur et le répertoire par défaut, et les tests peuvent ne pas inclure l'option de changer le répertoire d'installation. Il est toutefois conseillé aux programmeurs et aux développeurs de ne pas figer le chemin d'installation d'un programme, car le chemin d'installation par défaut dépend du système d'exploitation, de sa version et des décisions de l'administrateur système. Par exemple, de nombreuses installations de Microsoft Windows utilisent le lecteur C: comme disque dur principal, mais cela n'est pas garanti.

Un problème similaire existait avec les microprocesseurs des premiers ordinateurs, qui commençaient leur exécution à une adresse fixe en mémoire.

Certains programmes « protégés contre la copie » recherchent un fichier particulier sur une disquette ou une clé USB au démarrage afin de vérifier qu'il ne s'agit pas de copies non autorisées. Si l'ordinateur est remplacé par une machine plus récente, dépourvue de lecteur de disquette, le programme qui en a besoin ne peut plus être exécuté puisque la disquette ne peut pas être insérée.

Ce dernier exemple montre pourquoi le codage en dur peut se révéler peu pratique même lorsqu'il semble, sur le moment, devoir fonctionner parfaitement. Dans les années 1980 et 1990, la grande majorité des PC étaient équipés d'au moins un lecteur de disquette, mais les lecteurs de disquette sont ensuite tombés en désuétude. Un programme codé en dur de cette manière il y a 15 ans pourrait rencontrer des problèmes s'il n'est pas mis à jour.

Certains systèmes d'exploitation Windows possèdent ce que l'on appelle des dossiers spéciaux qui organisent logiquement les fichiers sur le disque dur. Le codage en dur peut y poser des problèmes :

Certains programmes Windows codent en dur le chemin du profil vers des emplacements définis par le développeur, tels que C:\Documents and Settings\Username. C'est le chemin de la grande majorité des installations de Windows 2000 et ultérieures, mais cela provoquerait une erreur si le profil est stocké sur un réseau ou déplacé d'une autre manière. La bonne façon de l'obtenir est d'appeler la fonction GetUserProfileDirectory ou de résoudre la variable d'environnement %userprofile%. Une autre supposition que font souvent les développeurs est que le profil se trouve sur un disque dur local.

Certains programmes Windows codent en dur le chemin de My Documents sous la forme ProfilePath\My Documents. Ces programmes fonctionneraient sur des machines exécutant la version anglaise, mais sur les versions localisées de Windows, ce dossier porte normalement un nom différent. Par exemple, dans les versions italiennes, le dossier My Documents est nommé Documenti. My Documents peut également avoir été déplacé à l'aide de la redirection de dossiers dans la stratégie de groupe sous Windows 2000 ou version ultérieure. La bonne façon de l'obtenir est d'appeler la fonction SHGetFolderPath.

Une référence indirecte, telle qu'une variable dans le programme appelée « FileName », pourrait être développée en accédant à une fenêtre de dialogue « parcourir pour trouver un fichier », et le code du programme n'aurait pas à être modifié si le fichier était déplacé.

Le codage en dur est particulièrement problématique lors de la préparation du logiciel en vue de sa traduction dans d'autres langues.

Dans de nombreux cas, une même valeur codée en dur, telle que la taille d'un tableau, peut apparaître plusieurs fois dans le code source d'un programme. Il s'agirait alors d'un nombre magique. Cela peut couramment provoquer un bogue si certaines occurrences de la valeur sont modifiées, mais pas toutes. Un tel bogue est difficile à trouver et peut rester longtemps dans le programme. Un problème similaire peut survenir si la même valeur codée en dur est utilisée pour plusieurs valeurs de paramètres, par exemple un tableau de 6 éléments et une longueur minimale de chaîne d'entrée de 6. Un programmeur peut modifier par erreur toutes les occurrences de la valeur (souvent à l'aide de la fonction de recherche-remplacement d'un éditeur) sans vérifier dans le code comment chaque occurrence est utilisée. On évite ces deux situations en définissant des constantes, qui associent des noms aux valeurs, et en utilisant les noms des constantes pour chaque occurrence dans le code.

Un cas important de codage en dur survient lorsque des chaînes de caractères sont placées directement dans le fichier, ce qui oblige les traducteurs à éditer le code source pour traduire un programme. (Il existe un outil appelé gettext qui permet de laisser les chaînes dans les fichiers, tout en laissant les traducteurs les traduire sans modifier le code source ; il « décode en dur » de fait les chaînes.)

Dans les concours de programmation tels que les Olympiades internationales d'informatique, les participants doivent écrire un programme suivant un schéma d'entrée-sortie précis conformément aux exigences des questions.

Dans de rares cas où le nombre d'entrées possibles est suffisamment petit, un participant pourrait envisager une approche qui associe toutes les entrées possibles à leurs sorties correctes. Ce programme serait considéré comme une solution codée en dur, par opposition à une solution algorithmique (même si le programme codé en dur peut être le résultat d'un programme algorithmique).

Le codage souple est un terme de programmation informatique qui désigne l'obtention d'une valeur ou d'une fonction à partir d'une ressource externe, telle que les fichiers texte, les fichiers INI, les macros de préprocesseur, les constantes externes, les fichiers de configuration, les arguments de ligne de commande, les bases de données, les saisies utilisateur et les réponses de serveur HTTP. C'est l'opposé du codage en dur, qui désigne le fait de coder les valeurs et les fonctions dans le code source.

Éviter de coder en dur des valeurs fréquemment modifiées est une bonne pratique de programmation. Les utilisateurs du logiciel devraient pouvoir l'adapter à leurs besoins, dans la limite du raisonnable, sans avoir à éditer le code source du programme. De même, les programmeurs soigneux évitent les nombres magiques dans leur code afin d'en améliorer la lisibilité et de faciliter la maintenance. Ces pratiques ne sont généralement pas désignées par le terme codage souple.

Le terme est généralement employé lorsque le codage souple devient un anti-patron. Abstraire trop de valeurs et de fonctionnalités peut introduire davantage de complexité et de problèmes de maintenance que n'en occasionnerait la modification du code lorsque c'est nécessaire. Le codage souple, en ce sens, a fait l'objet d'un article sur The Daily WTF.

À l'extrême, les programmes à codage souple développent leurs propres langages de script, mal conçus et mal implémentés, ainsi que des fichiers de configuration qui requièrent des compétences de programmation avancées pour être édités. Cela peut conduire à produire des utilitaires destinés à faciliter la configuration du programme d'origine, et ces utilitaires finissent souvent par être eux-mêmes à codage souple.

La frontière entre une configurabilité appropriée et un codage souple problématique varie selon le style et la nature d'un programme. Les programmes à code source fermé doivent être très configurables, car l'utilisateur final n'a pas accès au code source pour y apporter des modifications. Les logiciels internes et les logiciels à diffusion limitée peuvent être moins configurables, car distribuer des copies modifiées est plus simple. Les applications web sur mesure gagnent souvent à n'avoir qu'une configurabilité limitée, car modifier les scripts n'est généralement pas plus difficile que de modifier un fichier de configuration.

Pour éviter le codage souple, évaluez l'intérêt, pour l'utilisateur final, de toute flexibilité supplémentaire que vous offrez, et comparez-le à l'accroissement de la complexité et aux coûts de maintenance continue qu'implique cette configurabilité ajoutée.

Il existe plusieurs patrons de conception légitimes pour obtenir la flexibilité que le codage souple cherche à fournir. Une application nécessitant plus de flexibilité qu'il n'est approprié pour un fichier de configuration peut tirer parti de l'intégration d'un langage de script. Dans de nombreux cas, la conception appropriée est un langage dédié intégré à un langage de script établi. Une autre approche consiste à déplacer la majeure partie des fonctionnalités d'une application dans une bibliothèque, en fournissant une API pour écrire rapidement des applications connexes.