234 votes

Pourquoi l'astérisque est-il placé avant le nom de la variable, plutôt qu'après le type ?

Pourquoi la plupart des programmeurs C nomment-ils les variables comme ceci :

int *myVariable;

plutôt que comme ça :

int* myVariable;

Les deux sont valides. Il me semble que l'astérisque est une partie du type, et non une partie du nom de la variable. Quelqu'un peut-il expliquer cette logique ?

1 votes

Le second style semble plus intuitif en général, mais le premier est la solution pour éviter les bogues liés aux types dans le code. Si vous êtes vraiment attaché à ce dernier style, vous pouvez toujours opter pour typedefs mais cela ajoutera une complexité inutile, à mon avis.

301voto

luiscubal Points 8870

Ils sont EXACTEMENT équivalents. Cependant, en

int *myVariable, myVariable2;

Il semble évident que maVariable est de type int* alors que maVariable2 est de type int . Sur

int* myVariable, myVariable2;

il peut sembler évident que les deux sont de type int* mais ce n'est pas correct car myVariable2 a un type int .

Par conséquent, le premier style de programmation est plus intuitif.

155 votes

Peut-être, mais je ne mélangerais pas les types dans une même déclaration.

23 votes

@BobbyShaftoe D'accord. Même après avoir lu tous les arguments ici, je reste avec int* someVar pour des projets personnels. C'est plus logique.

38 votes

@Kupiakos Cela n'a de sens que si vous apprenez la syntaxe de déclaration du C basée sur le principe "declarations follow use". Les déclarations utilisent exactement la même syntaxe que l'utilisation des variables de même type. Lorsque vous déclarez un tableau d'ints, cela ne ressemble pas à : int[10] x . Ce n'est tout simplement pas la syntaxe du C. La grammaire est explicitement analysée comme : int (*x) et non comme (int *) x Par conséquent, placer l'astérisque à gauche est tout simplement trompeur et repose sur une mauvaise compréhension de la syntaxe de déclaration C.

148voto

biozinc Points 2760

Si vous regardez d'une autre manière, *myVariable est de type int ce qui est logique.

6 votes

C'est mon explication préférée, et elle fonctionne bien parce qu'elle explique les bizarreries de déclaration du C en général - même la syntaxe des pointeurs de fonction, qui est dégoûtante et épouvantable.

14 votes

C'est assez intéressant, car vous pouvez imaginer qu'il n'y a pas de types de pointeurs réels. Il n'y a que des variables qui, lorsqu'elles sont référencées ou déréférencées de manière appropriée, vous donnent l'un des types primitifs.

1 votes

En fait, '*myVariable' peut être de type NULL. Pour aggraver les choses, il pourrait simplement s'agir d'un emplacement mémoire aléatoire.

41voto

ojrac Points 6897

Parce que le * dans cette ligne se lie plus étroitement à la variable qu'au type :

int* varA, varB; // This is misleading

Comme @Lundin le souligne ci-dessous, la contrainte ajoute encore plus de subtilités à prendre en compte. Vous pouvez entièrement contourner cela en déclarant une variable par ligne, ce qui n'est jamais ambigu :

int* varA;
int varB;

L'équilibre entre un code clair et un code concis est difficile à trouver - une douzaine de lignes redondantes de int a; n'est pas bon non plus. Néanmoins, j'opte par défaut pour une déclaration par ligne et je me préoccupe de la combinaison du code plus tard.

4 votes

Le premier exemple trompeur est à mes yeux une erreur de conception. Si je pouvais, je supprimerais entièrement cette façon de déclarer en C, et je ferais en sorte que les deux soient de type int*.

1 votes

"le * se lie plus étroitement à la variable qu'au type" C'est un argument naïf. Considérons int *const a, b; . Où se situe la * " liaison " ? Le type de a es int* const Comment pouvez-vous dire que l'astérisque appartient à la variable alors qu'il fait partie du type lui-même ?

1 votes

Spécifique à la question, ou couvrant tous les cas : choisissez-en un. Je ferai une note, mais c'est un autre bon argument en faveur de ma dernière suggestion : une déclaration par ligne réduit les possibilités de se tromper.

20voto

Sutch Points 81

Je vais prendre des risques et dire que il y a une réponse directe à cette question tant pour les déclarations de variables que pour les types de paramètres et de retours, à savoir que l'astérisque doit figurer à côté du nom : int *myVariable; . Pour comprendre pourquoi, regardez comment vous déclarez d'autres types de symboles en C :

int my_function(int arg); pour une fonction ;

float my_array[3] pour un tableau.

Le modèle général, appelé la déclaration suit l'utilisation En effet, le type d'un symbole est divisé en deux parties : la partie avant le nom et la partie après le nom. autour de le nom, et ces parties autour du nom imitent la syntaxe que vous utiliseriez pour obtenir une valeur du type sur la gauche :

int a_return_value = my_function(729);

float an_element = my_array[2];

et : int copy_of_value = *myVariable; .

Le C++ jette un pavé dans la mare avec les références, car la syntaxe à l'endroit où vous utilisez les références est identique à celle des types de valeur, on pourrait donc dire que le C++ adopte une approche différente de celle du C. D'un autre côté, le C++ conserve le même comportement que le C dans le cas des pointeurs, les références sont donc vraiment à part à cet égard.

11voto

macbirdie Points 9417

C'est juste une question de préférence.

Lorsque vous lisez le code, il est plus facile de faire la distinction entre les variables et les pointeurs dans le second cas, mais cela peut prêter à confusion lorsque vous mettez à la fois des variables et des pointeurs d'un type commun sur une seule ligne (ce qui est souvent déconseillé par les directives du projet, car cela diminue la lisibilité).

Je préfère déclarer les pointeurs avec leur signe correspondant à côté du nom du type, par exemple

int* pMyPointer;

3 votes

La question porte sur le point C, où il n'y a pas de référence.

0 votes

Merci de l'avoir signalé, même si la question ne portait pas sur les pointeurs ou les références, mais sur le formatage du code, en gros.

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