192 votes

Quelles sont les conventions de dénomination les plus courantes en C ?

Quelles sont les conventions de dénomination couramment utilisées en C ? Je sais qu'il en existe au moins deux :

  1. GNU / linux / K&R avec lower_case_functions
  2. ? nom ? avec fonctions UpperCaseFoo

Je ne parle ici que de C. La plupart de nos projets sont de petits systèmes embarqués dans lesquels nous utilisons le C.

Voici celui que je prévois d'utiliser pour mon prochain projet :


C Convention de dénomination

Struct              TitleCase
Struct Members      lower_case or lowerCase

Enum                ETitleCase
Enum Members        ALL_CAPS or lowerCase

Public functions    pfx_TitleCase (pfx = two or three letter module prefix)
Private functions   TitleCase
Trivial variables   i,x,n,f etc...
Local variables     lower_case or lowerCase
Global variables    g_lowerCase or g_lower_case (searchable by g_ prefix)

12 votes

Je n'imposerais pas le préfixe "g_" sur les variables globales ; j'imposerais des noms significatifs (donc client_locale et non cl_lc comme nom de variable globale). Le C classique n'utilise pas la casse camel ; j'ai écrit du code en casse camel en C, et ça fait bizarre (donc je ne le fais plus comme ça). Cela dit, ce n'est pas faux - et la cohérence est plus importante que la convention utilisée. Évitez les typedefs qui encapsulent les pointeurs de structure ; considérez le standard C - 'FILE *' est écrit ainsi, pas FILE_PTR.

5 votes

@Jonathan Leffler, quel est le problème avec g_ pour signifier les globaux ? Dans les systèmes embarqués, j'ai déjà eu des problèmes où il était difficile de repérer les dépendances entre modules par le biais des variables globales et des extern g_somevar. Personnellement, je pense que c'est généralement une mauvaise idée, mais ce genre de chose est généralement fait pour des raisons de performance. Par exemple, un drapeau global qui est activé par une interruption indiquant que les données sont prêtes.

2 votes

Pour ce que cela vaut, cette convention de dénomination a été principalement reprise des conventions API de PalmOS. De plus, elle est similaire à la convention utilisée dans le livre de O'Reilly : "Programming Embedded Systems with C and GNU Development Tools". Personnellement, j'aime la TitleCase dans les noms de fonctions. J'envisageais d'utiliser la minusculeCamelCase dans les fonctions de liaison internes (que j'ai appelées privées dans ma question).

180voto

axel_c Points 4025

La chose la plus importante ici est la cohérence. Cela dit, je suis la convention de codage de GTK+, qui peut être résumée comme suit :

  1. Toutes les macros et constantes sont en majuscules : MAX_BUFFER_SIZE , TRACKING_ID_PREFIX .
  2. Noms de structures et typedef's en majuscules : GtkWidget , TrackingOrder .
  3. Fonctions qui opèrent sur des structs : style C classique : gtk_widget_show() , tracking_order_process() .
  4. Pointeurs : rien d'extraordinaire ici : GtkWidget *foo , TrackingOrder *bar .
  5. Variables globales : n'utilisez pas de variables globales. Elles sont diaboliques.
  6. Des fonctions qui sont là, mais ne devraient pas être appelées directement, ou ont des utilisations obscures, ou quoi que ce soit : un ou plusieurs underscores au début : _refrobnicate_data_tables() , _destroy_cache() .

43voto

SeanRamey Points 302

Vous savez, j'aime garder les choses simples, mais claires... Donc voilà ce que j'utilise, en C :

  • Variables triviales : i,n,c etc... (Une seule lettre. Si une lettre n'est pas claire, alors faites-en une Variable Locale)
  • Variables locales : camelCase
  • Variables globales : g_camelCase
  • Variables constantes : ALL_CAPS
  • Variables pointeurs : ajouter un p_ au préfixe. Pour les variables globales, ce serait gp_var pour les variables locales p_var pour les variables constantes p_VAR . Si des pointeurs lointains sont utilisés, utilisez un fp_ au lieu de p_ .
  • Structs : ModulePascalCase (Module = nom complet du module, ou une abréviation de 2 ou 3 lettres, mais toujours dans la langue du module) PascalCase .)
  • Variables membres de la structure : camelCase
  • Enums : ModulePascalCase
  • Valeurs de l'Enum : ALL_CAPS
  • Fonctions publiques : ModulePascalCase
  • Fonctions privées : PascalCase
  • Macros : PascalCase

J'ai typedef mes structs, mais j'utilise le même nom pour pour le tag et le typedef. La balise n'est pas destinée à être utilisée couramment. Il est préférable d'utiliser le typedef. Je déclare également le typedef dans l'en-tête du module public pour l'encapsulation et pour pouvoir utiliser le nom du typedef dans la définition.

Full struct Exemple :

typdef struct UtilsExampleStruct UtilsExampleStruct;
struct UtilsExampleStruct{
    int var;
    UtilsExampleStruct *p_link;
};

37voto

unwind Points 181987

Les "pointeurs de structure" ne sont pas des entités qui nécessitent une clause de convention de dénomination pour les couvrir. Ils sont simplement struct WhatEver * . Ne cachez pas le fait qu'il y a un pointeur impliqué avec un typage intelligent et "évident". Cela ne sert à rien, est plus long à taper, et détruit l'équilibre entre déclaration et accès.

39 votes

+1 pour le truc "ne pas cacher les pointeurs" - même si cette réponse ne répond pas (encore) au reste de la question.

2 votes

@unwind, je suis plutôt d'accord. Cependant, parfois un pointeur n'est pas destiné à être déréférencé de manière externe et il s'agit plus d'une poignée pour le consommateur que d'un pointeur réel vers une structure qu'il utilisera. C'est pour cela que j'ai laissé le TitleCasePtr. typedef struct { fields } MyStruct, *MyStructPtr ;

0 votes

Je supprime le TitleCasePtr, il détourne l'attention de la question réelle.

19voto

cletus Points 276888

Tout d'abord, le C n'a pas de fonctions publiques/privées/virtuelles. C'est le C++ et il a des conventions différentes. En C, on a typiquement :

  • Constantes dans ALL_CAPS
  • Des underscores pour délimiter les mots dans les structures ou les noms de fonctions, on ne voit presque jamais de majuscules en C ;
  • Les structs, typedefs, unions, membres (d'unions et de structs) et valeurs d'enum sont typiquement en minuscules (dans mon expérience) plutôt que la convention C++/Java/C#/etc de faire de la première lettre une majuscule mais je suppose que c'est possible en C aussi.

Le C++ est plus complexe. J'ai vu un vrai mélange ici. La casse pour les noms de classe ou les minuscules et les exposants (la casse est plus courante dans mon expérience). Les structures sont rarement utilisées (et généralement parce qu'une bibliothèque les requiert, sinon vous utiliseriez des classes).

12voto

Luc Fourestier Points 119

Codage en C#, java, C, C++ et objective C En même temps, j'ai adopté une convention de dénomination très simple et claire pour me simplifier la vie.

Tout d'abord, il s'appuie sur la puissance des IDEs modernes (comme eclipse, Xcode...), avec la possibilité d'obtenir des informations rapides par survol ou ctrl-clic... En acceptant cela, j'ai supprimé l'utilisation de tout préfixe, suffixe et autres marqueurs qui sont simplement donnés par l'IDE.

Ensuite, la convention :

  • Tout nom DOIT être une phrase lisible expliquant ce que vous avez. Comme "ceci est ma convention".
  • Puis, 4 méthodes pour obtenir une convention à partir d'une phrase :
    1. C'EST_MA_CONVENTION pour les macros, les membres de l'enum
    2. ThisIsMyConvention pour le nom du fichier, le nom de l'objet (classe, struct, enum, union...), le nom de la fonction, le nom de la méthode, le typedef
    3. c'est_ma_convention les variables globales et locales,
      paramètres, éléments struct et union
    4. thisismyconvention [facultatif] variables très locales et temporaires (comme l'index d'une boucle for())

Et c'est tout.

Il donne

class MyClass {
    enum TheEnumeration {
        FIRST_ELEMENT,
        SECOND_ELEMENT,
    }

    int class_variable;

    int MyMethod(int first_param, int second_parameter) {
        int local_variable;
        TheEnumeration local_enum;
        for(int myindex=0, myindex<class_variable, myindex++) {
             localEnum = FIRST_ELEMENT;
        }
    }
}

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X