¿Cuáles son los beneficios de prefijar nombres de parámetros de función con p *?

A menudo veo proyectos (en proyectos y equipos de Java que usan Eclipse) con los parámetros de función prefijo p.

Por ejemplo

public void filter (Result pResult) ...

Personalmente, no veo ningún beneficio en esto, pero me gustaría saber cuál es el razonamiento. La mejor explicación que he escuchado hasta ahora es que es para distinguir el nombre de campos con nombres idénticos. Tengo mis problemas con esa explicación pero puedo entender el punto.

Las prácticas de agregar prefijos significativos a los símbolos, como la notación húngara bien publicitada , se remontan a los tiempos en que los IDE no existían o eran demasiado primitivos. Hoy, al encontrar un punto de declaración a un clic del mouse, no tiene sentido estropear la parte más preciosa del nombre, sus primeras letras, asignando un prefijo común.

Como sospecha, es para evitar colisiones de nombres entre el nombre del parámetro y los nombres de miembros o variables locales. Las variables miembro a veces reciben un prefijo por la misma razón (por ejemplo, m_result). Personalmente, prefiero usar el thisprefijo para las variables miembro si hay una colisión de nombres. Está integrado en el idioma y todos ya saben lo que significa.

Solo uso un prefijo de parámetro cuando el parámetro está destinado a ser asignado a una variable miembro, como un constructor o un setter.

Paint (newColor) {
  color = newColor;
}

Para mí, encuentro que usar un nombre de variable diferente es más obvio que usar el prefijo "this".

Para otras situaciones, evito usar un parámetro que pueda confundirse fácilmente con una variable miembro.

Si un método o clase es tan grande que es difícil saber qué significan las variables, la solución real es dividirlo en métodos / clases más pequeños. El uso de prefijos es una solución de curita que aborda el problema subyacente.

Si establece un estándar para usar 'p' como prefijo con el nombre de cada parámetro del método, puede reconocer fácilmente los parámetros del método en el resto del cuerpo del método.

Le ahorra tiempo encontrar los parámetros del método. Puede depurar su código fácilmente.

Corto: esta práctica hace que el código sea más difícil de leer.

Largo: argumentaré que es una mala práctica que solo se usa para apoyar otras malas prácticas. Examinemos un par de razones por las cuales usar tales prefijos podría considerarse útil:

• Evitar colisiones en nombres de variables

  • ¿Sus nombres de parámetros expresan exactamente cuáles son los parámetros? Si tiene un parámetro y un campo de clase que son "exactamente iguales", no necesita un parámetro.
  • En este caso, solo tiene sentido usar prefijos para constructores de clases como el nuevo prefijo * descrito en la respuesta de Aaron. También podría ser útil para los métodos de establecimiento, p. Ej.

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

• Los métodos toman muchos parámetros, declaran muchas variables y fácilmente podríamos olvidar cuál es un parámetro.

  • Como se describió anteriormente, el problema radica en la cantidad de variables.
  • El programa probablemente no está bien estructurado. Compruebe si todas las variables son "independientes", tal vez deberían organizarse en estructuras o clases. Tal vez todo el cálculo o proceso debería estar envuelto en una clase separada solo para operar en tal número de variables.
  • Incluso si necesita ese número de variables, deben usar nombres significativos y el prefijo se interpone entre usted y la parte significativa.
• Los métodos son muy largos y debe usar prefijos para realizar un seguimiento de lo que es un parámetro.
  • El problema radica en la longitud de los métodos: si un programa está bien escrito, siempre debe ver el encabezado del método y todo su cuerpo en una sola pantalla.
  • Intenta dividir el método en bloques más pequeños.

Excepto en algunos casos específicos, agregar prefijos de parámetros solo ayuda con los síntomas y no resuelve problemas reales.

Soy fanático de iParam para los parámetros de entrada y oParam para los parámetros de salida. Diría cParam para el cambio, pero eso no es aceptable