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

Hay situaciones en las que un nombre pasado en Parámetro se convertirá en un nuevo tipo, pero el nombre del objeto Pasado debe seguir siendo similar. Para el caso de los atributos de clase, podemos usar este operador, pero ¿qué pasa con la variable local en las funciones? Qué convención de codificación se usa ampliamente.

ejemplo,

void MyFunc(BaseClass myPara)
{
  DerivedClass _mypara = (BaseClass)myPara;
}

o por el contrario

void MyFunc(BaseClass _myPara)
{
  DerivedClass mypara = (BaseClass)_myPara;
}

o cualquier otra convención

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 que puede hacerlo si lo desea).

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 el motivo del reparto. Entonces deberías poder encontrar 2 nombres diferentes. Por ejemplo, si pasó a una "persona" y la convirtió en un "cliente", entonces podría usar persona y / o cliente en los nombres de las variables.

Si realmente no puede pensar en 2 nombres diferentes, usaría "como" en el nombre ( hubo una pregunta en este sitio hace unos días sobre esto ). Por ejemplo, usaría "myParaAsDerived" para la variable local.

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

Primero usando

void MyFunc(BaseClass _myPara)
{
} 

Está claramente equivocado! ¡Como muchos estándares de codificación de C # usan un prefijo "_" en todos los nombres de campo ! El código debe ser fácil de entender por otro programador, por lo que el código no debe escribirse de manera que pueda confundir 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á sucediendo 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 ponerles un prefijo con algo, entonces debe usar el p_parámetro: en general, supongo que probablemente molestaría a mucha gente si hiciera esto. PERO sea coherente, no lo haga solo en un lugar solo porque necesita dos nombres diferentes para las variables que desea dar al mismo nombre.

Una buena regla general con nombres variables es como;

• Si solo tiene un tipo de objeto, llámelo 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 permitirán:

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

Y por favor, manténgase alejado de la notación húngara. No tiene sentido y no se adhiere a las convenciones de C #.

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

Ottinger afirma que su código debe permanecer lo más 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 echarle un vistazo: 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. El nombramiento de parms con un sufijo asegurará que no los asigne si está pagando atención.
• Las excepciones a esta regla vienen cuando el parm es ref o out. Aunque todavía uso el sufijo en esos.
• ¿Por qué nombres genéricos cortos? Debería documentar su función para saber qué es realmente s_ en sentido descriptivo. Entonces, con eso fuera del camino, el uso de genéricos cortos es útil cuando se crean grupos de funciones similares, o se recorta un cuerpo de función para transportarlo a otra función como punto de partida 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. Sabe que está obteniendo una cadena, por lo que es s_, etc., y no tiene que preguntarse si es 'nombre de archivo' o si fue 'ruta de archivo' o fue 'ruta completa', es la única cadena por lo que es 's_'.

Todo tiene compensaciones, y si usa algo o no dependerá mucho de cómo se adapte a su estilo actual.