Consejos de nomenclatura y estilo de código para scripting en C# en Unity

No puedes definir variables con espacios en el nombre porque C# utiliza el carácter de espacio para separar identificadores. Los esquemas de mayúsculas pueden aliviar el problema de tener que usar nombres compuestos o frases en el código fuente.

A continuación se enumeran varias convenciones de nomenclatura y mayúsculas bien conocidas:

Case de camello

También conocido como mayúsculas de camello, case de camello es la práctica de escribir frases sin espacios ni puntuación, separando las palabras con una sola letra mayúscula. La primera letra es en minúscula.

Típicamente, las variables locales y los parámetros de método aparecen en case de camello. Por ejemplo:

examplePlayerController
puntosDeSaludMax
endOfFile

Case Pascal

El case Pascal es una variación del case de camello, donde la letra inicial está en mayúscula. Usa esto para nombres de clases y métodos en el desarrollo de Unity. Los campos públicos también pueden estar en case Pascal. Por ejemplo:

ControladorDeJugadorEjemplo
PuntosDeSaludMax
EndOfFile

Snake case

En este caso, los espacios entre palabras se reemplazan con un carácter de guion bajo. Por ejemplo:

example_player_controller
max_health_points
end_of_file

Kebab case

Aquí, los espacios entre palabras se reemplazan con guiones. Las palabras luego aparecen en una especie de "escarba" de caracteres de guion. Por ejemplo:

example-player-controller
Max-health-points
end-of-file

El problema con el kebab case es que muchos lenguajes de programación utilizan el guion como signo menos. Además, algunos lenguajes interpretan números separados por guiones como fechas del calendario.

Hungarian notation

El nombre de la variable o función a menudo indica su intención o tipo. Por ejemplo:

int iCounter
string strPlayerName

La notación húngara es una convención más antigua y no se utiliza comúnmente en el desarrollo de Unity.

Considera estas reglas para tus variables y fields:

• Usa sustantivos para los nombres de las variables: Los nombres de las variables deben ser claros y descriptivos porque representan una cosa o estado específico. Usa un sustantivo al nombrarlas, excepto cuando la variable es del tipo bool (ver más abajo).
• Prefija los booleanos con un verbo: Estas variables indican un valor verdadero o falso. A menudo son la respuesta a una pregunta, como: ¿Está corriendo el jugador? ¿Está el juego terminado?
• Prefíjalos con un verbo para hacer su significado más evidente. A menudo esto se combina con una descripción o condición, por ejemplo, isDead, isWalking, hasDamageMultiplier, etc.
• Usa nombres significativos. No los abrevies (a menos que sea matemáticas): Los nombres de tus variables revelarán su intención. Elige nombres que sean fáciles de pronunciar y buscar.
• Si bien las variables de una sola letra son adecuadas para bucles y expresiones matemáticas, no abrevies en otras situaciones. La claridad es más importante que cualquier tiempo ahorrado al omitir algunas vocales.
• Para prototipos rápidos, puedes usar nombres cortos "basura" temporalmente, y luego refactorizar a nombres más significativos más adelante.
• Usa notación Pascal para campos públicos y notación camel para variables privadas: Como alternativa a los campos públicos, usa propiedades con un "getter" público (ver secciones anteriores y siguientes).
• Evita demasiados prefijos o codificación especial: Puedes prefijar las variables miembro privadas con un guion bajo (_) para diferenciarlas de las variables locales.
• Alternativamente, usa la palabra clave this para distinguir entre variables de miembro y locales en contexto y omitir el prefijo. Los campos y propiedades públicos generalmente no tienen prefijos.
• Algunas guías de estilo utilizan prefijos para variables de miembro privadas (m_), constantes (k_) o variables estáticas (s_), para que el nombre pueda revelar más sobre la variable de un vistazo.
• Muchos desarrolladores evitan esto y confían en el Editor en su lugar. Sin embargo, no todos los IDEs soportan resaltado y codificación de colores, y algunas herramientas no pueden mostrar contexto enriquecido en absoluto. Considera esto al decidir cómo (o si) aplicarás prefijos juntos como equipo.
• Especifica (o omite) modificadores de nivel de acceso de manera consistente: Si omites el modificador de acceso, el compilador asumirá que el nivel de acceso debe ser privado. Esto funciona bien, pero sé consistente en cómo omites el modificador de acceso por defecto.
• Recuerda que necesitarás usar protected si quieres esto en una subclase más tarde.

Los enums son tipos de valor especiales definidos por un conjunto de constantes nombradas. Por defecto, las constantes son enteros, contando desde cero.

Usa la notación Pascal para los nombres y valores de los enums. Puedes colocar enums públicos fuera de una clase para hacerlos globales. Usa un sustantivo singular para el nombre del enum.

Nota: Los enums de bits marcados con la System.FlagsAttribute son la excepción a esta regla. Normalmente los pluralizas ya que representan más de un tipo.

Sigue estas reglas estándar al nombrar tus clases e interfaces:

Usa sustantivos en notación Pascal para los nombres de clase: Esto mantendrá tus clases organizadas.

Si tienes un MonoBehaviour en un archivo, el nombre del archivo fuente debe coincidir: Puedes tener otras clases internas en el archivo, pero solo debe existir un MonoBehaviour por archivo.

Prefija los nombres de las interfaces con una “I” mayúscula: Sigue esto con un adjetivo que describa la funcionalidad.

En C#, cada instrucción ejecutada se realiza en el contexto de un método.

Los métodos realizan acciones, así que aplica estas reglas para nombrarlos adecuadamente:

Comienza el nombre con un verbo: Agrega contexto si es necesario (por ejemplo, ObtenerDirección, EncontrarObjetivo, etc.)

Usa camel case para los parámetros: Formatea los parámetros pasados al método como variables locales.

Los métodos que devuelven bool deben hacer preguntas: Al igual que las variables booleanas, prefija los métodos con un verbo si devuelven una condición de verdadero-falso. Esto los formula en forma de pregunta (por ejemplo, ¿EstáJuegoTerminado?, ¿HaComenzadoTurno?).

Nota: Los términos “función” y “método” se utilizan a menudo de manera intercambiable en el desarrollo de Unity. Sin embargo, dado que no puedes escribir una función sin incorporarla en una clase en C#, “método” es el término correcto.

Los eventos en C# implementan el patrón observador. Este patrón de diseño de software define una relación en la que un objeto, el sujeto (o publicador), puede notificar a una lista de objetos dependientes llamados observadores (o suscriptores). Así, el sujeto puede transmitir cambios de estado a sus observadores sin acoplar fuertemente los objetos involucrados.

Existen varios esquemas de nomenclatura para eventos y sus métodos relacionados en el sujeto y los observadores. Prueba las prácticas en las siguientes secciones.

Nombra el evento con una frase verbal. Asegúrate de elegir uno que comunique el cambio de estado con precisión.

Utiliza el participio presente o pasado para indicar el estado de los eventos como antes o después. Por ejemplo, especifica “AperturaPuerta” para un evento antes de abrir una puerta y “PuertaAbierta” para un evento después.

Utiliza el delegado System.Action para eventos. En la mayoría de los casos, el Action delegado puede manejar los eventos necesarios para el juego.

Puedes pasar hasta 16 parámetros de entrada de diferentes tipos con un tipo de retorno void. Usar el delegado predefinido ahorra código.

Nota: También puedes usar los delegados EventHandler o EventHandler. Acuerda como equipo cómo todos deben implementar eventos.

Prefija el método que genera el evento (en el sujeto) con “On.” El sujeto que invoca el evento típicamente lo hace desde un método prefijado con “On” (por ejemplo, “OnAperturaPuerta” o “OnPuertaAbierta”).

Prefija el método de manejo de eventos (en el observador) con el nombre del sujeto y un guion bajo (_). Si el sujeto se llama “EventosJuego,” tus observadores pueden tener un método llamado “EventosJuego_AperturaPuerta” o “EventosJuego_PuertaAbierta.”

Decide un esquema de nomenclatura consistente para tu equipo e implementa esas reglas en tu guía de estilo.

Nota: Este “método de manejo de eventos” no debe confundirse con el delegado EventHandler.

Crea EventArgs personalizados solo si es necesario. Si necesitas pasar datos personalizados a tu Evento, crea un nuevo tipo de EventArgs, ya sea heredado de System.EventArgs o de una estructura personalizada.

Utiliza namespaces para asegurarte de que tus clases, interfaces, enums, etc. no entren en conflicto con las que ya existen de otros namespaces, o el Namespace Global. Los namespaces también pueden prevenir conflictos con activos de terceros de la Unity Asset Store o con otras escenas de prueba que no formarán parte de la versión final del proyecto.

Al aplicar namespaces:

Utiliza la notación Pascal sin símbolos especiales ni guiones bajos.

Agrega una directiva using en la parte superior del archivo para evitar escribir repetidamente el prefijo del namespace.

Crea sub-namespaces también. Utiliza el operador punto (.) para delimitar los niveles de nombre, permitiéndote organizar tus scripts en categorías jerárquicas. Por ejemplo, puedes crear “MyApplication.GameFlow,” “MyApplication.AI,” “MyApplication.UI,” y así sucesivamente, para contener diferentes componentes lógicos de tu juego.

En el código, estas clases se refieren como Enemy.Controller1 y Enemy.Controller2, respectivamente. Agrega una línea using para ahorrar escribir el prefijo (por ejemplo, using Enemy;).

Cuando el compilador encuentra los nombres de clase Controller1 y Controller2, entiende que te refieres a Enemy.Controller1 y Enemy.Controller2.

Si el script necesita referirse a clases con el mismo nombre de diferentes namespaces, utiliza el prefijo para diferenciarlas. Por ejemplo, si tienes una clase Controller1 y Controller2 en el namespace Player, puedes escribir Player.Controller1 y Player.Controller2 para evitar conflictos. De lo contrario, el compilador informará un error.