Dos convenciones de nomenclatura de C #: ¿Qué te parece? [cerrado]

StackOverflow https://stackoverflow.com/questions/823294

  •  05-07-2019
  •  | 
  •  

Pregunta

Tengo dos específicos C # convenciones de codificación que he estado practicando con sentimientos encontrados. Tendría curiosidad por escuchar lo que piensa la gente. Ellos son:

# 1. Nombra instancias después de la clase de la que es una instancia, camelCased

# 2: " Nombres de propiedades coincidentes "

Aquí está la justificación:

# 1. Nombra instancias después de la clase de la que es una instancia, camelCased

Utilizo esto como mi configuración predeterminada para la convención de nomenclatura. Por supuesto, hay excepciones. Pero si se usa de forma consistente, dramáticamente mejora la claridad y la capacidad de mantenimiento del código. El código se ve así: 

var dataConnection = new DataConnection();
//not: var dataConn, dbConn, sqlConn, myDbPickOfTheDay etc.

FileInfo fileInfo = new FileInfo();

Timer timer = new Timer(); 

//etc.

Estoy en el punto donde un código como este me causa dolor físico: 

DataConnection dbConn = new DataConnection();

No puedo enfatizar lo suficiente cómo esta convención ha quitado el dolor y la ira del juego de nombres variables.

Esta convención contrasta con el hecho de intentar nombrar las cosas de manera que se intente indicar qué está haciendo la instancia, lo que equivale a tratar de integrar de forma creativa el caso de negocio en el código. El código tiene una manera de ser refactorizado hasta el punto en que esos nombres originales son, en el mejor de los casos, engañosos.

Para mí esta convención es oro. También evita la práctica horrible de nombres de variables ligeramente modificados para lo mismo.

Un ejemplo de esta convención en la práctica es: 

class Person { ...
   public string FirstName { get; set; }

//and then
var person = new Person();
person.FirstName = firstName; //where firstName comes from somewhere else.

Muy fácil de leer. Muy aburrido. Aburrir es bueno cuando se trata de mantener el código.

Sin embargo , esta convención me lleva al # 2:

# 2 " Nombres de propiedades coincidentes " (a falta de un título mejor)

Aquí hay un ejemplo: 

public class ShoppingCart { ..
  private Item item;
  public Item Item {  //<---- ?
  get { return this.item; } ...

El compilador está perfectamente feliz con esto. Y, de hecho, expone una interfaz muy agradable: 

//notice how tempting it is to just say "ShoppingCart cart ... "
ShoppingCart shoppingCart = new ShoppingCart();  
shoppingCart.Item = item;

Ahora, la alternativa es ser creativo: de hecho, necesita reunir dos buenos nombres de variables para el Artículo: el nombre de la propiedad pública y el nombre de la variable del miembro privado.

¿Cuántas veces has visto esto y solo quieres retirarte de inmediato? 

 public class ShoppingCart { ..
      private Item cartItem;
      public Item ShoppingCartItem { 
      get { return this.cartItem; } ..
  ///....
  ShoppingCart userShoppingCart = new ShoppingCart();
  userShoppingCart.ShoppingCartItem = userSelection;

Me siento lo suficientemente fuerte con respecto a la convención # 1 que creo que puedo vivir con el # 2.

¿Qué piensas?

¿Fue útil?

Solución

en caso de que no lo supiera y si le importa, C # ya tiene un estándar de nomenclatura

http://msdn.microsoft.com/en -us / library / xzf533w0 (VS.71) .aspx

También, revisando sus convenciones nuevamente ... aquí hay algunas sugerencias más.

  • fileInfo se ve bastante al lado de FileInfo, pero no tiene otro significado que no sea el tipo que puedo obtener rápidamente al hacer clic sobre el tipo o en intellisense. Sugeriría nombrar sus variables con significado y algún contexto si está disponible. remoteWebServerLog, localWebServerLog o incluso localWebServerLogFileInfo si le gusta el tipo en el nombre.

    Si puedo repartir algún consejo al regresar al código que escribiste 6+ meses más tarde. Se rascará la cabeza tratando de descubrir y rastrear qué diablos son todos sus dbConn y fileInfo. Que archivo Que db Muchas aplicaciones tienen varios dbs, ¿es esta dbConn para OrdersDB o ShoppingCartDB?

  • La denominación de clases debe ser más descriptiva. Preferiríamos ShoppingCartItem sobre Item. Si cada ListBox, DropDown, etc., nombraran sus elementos de colección "Elemento" estaría chocando con muchos espacios de nombres y se vería obligado a ensuciar su código con MyNameSpace.ShoppingCart.Item.

Habiendo dicho todo eso ... incluso después de años de codificación, todavía me equivoco y no sigo las reglas el 100% del tiempo. Puede que incluso haya usado FileInfo fi = ... pero es por eso que me encanta mi Resharper " Refactor- > Rename " comando y lo uso a menudo.

Otros consejos

La Convención # 1 puede volverse confusa. Si tuviera dos objetos FileInfo en el mismo método, digamos un Origen y un Destino, necesitaría desviarse de la convención para nombrar los dos.

Los nombres de las variables deben ser mnemónicos: para indicar al observador casual la intención de su uso.

Tal vez sería más feliz con una combinación de las dos convenciones ... como sourceFileInfo y targetFileInfo, por este ejemplo.

Obviamente, no puede asignar un nombre a cada System.String en su proyecto cadena *, , pero para cosas que no usa mucho, esp. las cosas de las que solo necesita una y cuya función en su código es evidente por su nombre, estas convenciones de denominación son perfectamente aceptables.

De todos modos, son lo que hago.

Iría con un nombre más específico para, por ejemplo, el objeto Timer. ¿Para qué sirve un temporizador? Pero definitivamente nombraré una DataConnection dataConnection.

* Incluso si " cadena " no era una palabra clave ...

Hago 1 todo el tiempo y me parece muy legible. Estoy en la cerca con 2. Lo encuentro confuso en ciertas situaciones, principalmente porque es difícil distinguir el tipo de la propiedad debido a que los identificadores son idénticos.

Normalmente seguiría la convención n. ° 1, aunque para los nombres de clase largos tiendo a usar las iniciales de la clase. Si me estoy refiriendo a más de un objeto del mismo tipo, entonces colgaría el nombre del tipo con un nombre que indique cuál es o para qué se utiliza.

A menudo uso la convención n. ° 2 si tiene sentido. No hay nada peor que tener algo como el ejemplo que enumeró de cart.ShopingCartItem, el hecho mismo de que sea una propiedad de ShoppingCart hace que esa parte del nombre de la propiedad sea totalmente redundante. Sin embargo, es muy probable que nombre la clase ShoppingCartItem y la propiedad Item. El artículo es un nombre demasiado genérico, mientras que ShoppingCartItem le dice con qué tipo de artículo está trabajando.

Sigo la convención 1 todo el tiempo. Sin embargo, agrego un calificador adicional si hay dos objetos uno al lado del otro.

Pero dicho esto, hacer que esta convención sea obligatoria puede ser problemático:

  1. En un determinado contexto, cart puede ser un nombre suficientemente bueno para un objeto ShoppingCart (si, por ejemplo, no hay otro 'cart' en la misma función para ser confundido con).
  2. A veces, la convención puede ocultar completamente el propósito del objeto declarado. Por ejemplo, Window scoreBoard = new Window () dice que tenemos un objeto que es de hecho una ventana pero que se está utilizando como scoreBoard. Muy expresivo. Pero siguiendo la convención 1, tendría que escribir Window window = new Window () que oculta totalmente la intención detrás de esta ventana.

Por lo tanto, diría que utilice esta idea de denominación en cualquier lugar, excepto cuando obstaculice el significado o parezca irrazonablemente exigente.

Sobre la convención 2, estoy totalmente de acuerdo. Mantener los nombres de propiedades concisos y dejar que el nombre del objeto complete el significado completo de su invocación es algo elegante. Funciona perfectamente con objetos bien nombrados. Así que hay pocas razones para tener miedo de usarlo.

No me gusta la noción de tener múltiples identificadores en el alcance que difieren solo en su uso de mayúsculas / minúsculas; si tuviera mis druthers, el código que usaba un identificador tendría que usar la misma combinación de letras mayúsculas / minúsculas que su declaración, pero el código no podría declarar dos identificadores en el mismo ámbito que difieren solo por caso, ni acceso cualquier identificador que, excepto el caso, coincida con un identificador en un ámbito interno. Aunque no conozco ningún idioma (ciertamente no VB ni C #) hace cumplir tales reglas, el código escrito en conformidad con dichas reglas podría ser libremente transferible entre los idiomas que distinguen entre mayúsculas y minúsculas sin tener que cambiar el nombre de los identificadores.

En consecuencia, no me gusta el patrón # 2. El cumplimiento de CLS requiere que cualquier identificador de ese estilo esté restringido al ámbito privado o interno . Dado que tanto vb.net como C # permiten que los nombres comiencen con guiones bajos, si una propiedad se llama Trait , no veo ninguna razón para favorecer a trait sobre _trait . El uso del último nombre distinguiría claramente los casos en que el programador quería escribir en la variable de respaldo de aquellos donde su dedo se deslizó en la tecla Mayús.

En cuanto al patrón n. ° 1, en los casos en que el propósito completo de un tipo o método se resuelve alrededor de un único objeto encapsulado de algún tipo en particular, prefiero prefijar los campos con my o los parámetros con el . Incluso en los casos en que el compilador permitiría el uso de los mismos nombres para los miembros y parámetros de la instancia, el uso de prefijos distintos evita la posibilidad de usar uno donde se requiere el otro.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top