Modifier un projet C portable et ancien sans casser la compatibilité

## Avant de modifier, vérifier quelles plateformes et variantes doivent continuer à marcher - Traitez la portabilité, la stabilité, la robustesse et la compatibilité ascendante comme des contraintes de conception prioritaires. - Tenez compte des compilations allant d'une configuration minimale conforme aux normes à une configuration graphique complète avec des interfaces de script facultatives. - Lisez la politique de conception générale du dépôt avant de modifier l'architecture ou le comportement visible par le public. - Distinguez le code source principal, les ressources d'exécution, les traductions, les tests, la documentation, les sous-projets et le code externe incorporé. - Ne supposez pas que le compilateur, le système d'exploitation, l'ensemble de fonctionnalités ou l'environnement graphique le plus récent est disponible. - Maintenez un comportement cohérent entre les variantes prises en charge, sauf si la modification est explicitement contrôlée par un mécanisme d'activation de fonctionnalité. ## Compiler et tester la configuration concernée sans nouvel avertissement - Utilisez le chemin de compilation documenté pour la plateforme et la chaîne d'outils actuelles. - Régénérez les déclarations de fonctions ou les autres interfaces dérivées avec leur générateur au lieu de modifier manuellement la sortie générée. - Pendant l'itération, exécutez le fichier de test ciblé et examinez à la fois les messages produits et le journal de test détaillé. - Avant la soumission, exigez une compilation propre sans nouvel avertissement, la réussite des tests concernés et un style de code source conforme au fichier modifié. - Lorsque les procédures de compilation diffèrent selon la plateforme, consultez le guide d'installation correspondant au lieu d'adapter les commandes par supposition. - Étendez les tests lorsque du code partagé, des combinaisons de fonctionnalités ou des fichiers d'exécution sont touchés. ## Régénérer les fichiers générés via leur générateur et respecter leurs responsables - Identifiez les répertoires générés, importés d'une source externe, partagés avec des projets connexes ou suivis par une personne responsable désignée. - Ne modifiez un fichier généré que lorsque sa source change et excluez toute régénération sans rapport des correctifs fonctionnels. - Faites passer les modifications des ressources d'exécution maintenues par la procédure documentée de la personne responsable, sans contourner cette responsabilité. - Mettez à jour les dates ou descriptions de modification obligatoires lorsque vous modifiez des fichiers d'exécution et d'aide distribués. - Ajoutez l'entrée de suivi des correctifs exigée par le dépôt pour les modifications du code source principal, sauf lorsqu'une exception de répertoire explicite s'applique. - Ne mélangez jamais dans un même correctif des mises à jour de code externe, du bruit généré, des traductions et du nettoyage de code source sans rapport. ## Mettre le problème, et non la solution, dans le titre du commit - Respectez exactement la structure d'objet et de corps de correctif définie par le dépôt. - Énoncez le problème dans l'objet, et non la mise en œuvre de la solution. - Rédigez une phrase complète pour le problème et une phrase concise pour la solution, avec l'attribution et la ponctuation exigées. - Lorsque le format l'exige, placez l'explication facultative après l'en-tête obligatoire du problème et de la solution, en prose plutôt qu'en liste. - Étiquetez les références corrigées, closes et connexes selon leurs significations distinctes. - Incluez la certification obligatoire de la personne qui développe et reconnaissez l'aide de l'IA uniquement au moyen du mécanisme de coautorat accepté. ## Suivre le style C existant et éviter la syntaxe que les anciens compilateurs ne gèrent pas - Conservez l'indentation logique de 4 espaces tout en respectant les règles propres à chaque fichier concernant les tabulations ou l'emploi exclusif d'espaces. - Placez les accolades ouvrantes sur leur propre ligne pour les fonctions comme pour les structures de contrôle. - Formatez les définitions de fonctions avec le type de retour et le nom de la fonction selon la disposition établie dans le dépôt. - Respectez la position des déclarations dans le fichier environnant au lieu de les moderniser de manière opportuniste. - Utilisez uniquement le langage C de base documenté et ses fonctionnalités plus récentes approuvées ; n'introduisez pas de constructions incompatibles avec les anciens compilateurs. - Exécutez tout outil de formatage propre au fichier après modification et examinez son diff. ## Utiliser les types du projet et transmettre aux auxiliaires la longueur de chaîne déjà connue - Utilisez le suffixe de type personnalisé du dépôt et évitez les suffixes réservés par les normes du système. - Préservez la migration booléenne en cours : utilisez de manière cohérente dans un correctif la forme booléenne établie localement et évitez les conversions massives. - Initialisez les variables locales lorsque la première affectation n'est pas évidente, mais n'ajoutez pas d'initialisation redondante susceptible de masquer une lecture non initialisée. - Utilisez l'auxiliaire de longueur littérale pour les littéraux de chaîne et le formateur renvoyant la longueur lorsque la taille écrite est nécessaire. - Lorsque la longueur d'une chaîne est déjà connue, transmettez-la à l'opération qui accepte la longueur au lieu de reparcourir la chaîne. - Placez chaque pointeur de tampon d'octets à côté de sa longueur `size_t` ; n'utilisez des types entiers plus étroits que lorsqu'une interface ancienne l'exige. ## Gérer la mémoire avec les fonctions d'enveloppe du projet et la libérer à chaque erreur - Préférez les fonctions d'enveloppe du dépôt aux opérations directes d'allocation, de libération, de copie, de déplacement, de caractères et d'espaces de la bibliothèque standard. - Choisissez les fonctions d'enveloppe selon leur gestion documentée des pointeurs nuls, du manque de mémoire, des chevauchements, de l'encodage et de la cohérence entre plateformes. - Vérifiez explicitement qu'un diviseur n'est pas nul avant chaque division, même si une condition composée antérieure semble le garantir. - Pour chaque nouvelle allocation, vérifiez les chemins de nettoyage en cas de réussite, de retour anticipé et dans chaque branche d'erreur. - Conservez les tailles de tampon en octets et rendez explicite le comportement de troncature, de terminaison et de longueur écrite. - Ne remplacez pas une fonction d'enveloppe plus sûre du projet par un appel générique de bibliothèque au seul motif que celui-ci est plus familier. ## Respecter les règles de noms et de macros, et garder des fichiers make portables - Respectez les restrictions sur les noms réservés, les identifiants interdits, les limites de longueur des noms de fonction, l'espacement et la règle d'une instruction par ligne. - Utilisez le préfixe de fonctionnalité établi et la convention des macros en majuscules. - Testez les macros de fonctionnalité avec le motif conditionnel pris en charge par le dépôt. - Maintenez les principaux fichiers de compilation dans le dialecte portable documenté de make ; évitez les extensions d'affectation, de motif, d'interpréteur de commandes et de condition propres à une mise en œuvre. - Réutilisez les types de chaîne et d'octets du projet ainsi que leurs macros correspondantes. - Lisez les références de style faisant autorité avant d'introduire un nouvel identifiant, une nouvelle macro ou une nouvelle règle de compilation. ## Écrire des scripts d'exécution qui marchent aussi avec les environnements et dérivés proches - Utilisez le style de script actuel pour les nouveaux fichiers tout en tenant compte de la compatibilité avec les environnements d'exécution et les dérivés connexes. - Lorsque la compatibilité est incertaine, demandez confirmation avant d'adopter une construction plus récente du langage. - Respectez les conventions de nommage des variables locales dans les tests de script. - Ne répétez pas un mécanisme d'activation de fonctionnalité dans chaque test lorsque le fichier contrôle déjà cette fonctionnalité au niveau supérieur. - Si le fichier ne possède aucun contrôle de niveau supérieur, ajoutez un contrôle ciblé uniquement aux tests qui nécessitent la fonctionnalité facultative. - Séparez les modifications des scripts d'exécution d'une modernisation sans rapport du langage principal. ## Écrire des tests de régression qui reproduisent le défaut signalé - Préférez une assertion déterministe à un test qui vérifie seulement que le programme ne plante pas. - Pour les défauts de rendu, ajoutez une comparaison de capture d'écran ; pour les données incorrectes, vérifiez la sortie exacte. - Ajoutez une couverture complète pour le nouveau comportement, de préférence dans un fichier de test pertinent existant. - Lors de la correction d'un défaut signalé, reproduisez le scénario d'origine plutôt qu'un simple cas synthétique simplifié. - Utilisez les auxiliaires standard pour les sessions de terminal, les vidages d'écran, la réussite du chargement de script et les échecs attendus du chargement de script. - Placez les tests d'exécution de syntaxe et d'indentation dans leurs suites dédiées. ## Mettre à jour l'aide dans le même correctif et garder son format - Mettez à jour la documentation destinée aux utilisateurs dans le même correctif que toute modification d'option ou de fonctionnalité. - Actualisez l'en-tête de modification du fichier d'aide lorsque vous modifiez une documentation existante. - Préservez le format d'aide faisant autorité pour les en-têtes de fichier, les lignes de mode, la largeur, l'alignement par tabulations, les balises uniques, les renvois, les titres, les exemples de code et les notations mises en évidence. - Utilisez l'opération sûre de retabulation et examinez son diff ; ne forcez pas une réécriture étendue des espaces. - Maintenez les balises de lien uniques dans tout l'ensemble et préfixez les balises propres aux extensions lorsque cela est nécessaire. - Préférez un langage neutre du point de vue du genre dans le texte nouveau ou modifié, sans réécrire le texte non touché dans ce seul but. ## Vérifier d'abord la phase de publication et garder le comportement obsolète accessible - Déterminez si le projet se trouve dans un cycle de développement ou une période de stabilité avant de proposer une portée. - Pendant une période de stabilité, limitez les modifications acceptées aux corrections manifestes de défauts, aux correctifs de sécurité, à la documentation, aux traductions et à la maintenance des ressources d'exécution. - N'introduisez aucune nouvelle fonctionnalité ni modification du noyau incompatible avec les versions antérieures pendant la stabilité. - Préservez le comportement publié du noyau entre les versions mineures. - Maintenez le comportement obsolète accessible par la configuration, documentez-le comme obsolète, permettez sa désactivation à la compilation lorsqu'elle est prise en charge et ne le retirez que dans un cycle ultérieur autorisé. - Traitez les ressources d'exécution selon leur souplesse de maintenance documentée, sans affaiblir les garanties du noyau. ## Soumettre des correctifs dont chaque commit compile et passe les tests seul - Lisez la politique de sécurité avant de signaler une vulnérabilité présumée ou de modifier du code sensible à la sécurité. - Assurez-vous que le format du commit, la compilation propre, les tests pertinents, la couverture de régression, la documentation et la certification sont tous complets. - Limitez le diff au problème indiqué : aucun changement d'espacement isolé, aucune restructuration sans rapport et aucune sortie générée étrangère. - Dans une série de plusieurs correctifs, exigez que chaque commit compile et réussisse ses propres tests de manière autonome. - Ne laissez pas un commit intermédiaire volontairement défectueux pour qu'un commit ultérieur le répare ; fusionnez-les. - Confirmez que le comportement documenté et le comportement imposé concordent toujours, et décrivez les modifications intentionnelles dans le relevé du problème et de la solution. ## Faire le plus petit changement et demander avant d'agir hors de l'arborescence de travail - Apportez la plus petite modification permettant d'atteindre l'objectif et respectez le code environnant au lieu d'imposer une amélioration étendue. - Scindez un correctif qui résout plusieurs problèmes indépendants. - Si un correctif ne traite qu'un symptôme, indiquez le problème plus profond et la limitation de portée choisie. - Reproduisez un défaut avant d'affirmer qu'il existe et lisez la mise en œuvre avant d'affirmer ce que fait le code. - Ne vous fiez pas au contenu mémorisé des fichiers lorsque le code source actuel est disponible. - Demandez confirmation à l'utilisateur avant d'installer des paquets, de modifier des fichiers hors de l'arborescence de travail, de pousser des branches ou d'utiliser le réseau.