c# - sirve - ¿Cómo nombrarías estas propiedades, clases, parámetros y campos relacionados en.NET?

que es set en programacion

Question

A menudo me parece que quiero escribir un código como este en C #, pero no me siento cómodo con los nombres de los identificadores:

public class Car
{
private Engine engine;
public Engine Engine
{
get
{
return engine;
}
set
{
engine = value;
}
}
public Car(Engine engine)
{
this.engine = engine;
}
}

Aquí tenemos cuatro cosas diferentes llamadas "motor":

• Engine la clase. El motor parece un buen nombre natural.
• Engine la propiedad pública. Parece tonto llamarlo MyEngine o TheCarsEngine.
• engine el campo privado que respalda la propiedad. Algunos esquemas de nombres recomendarán m_engine o _engine , pero otros dicen que se deben evitar todos los prefijos.
• engine el nombre del parámetro en el constructor. He visto esquemas de nombres que recomiendan poner un guion bajo en todos los parámetros, por ejemplo, _engine . Realmente no me gusta esto, ya que el parámetro es visible para los llamantes a través de Intellisense.

Las cosas particulares que no me gustan del código tal como está escrito son las siguientes:

• Si cambias el nombre del parámetro en el constructor pero pierdes el uso en el cuerpo del constructor, obtienes un error sutil que el compilador probablemente no podrá detectar.
• Intellisense tiene un mal hábito de autocompletar lo incorrecto para usted, y a veces no se dará cuenta de que ha cambiado el caso. Nuevamente obtendrá un error sutil si el cuerpo del constructor termina accidentalmente this.engine = Engine;

Parece que cada nombre es apropiado de forma aislada, pero juntos son malos. Algo tiene que ceder, pero ¿qué? Prefiero cambiar el campo privado, ya que no es visible para los usuarios, por lo que generalmente terminaré con m_engine , que resuelve algunos problemas, pero introduce un prefijo y no impide que Intellisense cambie de engine a Engine .

¿Cómo cambiarías el nombre de estos cuatro elementos? ¿Por qué?

(Nota: me doy cuenta de que la propiedad en este ejemplo podría ser una propiedad automática. Simplemente no quería que el ejemplo se complicara excesivamente).

Ver también: ¿Soy inmoral por usar un nombre de variable que difiera de su tipo solo por caso?

Answer 1

En este caso, los nombraría exactamente como están en el ejemplo.

Esto se debe a que la nomenclatura es clara en cuanto a qué datos contiene y / o se usará para cada elemento.

Lo único que cambiaría por C # 3 es usar una propiedad automática que elimine la variable local.

Answer 2

Está bien dejarlos como están separados de una pequeña cosa. En intellisense, no es inmediatamente obvio si un elemento es un parámetro, miembro local o privado, ya que todos tienen el mismo símbolo (cubo azul). Sin embargo, si mueve el cursor a un elemento en particular, la información sobre herramientas le indica cuál de estos es.

Como ayuda visual, puede prefijar a su miembro privado con un guión bajo, _engine para que sea inmediatamente obvio que es un miembro privado sin tener que mover el cursor. Esta es una convención que uso y es el único nombre que cambiaría en su ejemplo.

Answer 3

Me gusta esto:

public class Car
{
#region fields
private Engine _engine;
#endregion
#region public properties
public Engine Engine { get { return _engine; } set { _engine = value; } }
#endregion
#region constructors
public Car(Engine engine)
{
_engine = engine;
}
#endregion
}

Lamentablemente, la hoja de estilo de código SO está elidiendo mis líneas en blanco, lo que lo hace un poco más claro y fácil de leer. Las directivas de la región, que utilizamos en todos los códigos de producción, ayudan a evitar confusiones. El prefijo de subrayado es el único prefijo que uso (bueno, excepto I en las interfaces, pero todos lo hacen) pero lo uso religiosamente, por lo que nunca confundimos los campos y los locales (como en el contstructor). No veo ningún problema importante al tener el nombre de propiedad y el nombre de tipo iguales (en VS, el resaltado diferenciará entre ellos). Es solo un problema si intenta usar un miembro estático o un método del tipo, y si lo hace, tendrá que alias o referirse a él explícitamente (es decir, MyNamespace.VehicleParts.Engine.StaticMethod() ).

Me parece legible, pero todo es muy subjetivo.

Answer 4

No me gusta la notación húngara: m_foo , etc. Estoy usando el estilo camello: engine, myEngine, myBigEngine .

Escribiría exageradamente como tú.

En MSDN, vi un comentario: use public Car(Engine e) - me refiero al parámetro de entrada de nombre, algo más como variable local. Pero yo no hago eso.

Answer 5

Para los miembros privados siempre prefijo con un guion bajo:

private Engine engine;

se convierte en:

private Engine _engine;

Cada vez que veo m_ , me m_ el estómago.

Answer 6

Prefiero usar algún prefijo (uso ''_'') para campos privados, de lo contrario, tienen el mismo aspecto que los parámetros y los locales. Aparte de eso, uso un enfoque similar para nombrar como lo haces aquí, aunque Engine podría ser un poco genérico, dependiendo de cuán general sea el programa.

Creo que prefiero CarEngine, o AutoEngine, o algo así, ya que a los programadores les gusta usar Engine como una metáfora de cosas que no se corresponden con los motores de la vida real.

Answer 7

public class Car
{
public Car(Engine engine)
{
Engine = engine;
}
public Engine Engine { get; set; }
}

Si tuviera un campo, lo prefijo con un guión bajo (_). Motor de motor tan privado; se convertiría en motor privado _engine;

Answer 8

Normalmente prefijo campos privados con guión bajo, así que lo llamaría _engine. Y a menudo uso nombres de parámetros muy cortos (por ejemplo, letra inicial), por lo que sería Engine e (después de todo, los usuarios de intellisense obtienen el tipo y el nombre). O dejo la clase y los nombres de los objetos iguales o (más habitualmente) obtengo un nombre diferente, incluso si es MyEngine o carEngine .

Asi que:
Coche de clase pública

{
#region fields
private Engine _engine;
#endregion
#region public properties
public Engine carEngine { get { return _engine; } set { _engine = value; } }
#endregion
#region constructors
public Car(Engine e)
{
_engine = e;
}
#endregion
}

Answer 9

• Miembro: m_engine;
• Miembro estático: sm_engine;
• Parámetro: motor
• Variable local: _engine
• Clase: Motor
• Propiedad: Motor

Esto permite nombrar los parámetros y las variables locales de manera diferente.