Quels sont les avantages de préfixer les noms de paramètres de fonction avec p *?

Je vois souvent des projets (dans des projets Java et des équipes utilisant Eclipse) qui préfixent des paramètres de fonction avec p.

Par exemple

public void filter (Result pResult) ...

Personnellement, je ne vois aucun avantage à cela, mais j'aimerais savoir quel est le raisonnement. La meilleure explication que j'ai entendu à ce jour est qu'il s'agit de distinguer le nom de champs nommés identiques. J'ai des problèmes avec cette explication mais je peux comprendre le point.

Les pratiques consistant à ajouter des préfixes significatifs aux symboles, comme la notation hongroise bien connue, remontent à l'époque où les IDE n'existaient pas ou étaient trop primitifs. Aujourd'hui, quand trouver un point de déclaration est à un clic de souris, il ne sert à rien de gâcher la partie la plus précieuse du nom, ses premières lettres, en attribuant un préfixe commun.

Comme vous le soupçonnez, c'est pour éviter les collisions de noms entre le nom du paramètre et les noms de membre ou de variable locale. Les variables membres reçoivent parfois un préfixe pour la même raison (par exemple, m_result). Personnellement, je préfère simplement utiliser le thispréfixe pour les variables membres en cas de collision de noms. Il est intégré à la langue et tout le monde sait déjà ce que cela signifie.

J'utilise uniquement un préfixe de paramètre lorsque le paramètre est destiné à être affecté à une variable membre, comme un constructeur ou un setter.

Paint (newColor) {
  color = newColor;
}

Pour moi, je trouve que l'utilisation d'un nom de variable différent est plus évidente que d'utiliser le préfixe "this".

Pour les autres situations, j'évite d'utiliser un paramètre qui pourrait être facilement confondu avec une variable membre.

Si une méthode ou une classe est si grande qu'il est difficile de dire ce que signifient les variables, la vraie solution est de la diviser en méthodes / classes plus petites. L'utilisation de préfixes est une solution de pansement qui résout le problème sous-jacent.

Si vous créez une norme pour utiliser «p» comme préfixe avec chaque nom de paramètre de méthode, vous pouvez facilement reconnaître les paramètres de méthode dans le reste du corps de la méthode.

Cela vous fait gagner du temps pour trouver les paramètres de la méthode. Vous pouvez déboguer votre code facilement.

Court - Cette pratique rend le code plus difficile à lire.

Long - Je dirai que c'est une mauvaise pratique uniquement utilisée pour soutenir d'autres mauvaises pratiques. Examinons quelques raisons pour lesquelles l'utilisation de tels préfixes pourrait être considérée comme utile:

• Éviter les collisions dans les noms de variables

  • Vos noms de paramètres expriment-ils exactement ce que sont les paramètres? Si vous avez un paramètre et un champ de classe qui sont "exactement les mêmes", vous n'avez pas besoin d'un paramètre.
  • Dans ce cas, il est logique d'utiliser des préfixes pour les constructeurs de classes comme le nouveau préfixe * décrit dans la réponse d'Aaron. Il peut également être utile pour les méthodes de définition, par exemple

  public void setHeight(int newHeight) { this.height = newHeight; }

• Les méthodes prennent beaucoup de paramètres, déclarent beaucoup de variables et nous pourrions facilement oublier lequel est un paramètre.

  • Comme décrit ci-dessus - le problème réside dans le nombre de variables.
  • Le programme n'est probablement pas bien structuré. Vérifiez si toutes les variables sont "indépendantes" - elles devraient peut-être être organisées en structures ou en classes. Peut-être que l'ensemble du calcul ou du processus devrait être emballé dans une classe distincte juste pour fonctionner sur un tel nombre de variables.
  • Même si vous aviez besoin d'un tel nombre de variables - elles devraient utiliser des noms significatifs et le préfixe se trouve entre vous et la partie significative.
• Les méthodes sont très longues et vous devez utiliser des préfixes pour suivre ce qu'est un paramètre.
  • Le problème réside dans la longueur des méthodes - Si un programme est bien écrit, vous devriez toujours voir l'en-tête de la méthode et son corps entier sur un seul écran.
  • Essayez de diviser la méthode en blocs plus petits.

Sauf dans certains cas spécifiques, l'ajout de préfixes de paramètres n'aide que les symptômes et ne résout pas les problèmes réels.

Je suis un fan d'iParam pour les paramètres d'entrée et d'oParam pour les paramètres de sortie. Je dirais cParam pour le changement, mais ce n'est pas acceptable