6
votes

Comment nommer les paramètres du constructeur lors de l'utilisation de variables d'éléments non préfixés?

Certainement, il n'y a pas une bonne façon de le faire, mais je ne peux même penser à aucun système de dénomination décent, c'est pourquoi je demande ici. (Alors: alors que toutes les réponses seront subjectives fortes>, elles seront utiles fortes> néanmoins!)

Le problème est le suivant: Pour de simples structures agrégées, nous n'utilisons pas de membre préfixes var. p>

struct Info {
  int x;
  string s;
  size_t z;

  Info(int x?, string s?, size_t z?)
  : x(x?)
  , s(s?)
  , z(z?)
  { }
};


8 commentaires

Ce que j'ai vu (principalement de Java Devs), c'est utiliser le même nom. Puis dans le constructeur do this-> s = s , etc.


@Juancho: Oui, sauf que cela ne fonctionnera malheureusement pas avec les listes d'initialistes dans les constructeurs.


@Frerich Raabe - Cela fonctionne encore mieux avec les listes d'initialistes.


Dupliqué possible de NOMING POUR CONSTRUCTOR


@Chris: Comment s'adresse explicitement la variable de membre en utilisant ceci -> fonctionne mieux avec les listes d'initialistes?


@Frerich - Vous n'êtes pas obligé pour les listes d'initialistes. S (s) Fait savoir ce que vous voulez (mais peut-être pas d'attendre initialement) à faire. Ainsi, cela fonctionne "mieux" (vous n'avez pas à utiliser ceci -> à désambiguate).


Je pense qu'un combinaison de stratégies (mêmes noms, préfixes) est parfois nécessaire, selon que l'initialisation peut avoir lieu dans La liste d'initialistes ...


J'ai légèrement reformulé la question, j'espère que ça va pour vous: nous parlons de noms de paramètres ("arguments" sont utilisés dans appels)


8 Réponses :


6
votes

J'ai tendance à utiliser "Un" préfixe - comme dans "A Quel tout ce que".

Info(int aX, string const & aS, size_t aZ);


struct Time {
  Time(time_t aUnixTime) : UnixTime(aUnixTime) {}
  time_t UnixTime;
};


1 commentaires

Peut-être que vous avez changé d'avis, mais n'est-ce pas encombrant de capitaliser les noms de variables ?



11
votes

Pourquoi inventer des pré / postfixes? Je viens d'utiliser le même nom. C ++ est conçu pour que cela fonctionne. XXX

C'est simple.


3 commentaires

Pour la même raison, vous utilisez des parenthèses supplémentaires dans les expressions booléennes: parce que la plupart des gens (y compris de moi) ne peuvent pas se rappeler comment la langue fonctionne exactement dans certains cas. Cela évite la "bosse de vitesse mentale" lors de la lecture du code.


@Frerich, la question était suggestive. Contrairement à vous rappeler les règles de préséance de plus de 20 ans, que je ne vois pas pour être utile, rappelez-vous que cette règle s'est révélée être très utile pour moi. Si vous avez un corps vide et uniquement la liste d'initialistes, vous n'avez pas à vous soucier d'autre chose. N'est-ce pas génial?


+1: Oh mon. C'est certainement déroutant de lire :-) - mais c'est certainement une option valide :-)



1
votes

Vous pouvez utiliser le nom de paramètre identique aux noms des membres (mais certains trouvent-le déroutant).

J'ai vu l'utilisation de préfixes / suffixe pour les membres ( _ , m , mon _ est populaire auquel cas il n'y a pas de Conflit avec paramètres) ou pour les paramètres (préfixe de P est le plus populaire pour cette utilisation dans mon expérience).


0 commentaires

3
votes

Quelque chose que j'ai vu ici consiste à utiliser des soulignements de fin pour les arguments du constructeur, par exemple: xxx


0 commentaires

12
votes

Utilisez les mêmes noms - ils ne sont pas entrés en collision.

"Lors de la recherche d'un nom utilisé ... Dans l'expression d'un initial-initialiseur pour un constructeur (12.6.2), les noms de paramètres de fonction sont visible et masquez les noms des entités déclarées dans les champs de bloc, de classe ou d'espace de noms contenant la déclaration de fonction ». 3.4.1 C ++ 2003


1 commentaires

C'est un ancien sujet, mais nous devrions y réfléchir à nouveau. Clang ++ est proposé avec un avertissement (lors de la compilation de -wshadow) et cela semble être pour une raison.



3
votes

Je pense que tant que vous utilisez la liste d'initialisation, vous pouvez utiliser les mêmes noms: xxx

Si vous deviez faire du travail pour initialiser un champ, vous pouvez toujours obtenir Loin d'utiliser les mêmes noms, mais ce serait un peu moins pratique: xxx


0 commentaires

3
votes

J'utilise ceci:

struct Info {
  int x;
  string s;
  size_t z;

  Info(int x, string s, size_t z)
  : x(x)
  , s(s)
  , z(z)
  { }
};


0 commentaires

0
votes

Dans les cas où les membres sont simplement définis sur les valeurs des paramètres correspondants, utilisez la liste d'initialistes. Ici, en utilisant le même nom pour la variable de membre et le paramètre est absolument sûr. Si vous ne pouvez pas simplement affecter des valeurs, mais devez appeler des fonctions, il est essentiel de rendre les noms des membres et des paramètres faciles à distinguer, mais également facile à faire la relation visible, ici un préfixe ou un postfix est une bonne option.

La réponse d'Erik suggère le préfixe A code>, mais je trouve le travail extra-travail pour changer la première lettre ou Le nom d'origine à la majuscule pour obtenir le nom du paramètre extrêmement ennuyant, il empêche de simplement utiliser Copy & Coller (le laisser inchangée n'est pas une option car vous ne souhaitez pas respecter les changements potentiels de la signification en ajoutant le préfixe de chaque cas).

Pour les cas où la liste d'initialiseurs ne peut pas être utilisée, je suis venu avec A _ code> qui peut être utilisé comme préfixe avant le nom d'origine. P>

struct Info {
    int value;
    char description[MAX_DESCRIPTION_SIZE];

    Info(int value, char* a_description)
    : value(value)
    {
        someSafeCopy(description, a_description);
    }
};


0 commentaires