Estilo de código para métodos privados en C#

Question

Acabo de descubrir que parece un patrón común utilizar UpperFirstLetterPascalCase() para métodos privados. Para mí, considero que esto es completamente incoherente con las reglas de nomenclatura de campos y variables de instancias privadas y también me resulta difícil de leer/depurar.

Me gustaría preguntar, ¿por qué utilizar una primera letra superior para los métodos podría ser una mejor opción que una primera inferior doThis()? Solo por curiosidad ...

Answer 1

No es realmente mejor o peor. Es simplemente la convención.

Answer 2

Todos los nombres de métodos en C# comienzan con una letra mayúscula por convención. Todos los nombres de propiedades también lo hacen. Solo los campos privados, las variables locales y los parámetros de los métodos comienzan con una letra minúscula (AFAIR).

Es una convención, por lo que pedir un "por qué" está un poco fuera de lugar. Probablemente sea como preguntar "¿Por qué la convención de codificación Java prefiere letras minúsculas para todo menos para las clases?" - las respuestas a tales preguntas suelen ser "Porque alguien, en alguna parte, decidió que sería una buena idea hacerlo" . El resto entonces simplemente es historia o convención y usted lo sigue o no (en cuyo caso le dificulta la vida a las personas que leen su código).

ETA: Como se ha dicho en un comentario ya, (en mi humilde opinión) la respuesta a la pregunta »por qué« por lo general conduce a lo que los diseñadores del lenguaje (o las personas que vienen con la convención) que se consideran aspectos importantes a? estar cubierto por la convención. En Java, es claramente un caso de clases visualmente diferentes (PascalCase), variables/campos (camelCase) y propiedades (get ~()/set ~()). Para .NET obviamente existía la necesidad de separar las clases e interfaces de inmediato (algo que también considero muy agradable tener) y distinguir visualmente el acceso a la propiedad (PascalCase) y el campo (camelCase).

Por lo general, en tales escenarios todas las cosas no consideradas inicialmente importantes para la convención son cortas en obviedad.

Answer 3

Tal es la convención de nomenclatura para .NET, y esa es la convención que siguen todas las bibliotecas .NET estándar. No hay nada que requiera que siga esta convención en su propio código, pero generalmente es mejor seguir los estándares del idioma en el que está trabajando. Personalmente, prefiero lowerCamelCase a UpperCamelCase, pero sigo usando el estilo .NET recomendado al escribir Cª#.

Privado Las variables miembro se suelen indicar con un guion bajo y una minúscula en la primera letra, p. Ej. _privateMember. Los métodos privados siguen las mismas convenciones que los métodos públicos.

Answer 4

Lo principal que gana de esta convención es la capacidad de distinguir fácilmente las llamadas al método de la variable miembro y el acceso a los parámetros.

Como otros han mencionado, que no es necesariamente mejor - es sólo la disyuntiva de que los desarrolladores de .NET han elegido y pegado con: por lo que es más fácil decir lo que estás accediendo en lugar de hacer que sea más fácil diga el nivel de accesibilidad de lo que está accediendo.

Las propiedades lo hacen especialmente valioso, lo que puede explicar por qué echó raíces en el mundo .NET. Poder distinguir la diferencia entre un acceso de propiedad y un acceso de variable miembro puede ser crítico.Los usuarios de propiedades pueden estar calculando o validando valores, y llamar a la variable miembro relacionada por error (o viceversa) crea errores sutiles.

Answer 5

Sólo me gustaría señalar que, si bien sí, PascalCase es la convención en .NET para el privado, así como los métodos públicos, teniendo en cuenta que estamos hablando de métodos privados aquí, no veo ningún daño en la elección de qué te queda mejor. Quiero decir, usted tiene un punto que parece que hay mérito en diferenciar entre los métodos públicos privados. Mientras que lo que está exponiendo al cliente (si está desarrollando una biblioteca) es consistente con la convención, está satisfecho. Solo elabora con los miembros del equipo cómo vas a hacer las cosas internamente.

Answer 6

Creo que debes elegir tus convenciones de nombres de acuerdo con tus gustos/disgustos, sin importar cómo lo hagan otras personas (a menos que el tipo que pague el cheque diga lo contrario).

Lo importante es que una vez que elija una convención, ¡quédese con ella!

Answer 7

Una diferencia que podría pensar es que distingue entre variables y métodos de delegado locales, aunque probablemente esta no sea la intención. Con los IDEs modernos, en general es bastante fácil averiguar si la llamada es pública o privada, en cualquier caso. Mi opinión sobre las convenciones de nomenclatura para propiedades, campos y variables es que permiten distinguir diferentes formas de la misma 'propiedad' de esta manera:

public class MyClass 
{ 
    private int _property; 

    public int Property 
    { 
     get { return _property; } 
    } 

    public MyClass(int property) 
    { 
     _property = property; 
    } 
} 

con métodos que no tienen la misma ambigüedad en la que desea usar el mismo nombre para diferentes formas del mismo concepto (distintas de las sobrecargas, que no requieren diferentes envolturas para distinguirlas).

Answer 8

Tiendo a mirar la firma completa del método cuando leo el código. Si no veo un modificador de acceso (public, protected, internal, protected internal) entonces puedo asumir que es private (aunque trato de ser explícito sobre los modificadores de acceso).

Usted es libre de adoptar su propia convención, especialmente para los métodos private.

Hay un caso en el que puedo pensar donde la convención es útil: cuando se usa C#'s implicit method group conversion syntax. Considere esta clase, Test:

public class Test { 
    public event EventHandler MyEvent; 
} 

Si creo un método privado para el manejo de MyEvent y agregar el controlador mediante la conversión del grupo método implícito C# 's sintaxis de un nombre de método minúscula podría confundirse con un campo o variable:

Test test = new Test(); 
test.MyEvent += myEventHandler; 

private void myEventHandler(object sender, EventArgs e) { 
    ... 
}