El manejo de los estándares de codificación para programadores es una parte importante de nuestro trabajo. Nos ayuda a trabajar mejor en equipo y que el código sea lo más legible posible por otros. Conocerlos harán que seamos mejores programadores Veamos las más interesantes en este artículo.
Convención de nombres
Muchos piensan que nombrar cosas es difícil, lo es. Cada uno de los lenguajes tienen sus propias convenciones de nombres, por ejemplo, la de java es muy similar a la de C#, pero, no es exactamente la misma. Lo importante de tenerla es que nos guía a tener un código uniforme, si no la tenemos, los miembros de un equipo lo harán cada uno a su gusto. Esto dificulta la lectura para otros integrantes como para nuevos integrantes del equipo.
En C# tenemos básicamente 3 que son las más populares, esto no quita que cada equipo pueda hacer las suyas, pero la comunidad en la mayoría de los casos sigue estas 3:
- PascalCase: se utiliza para nombres de archivo, espacios de nombres, clases, métodos y miembros públicos.
- camelCase: utilizada para miembros no públicos o privados.
- UPPER_CASE: se utiliza para nombrar variables constantes o enumeraciones.
Algo muy discutido, es el uso del guion bajo (_) en la declaración de los miembros privados. Por mi parte, es útil. Sobre todo, cuando estamos usando inyección de dependencia, tiende confundir la variable que se pase en constructor con el miembro al cual se asigna. Para eso uso el _ para distinguirla. Puede ser molesto hacer un this._, pero me facilita la lectura y evitar utilizar la variable incorrecta.
public class Product
{
private string _productName;
public void Show(string producttName = null)
{
Console.WriteLine($"mostrar: , { producttName ?? _productName }!");
}
}Existen otros tipos de conversiones en otros lenguajes, pero no son muy amigables a C#, muchas son un dolor de cabeza. Por ejemplo, la notación húngara. Esta notación está relacionada con cómo debemos nombrar las variables. Básicamente, cada variable debe tener en su letra inicial un tipo, por ejemplo, una variable que contenga la edad, como la edad podemos guardarla en un int, debería ser el nombre de la variable iEdad.
Si bien no está mal, en la actualidad debemos tener presente lo siguiente: el compilador transforma todo a código que la máquina comprenda y no le importa que escribimos en realidad. Aquí es donde está un poco de sentido común, edad en el 99% de los casos era un int y sabes que no lo necesitamos estaría demasiado. Pero dirán y si no puedo distinguirlo, bueno en este caso podemos usar un nombre largo como saldoTotalEnCuenta. Recordemos que no nos cobran por letra o que tardará más en compilar por un nombre tan largo y no ayuda más fácilmente a saber qué tipo tiene esa variable solo por el nombre.
Formatos
Existen algunas convenciones para formato en C#. En este caso, a diferencia del anterior, son compartidos por varios lenguajes. Estos son formato de saltos de líneas, sangría y espacio. En la actualidad, todos los IDEs de desarrollo, tienen herramientas para ayudarnos a respetar esos formatos, pero, aun así, no está demás conocerlos.
Hay una gran controversia, aunque no lo crean, se usa para indentar código entre espacio y tabs. No quiero entrar en la discusión, si no en lo importante de cuantos deben ser, tanto el tab como la cantidad de espacios deben ser de 4. Quiere decir que un 1 tab es igual a 4 espacios.
Otro formato, a pesar de que el lenguaje lo permite, siempre que abras una llave o un corte debe tener su cierre relacionado. También, los puntos y como de cierre de instrucción, luego de este no tiene que existir nada, si queremos agregar código que sea en la línea siguiente.
El uso de VAR
Var es especialmente útil cuando las variables son de corta duración o en un mismo ámbito. Nos ayuda a reducir la redundancia y tener mayor flexibilidad en el código. La gran pregunta: ¿Cómo hago para saber el tipo si es un var? es muy sencillo, si nos paramos arriba del var el IDE no mostrará el tipo que tomará porque infiere el resultado del método que estamos invocando.
var product = new product(id);
var result = await _someApiproduct.GetAsync(id, cancellationToken);
for(var i = 0; i < max; i++)
{
// i is implicitly typed
}
var product = this.productFactory.GetOrCreate(id);
this.someDependency.Submitproduct(product);Uso de propiedades
Cuando declaramos una propiedad automáticamente se creará una variable de respaldo para almacenar esa propiedad. Al menos que realmente necesite acceder a esa variable no es necesario declararla solo podemos usar la versión automática.
public int Count { get; set; }Un truco para escribir las propiedades más rápido, podemos usar prop y presionar el tab, esto nos creará la propiedad donde deberemos completar el tipo y el nombre solamente.
Declarar Variables
Una práctica que se usaba hace mucho tiempo, era declarar todas las variables al inicio de la clase. Se hacía de esa manera porque muchos lenguajes lo primero que hacían era iniciar las variables por cuestiones de espacio, hoy ya no es necesario. Hoy esto tiene un problema, cuando nuestra clase es extensa, volver al código por alguna razón para ver las variables es incómodo. Subimos hasta el inicio y debemos volver al código. Aunque los IDEs hoy permiten poner marcas o ir a lineas, la mejor práctica es declarar las variables lo más cercano posible a donde serán utilizadas
Organización de archivos
Todos nuestros archivos deben estar organizados en carpetas acordes o con nombres relacionados con lo que van a contener para que sea fácil de comprender y navegar. Clases, Interfaces y enumeraciones deben estar en un solo archivo para simplificar el seguimiento y la lectura.
USING cómo destructor
Cuando declaramos una variable esta variable quedará en memoria hasta que pierda todas sus referencias y el Garbage Collector haga su trabajo. Pero una muy buena práctica es usar los using para determinar que el objeto ya no es utilizado y que el Garbage Collector lo elimine lo más rápido posible.
El mejor ejemplo de estos es cuando abrimos una conexión a una base de datos u otro tipo de canal que necesitemos mantener un estado. Si no cerramos el objeto de conexión, la conexión puede quedar abierta hasta que se elimine el objeto.
using(var connection = new Connection())
using(var stream = connection.OpenStream())
{
// ---
}Conclusiones
Estos son algunos puntos interesantes. Podríamos entrar en más detalle en técnicas de Clean Code para mejorar nuestro código. Tal vez lo hagamos en próximos posts, espero que hayan disfrutado este.
