Qué convención de nomenclatura usar para los parámetros de función de C #

Prefijar parámetros o variables locales con un guión bajo no es muy idiomático en C #, no es muy fácil de leer y no se usa con frecuencia (aunque es legal, por lo tanto, si lo desea, puede hacerlo).

El mejor nombre para el parámetro y la variable es un nombre descriptivo. Debe pensar por qué está cambiando el tipo, cuál es la razón del reparto. Entonces deberías poder llegar a 2 nombres diferentes. P.ej. Si pasaste a una "persona" y lo convertiste en un "cliente", entonces podrías usar persona y / o cliente en los nombres de las variables, tal vez.

Si realmente no puede pensar en 2 nombres diferentes, usaría "como" en el nombre ( Hace unos días hubo una pregunta en este sitio acerca de esto ). P.ej. usaría "myParaAsDerived" para la variable local.

Si fuera posible, no usaría esto, me gustaría reflexionar sobre el problema que está resolviendo y qué nombres significativos podrían usarse, pero si todo lo demás falla, esto es bastante legible.

En primer lugar usando

void MyFunc(BaseClass _myPara)
{
} 

¡Está claramente mal! ¡Como muchos de los estándares de codificación de C # usan un prefijo "_" en todos los nombres de campo ! Su código debe ser fácil de entender por otro programador, por lo que el código no debe escribirse de forma que engañe a muchos programadores de C #.

Dados todos los beneficios de los métodos pequeños, personalmente no veo ninguna necesidad de una convención de nomenclatura para separar las variables locales de los parámetros. Si sus métodos tienen tantos parámetros y variables locales que no puede saber qué está pasando sin una convención de nomenclatura, tiene mayores problemas. (Esto está bien cubierto en el Clean Code Book , un libro de Java pero todavía lo encontré de gran beneficio como programador de C #)

Si desea prefijarlos con algo, debe usar p_ para el parámetro: en general, creo que probablemente molestaría a mucha gente si hiciera esto. PERO sea consistente, no lo haga en un solo lugar solo porque necesita dos nombres diferentes para las variables que desea dar el mismo nombre.

Una buena regla general con nombres de variables es como;

• Si solo tiene un tipo de nombre de objeto por su función:

  var builder = new PizzaBuilder();
  

• Si tiene más de un nombre por su función y especialidad:

  var pizzaBuilder = new PizzaBuilder();
  var milkShakeBuilder = new MilkShakeBuilder();
  

Las convenciones de nomenclatura de C # te tendrán:

• Uso de PascalCasing para métodos, propiedades públicas y nombres de clase
• Uso de IPascalCasing (observe la I al comienzo) para los nombres de interfaz
• Uso de camelCasing para parámetros de método y variables locales
• Uso de _underscoredCamelCasing para campos privados de toda la clase

Y por favor mantente alejado de la notación húngara. Es inútil y no se adhiere a las convenciones de C #.

El subrayado en la denominación de variables puede ser innecesario, ya que tenemos la palabra clave "this" para hacer referencia a las variables de nivel de clase específicamente. Si desea obtener más información sobre las convenciones de nombres de variables de los expertos, le sugiero que eche un vistazo al infame documento titulado "Reglas de Ottinger para nombres de variables y clases" por Tim Ottinger, un artículo respaldado por el mentor de codificación limpio Robert C. Martin .

Ottinger declara que su código debe permanecer lo más humanamente legible posible, como una prosa bien escrita, así que ...

public void Function(string p_Parameter1, string p_Parameter2)

... sería más legible como ...

public void Function(string parameter1, string parameter2)

... donde parámetro1 y 2 son nombres descriptivos para las variables correspondientes.

Aquí está el enlace, definitivamente vale la pena verlo: Enlace

Creo en el sufijo de parámetros: cadena s_, int i_, etc

También creo que los nombres de parm deben ser cortos y genéricos como sea posible.

Ahora por las razones:

• En la función, no desea modificar el parámetro de ninguna manera, si necesita una versión modificada, cree una nueva variable para pegarla. La denominación de parms con un sufijo se asegurará de que no se los asigne. Si estás prestando atención.
• Las excepciones a esta regla se producen cuando el parámetro es ref o out. Aunque todavía uso el sufijo en esos.
• ¿Por qué nombres genéricos cortos? Debería estar documentando su función para saber qué es realmente en el sentido descriptivo. Por lo tanto, una vez que esté fuera del camino, usar genéricos cortos es útil cuando está creando grupos de funciones similares, o recortar un cuerpo de función para transportarlo a otra función como punto de inicio para la modificación.
• El beneficio real de los nombres genéricos es que no tiene que recordar lo que llamó ese parámetro en la mayoría de los casos. Usted sabe que está obteniendo una cadena, así que es s_, etc. y no tiene que preguntarse si es 'nombre de archivo' o si fue 'filepath' o si fue 'ruta completa', es la única cadena, por lo que es _ '.

Todo tiene ventajas y desventajas, y si usas algo o no dependerá mucho de cómo se adapte a tu estilo actual.