Mon style personnel de programmation en C à la fin de 2023

• L’auteur présente son style personnel de programmation en C à la fin de 2023, en mettant en avant les changements importants et les améliorations apportées à ses techniques.
• Il a commencé à utiliser des noms courts pour les types primitifs, estimant que cela améliore la clarté et rend les revues de code plus agréables.
• Il donne des exemples de nouvelles conventions de nommage pour les types primitifs, comme typedef uint8_t u8; et typedef char16_t c16;.
• Il a adopté les minuscules pour les macros qui ressemblent à des fonctions, car elles sont plus faciles à lire et n’ont pas les mêmes problèmes d’espace de noms que d’autres définitions de macros.
• Il a cessé d’utiliser const, car cela ne joue selon lui aucun rôle concret dans l’optimisation et ne permet pas de détecter les erreurs. Il considère que son inclusion dans le C était une erreur.
• Il rejette les chaînes terminées par un caractère nul et adopte un type de chaîne de base, qu’il juge plus productif.
• Il préfère retourner des structures plutôt que d’utiliser des paramètres de sortie, ce qui permet de renvoyer efficacement plusieurs valeurs.
• Il préfère initialiser par affectation plutôt que via des initialiseurs, à l’exception de l’initialiseur traditionnel de mise à zéro.
• Il préfère __attribute à __attribute__, jugeant cette dernière forme excessive et inutile.
• Pour la programmation système Win32, il recommande d’écrire manuellement les prototypes à l’aide de types personnalisés afin de réduire les temps de compilation, d’assainir l’espace de noms et d’interfacer plus proprement le programme.
• Il fournit des exemples de style de code dans de petits programmes comme wordhist.c et asmint.c.

[GN⁺]

Discussion Hacker News

• Article sur le style personnel de l’auteur pour coder en C à la fin de 2023.
• Certains commentateurs ne sont pas d’accord avec la manière dont l’auteur définit ses propres types, estimant que cela peut dérouter les personnes déjà familières avec les types du C.
• L’usage de ALL_CAPS pour les constantes fait débat, certains affirmant que cela devrait être réservé aux macros du préprocesseur.
• L’auteur est critiqué pour son utilisation de tailles signées, certains commentateurs estimant que les tailles non signées sont moins sujettes aux défauts.
• Le fait que l’auteur s’écarte des conventions existantes, par exemple en utilisant u8 ou i32 au lieu de uint8_t ou int32_t, semble pouvoir semer la confusion chez d’autres développeurs.
• Certains commentateurs estiment que l’approche de l’auteur semble davantage centrée sur des préférences personnelles que sur l’objectif de rendre le code C facile à manipuler pour tout le monde.
• Des questions sont soulevées sur l’usage par l’auteur de booléens sur 32 bits, certains affirmant que cela gaspille de la mémoire sans avantage clair.
• Des inquiétudes sont exprimées au sujet de l’hypothèse de l’auteur selon laquelle float fait 32 bits et double 64 bits, ce qui pourrait potentiellement poser problème.
• Le concept de « style personnel » en programmation semble pouvoir être problématique, puisque programmer est au fond une activité sociale, y compris pour les projets hobby.
• Certains commentateurs ne partagent pas la préférence de l’auteur pour les structs plutôt que pour les out-parameters, affirmant que cela complique la composition des fonctions et entraîne une prolifération des types.
• Cet article suscite une discussion sur les différents styles et approches de programmation, et met en évidence la diversité des opinions dans la communauté du développement.