Quelles sont les conventions de dénomination couramment utilisées en C ? Je sais qu'il en existe au moins deux :
- GNU / linux / K&R avec lower_case_functions
- ? 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).
0 votes
@Jeff V - La réponse hargneuse est "garder la trace des variables globales en notant qu'elles n'ont pas été définies comme variables locales dans le corps de la fonction", mais je pense que cette réponse a un certain mérite. Si vous avez tellement de variables locales que vous ne pouvez pas dire quelles variables sont locales et quelles variables sont globales, votre fonction est probablement trop grande, et à moins que vous ayez une bonne raison de ne pas le faire (espace/mémoire/efficacité), vous devriez la décomposer.
3 votes
@Chris Lutz, je suis d'accord, de tout cœur. Dans la mesure du possible, les variables doivent être maintenues à la portée la plus étroite. Notez qu'il y a en fait trois portées dont nous discutons : locale à une fonction, locale à un module (aucun lien externe à la variable) et les globales avec lien externe. Il est courant d'avoir des variables "globales à un module" dans les systèmes embarqués. Par conséquent, il faut prendre soin d'identifier les variables globales avec lien externe afin de les réduire au minimum et de comprendre les interactions entre les modules. C'est là que le préfixe "g_" est utile.
0 votes
Je suis d'accord pour utiliser une partie de la notation g_. C'est utile pour savoir si un élément auquel on fait référence est global ou ailleurs.
91 votes
J'aime préfixer les variables globales par //.
0 votes
@plafer J'ai failli perdre la tête en lisant votre commentaire, lol. En tant que vimmer, je préfère préfixer les globaux avec "ggVGd", car ils sont généralement accompagnés d'autres problèmes de conception.