C# Estándares y nomenclaturas de codificación

Hace ya varios meses que no publico ningun post. Hoy voy a publicar una serie de estandares de estilo de desarrollo, algo que toda empresa deberia de tener bien definida para que todo el mundo tenga el mismo estilo y facilite la lectura de código.

 

1.1.    Buenas prácticas

1.1.1.   PascalCasing

Se debe usar para el nombre de clases y métodos

public class ActividadCliente
{

public void BorrarEstadisticas()
{
//…
}
public void CalcularEstadisticas()
{
//…
}

}

¿Por qué?: Es consistente con .NET Framework de Microsoft y fácil de leer.

Se debe usar para las abreviaciones de 3 caracteres o más la notación para el nombre de clases y métodos

HtmlHelper htmlHelper;

FtpTransfer ftpTransfer;

UIControl uiControl;

¿Por qué?: Es consistente con .NET Framework de Microsoft y fácil de leer.

 

1.1.2.   CamelCasing

Se debe usar para el nombre de los argumentos de los métodos y variables locales.

public class Ejemplo
{
public void Add(Elemento item)
{
int itemCount = item.Items.Count;
// …
}
}

¿Por qué?: Es consistente con .NET Framework de Microsoft y fácil de leer.

1.1.3.    Declaración de variables y propiedades de clase

Se deben de declarar todas las propiedades y variables privadas de una clase en su parte superior.

public class Account
{
public static string BankName;
public static decimal Reserves;
public string Number {get;set;}
public DateTime DateOpened{get;set;}
public DateTime DateClosed{get;set;}
public decimal Balance{get;set;}
// Constructor
publicAccount()
{
// …
}
}

¿Por qué?: Esta muy generalizada y aceptada. Es una práctica que evita tener que estar buscando la definición de dichas propiedades y variables.

 

1.1.4.   Definición de tipos en las variables

Se debe usar los nombres de tipos predefinidos en lugar de los nombres de los tipos de sistema como Int16, Int32, etc

// Correcto
string firstName;
int lastIndex;
bool isSaved;

// Evitar
String firstName;
Int32 lastIndex;
Boolean isSaved;

¿Por qué?: Es consistente con .NET Framework de Microsoft y es mucho más natural de leer.

Se debe usar el tipo implicito “var”. Excepto para los tipos primitivos (string, int, etc)

var stream =File.Create(path);

var customers =newDictionary();

// Excepciones

int index =100;

string timeSheet;

bool isCompleted;

 

¿Por qué?: Elimina ruido, sobre todo cuando se trata de tipos genéricos complejos. El tipo es fácilmente detectable con los tooltips de Visual Studio.

 

1.1.5.   Clases

Utilizar Substantivos para nombrar las clases.

public class Empleado
{
}
public class Localizacion
{
}

public class Documento
{
}

¿Por qué?: Es consistente con .NET Framework de Microsoft y fáciles de recordar.

1.1.6.   Interfaces.

Utilizar el prefijo “I” y nombres o adjetivos para nombrarlas.

public interface IShape

{

}

public interface IShapeCollection

{

}

¿Por qué?: Es consistente con .NET Framework de Microsoft y fáciles de recordar.

1.1.7.   El nombre de los archivos de código

El nombre de los archivos de código fuente debe coincidir con la clase, a excepción, de las clases parciales que pueden tener un sufijo (designer, generated, etc).

// Archivo Task.cs

public partial class Task

{

//…

}

// Archivo Task.Designer.cs

public partial class Task

{

//…

}

¿Por qué?: Es consistente con .NET Framework de Microsoft. Los archivos están alfabéticamente ordenados, facilidad para buscar las clases.

1.1.8.   Alinear verticalmente entre llaves

public class Ejemplo

{

public void Main()

{

}

}

¿Por qué?: Hay muchos estándares respecto a esto, pero este es el más utilizado.

 

1.1.9.   Enums

Se debe nombrar en singular excepto aquellos que tengan la data anotation [Flag]

// Correcto

public enum Color

{       

       Red,

       Green,     

   Blue,

       Yellow,

       Magenta,

       Cyan

}

// Excepcion

[Flags]

public enum Posiciones

{

       None = 0,

        Top = 1,

        Right = 2,

        Bottom = 4,

        Left = 8

}

¿Por qué?: Es consistente con .NET Framework de Microsoft y hace el código mucho más natural de leer. El plural se usa con los enums que tienen el Flag porque pueden contener varios valores.

1.2.     Malas practicas

1.2.1.   Notación Hungara

No se debe usar la notación Hungara  o cualquier otro tipo de identificación de tipo.

// Correcto
int contador;
string nombre;


// Evitar
int iContador;
string strNombre;

¿Por qué?: Es consistente con .NET Framework de la Microsoft y Visual Studio hace la identificación de los tipos sea muy sencilla fácil de leer.

 

1.2.2.   Constantes y readonly

No se debe usar nombres con todos los caracteres en mayúsculas

// Correcto
    public static const string TipoDeTransporte = “tipo1”;


// Incorrecto
public static const string TIPODETRANSPORTE = “tipo1”;

¿Por qué?: Es consistente con .NET Framework de la Microsoft. Las mayúsculas desvían nuestra atención.

1.2.3.   Abreviaciones

Evitar usar abreviaciones  excepto las abreviaturas comúnmente utilizadas Id, XML, FTP, Uri.

 

    // Correcto
UserGroup userGroup;
Assignment employeeAssignment;


// Evitar
UserGroup usrGrp;
Assignment empAssignment;


    // Excepciones
    CustomerId customerId;
    XmlDocument xmlDocument;
FtpHelper ftpHelper;
UriPart uriPart;

¿Por qué?: Es consistente con .NET Framework de la Microsoft y  previene abreviaciones inconsistentes.

 

1.2.4.   Guion bajo (_)

No se debe usar la el guion bajo (_) excepto como prefijo en las variables privadas.

 

// Correcto
public DateTime ClientAppointment;
public TimeSpan TimeLeft;

// Evitar
public DateTime client_Appointment;
public TimeSpan time_Left;

// Excepción
private DateTime _registrationDate;
¿Por qué?: Es consistente con .NET Framework de la Microsoft y hace que el código sea más natural para leer. También evita el estrés por subrayado (incapacidad para ver el subrayado).

.

1.2.5.   Enums

No indicar con el sufijo o prefijo “Enum”

// Correcto

public enum Color

{

Red,

Green,

Blue,

Yellow,

Magenta,

Cyan

}

// Incorrecto

public enum PosicionesEnum

{

None = 0,

Top = 1,

Right = 2,

Bottom = 4,

Left = 8

}

¿Por qué?: Es consistente con .NET Framework de Microsoft y consistente con la regla de no usar un identificador de tipo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *