Después de unas semanas dedicadas a la familia, toca entrada por fin. Aunque por ahora me limitaré a entradas cortas sobre temas específicos y un poco más centrados en el código, pues ahora toca retomar y acabar con algunos temas pendientes tales como terminar la demo, finalizar los retoques del documento de puzzles y actualizar el documento de diseño con los pequeños cambios que van surgiendo con el desarrollo.
De estas entradas de carácter corto, en esta en concreto trataremos algo que muchos novatos programadores se olvidan, o que ni siquiera saben que existe: las normas de estilo (en inglés se suele denominar como coding guidelines).
Tal como os puse en situación con la entrada del control de versiones en los proyectos y de cómo era necesario no sólo para tener una copia controlada del proyecto, sino en el caso de varios programadores a la vez, este es otro de los elementos necesarios en el caso de que varios programadores trabajen a la vez y tengan que leer los códigos de otros. O simplemente para que el código sea más fácil de leer para otras personas una vez publicado.
Y esto es un problema que se adquiere por aprender a programar sin tener estos factores de que tu código no solo lo tienes que entender tú, también tiene que ser comprensible para todos los demás.
Esto es algo muy importante, pues si varios programadores escriben el código cada uno siguiendo sus propias normas, llegará un punto en el que si otra persona no entiende que es lo que está haciendo el otro, ralentizando el ritmo del grupo (has de dedicar un tiempo a comprender qué quería hacer el otro programador con el código que lees) y creando confusión y/o diversidad de opiniones sobre como debería haberse escrito X código. Todo ese tiempo perdido se podría haber empleado en seguir trabajando en el proyecto, y lo que es peor, no será una situación que se dé de manera excepcional, sino que se dará de manera habitual.
Si dichos programadores llegasen a un acuerdo de cómo escribir el código de forma que los dos lo escribiesen de la misma forma, lograrían un código uniforme y fácilmente legible, evitando esta situación.
Algunos casos prácticos simples son tabular siempre con cuatro espacios los códigos anidados, poner saltos de línea en los bloques de código if/else sin importar su longitud, poner nombres explicativos a las funciones y variables usando la notación CamelCase sin importar lo largos que sean estos.
Muchas empresas y organizaciones ya proporcionan sus propias normas de estilo, algunas prácticamente a nivel de estándar internacional, para que lo tomen en cuenta los programadores profesionales para que a la hora de embarcarse en proyectos sea de la envergadura que sea, tengan en cuenta estas facilidades sin tener que crearse sus propias normas.
Algunas de las normas más conocidas son la de Google para C++, la de Microsoft para C#, o unas de las más completas que puede aplicarse en la gran mayoría de los lenguajes es de la PHP creada por PHP The Right Way.
Lamentablemente de Unity no hay ninguna convención que esté más o menos estandarizada, así que para 1812: La aventura he decidido adoptar algunas normas de estilo que están más o menos aceptadas. El formato que he elegido es el presente en la página de Unity Gems, que os la recomiendo visitar pues contiene artículos variados y muy útiles sobre Unity.
Y hasta aquí esta entrada, si conocéis más normas de estilo que consideráis que debería mencionar aquí, no dudéis en comunicármelo y las pondré.
Espero, como siempre, que esta entrada os haya servido y que los novatos os vayáis dando cuenta de los muchos detalles que hay que tener en cuenta a la hora de empezar un videojuego, para que al menos tengáis unas garantías sino de éxito al realizar el juego, pero al menos amenizaros el trabajo lo más posible.
1812: La aventura 