Conventions de nommage de type C, _t ou ALLCAPS

Je me suis toujours demandé s’il y avait des problèmes de nommage, comme quand utiliser ALLCAPS pour un type et quand append _t (et quand ne pas utiliser quoi que ce soit?). Je sais qu’à l’époque K & R avait publié de nombreux documents sur l’utilisation de C, mais je n’ai rien trouvé à ce sujet.

Parmi les types de librairies standard C, _t semble être dominante

 time_t clock_t uint32_t size_t sig_atomic_t ... 

, par opposition à FILE , va_list ou struct tm . Existe-t-il des règles à ce sujet ou est-ce complètement arbitraire? Microsoft utilise toujours les noms de type dans ALLCAPS dans leur API Windows, qui semble au moins plus cohérente que la bibliothèque C, franchement …

En réalité, selon le standard POSIX, tous les noms de types se terminant par _t sont réservés, comme défini ici :

Les noms qui se terminent par ‘_t’ sont réservés pour des noms de type supplémentaires.

Je m’efforcerais de minimiser votre utilisation de typedef . Utilisez le mot struct clé struct pour les structures et utilisez uniquement typedef lorsque vous définissez (a) un type opaque pouvant être implémenté de quelque manière que ce soit, ou (b) définissez un alias pour un type arithmétique que vous souhaiterez peut-être modifier ultérieurement ou ultérieurement. différentes configurations (par exemple si vous voulez pouvoir choisir float ou double ).

Dans tous les cas, n’utilisez pas ALL CAPS car c’est affreusement laid, et n’utilisez pas _t car il est réservé par POSIX. Cela n’a probablement pas d’importance si vous préfixez vos noms de types de manière appropriée, mais alors le _t sur la fin est simplement une laideur inutile et une non-portabilité gratuite. Il suffit de les préfixer ainsi: foo_scalar (où foo est le nom de votre bibliothèque / module).

C’est totalement arbitraire – différents rédacteurs / normes de bibliothèque utilisent différentes conventions (ou aucune convention du tout). Choisissez-en un pour votre code et soyez cohérent.

Il n’y en a pas puisque les types que vous avez mentionnés peuvent avoir été accumulés au fil des années à travers différentes normes (telles que POSIX) et différentes implémentations dominantes. Un exemple xstr est xstr et xstr que les deux sont des macros en minuscule. Cependant, assurez-vous d’avoir lu la FAQ 12.9 et vous devriez être prêt à partir.

Vous pouvez également consulter la section Identificateurs réservés dans la norme. Voici ce que dit ma copie de N1570:

7.1.3 Identifiants réservés

1 Chaque en-tête déclare ou définit tous les identifiants répertoriés dans sa sous-clause associée et éventuellement identifie ou définit les identifiants répertoriés dans sa sous-clause d’instructions de bibliothèque future associée et les identifiants toujours réservés à une utilisation ou à une utilisation en tant qu’identificateurs de scope de fichier. – Tous les identificateurs commençant par un trait de soulignement et une lettre majuscule ou un autre trait de soulignement sont toujours réservés pour toute utilisation. – Tous les identificateurs commençant par un trait de soulignement sont toujours réservés à une utilisation en tant qu’identificateurs avec une étendue de fichier dans les espaces de nom de balise et ordinaire.

– Chaque nom de macro dans l’un des sous-paragraphes suivants (y compris les instructions futures de la bibliothèque) est réservé pour être utilisé comme spécifié si l’un des en-têtes associés est inclus. sauf indication explicite contraire (voir 7.1.4).

– Tous les identifiants avec une liaison externe dans l’un des sous-paragraphes suivants (y compris les instructions de la future bibliothèque) et errno sont toujours réservés à une utilisation en tant qu’identifiants avec une liaison externe.184)

– Chaque identifiant avec une étendue de fichier répertoriée dans l’un des sous-paragraphes suivants (y compris les instructions futures de la bibliothèque) est réservé à l’utilisation en tant que nom de macro et en tant qu’identifiant avec une étendue de fichier dans le même espace de nom si l’un des en-têtes associés est inclus.

2 Aucun autre identifiant n’est réservé. Si le programme déclare ou définit un identifiant dans un contexte dans lequel il est réservé (autre que celui autorisé par 7.1.4), ou définit un identifiant réservé en tant que nom de macro, le comportement est indéfini.

3 Si le programme supprime (avec #undef) toute définition de macro d’un identificateur du premier groupe répertorié ci-dessus, le comportement est indéfini.

La convention la plus courante consiste à utiliser des majuscules (uniquement) pour les macros (que ce soit un type ou non).

Les ALLCAPS sont généralement utilisés (pas universellement) pour les macros et, selon mon expérience, sont rarement utilisés pour les définitions de type. Les conventions les plus courantes que j’ai vues pour les noms de type sont soit le suffixe LeadingUpperMixedCase, soit le suffixe _t (ce que d’autres ont déjà signalé peut provoquer des conflits avec POSIX).

ALL CAPS sont le plus souvent utilisés pour les constantes et / ou les macros. Je ne l’ai pas rencontré pour des types nulle part ailleurs que dans l’API Windows et je ne le recommanderais pas.

uint8_t etc. est un moyen assez courant de nommer des types, comme le montre la norme. Une autre manière courante est comme This avec seulement la première lettre majuscule.