Si bien es posible que no exista una forma correcta de formatear su código C#, acordar un estilo consistente en todo su equipo puede resultar en una base de código más limpia, legible y escalable. Una guía de estilo bien organizada puede ayudarle a controlar las discrepancias para producir un producto final coherente. Esta página proporciona consejos y consideraciones clave a tener en cuenta para las convenciones de nomenclatura y el formato del código al crear su propia guía de estilo.
Nota: Las recomendaciones compartidas aquí se basan en las proporcionadas por Microsoft. Las mejores reglas de guía de estilo de código son las que mejor funcionan para las necesidades de su equipo.
Puede encontrar un ejemplo de guía de estilo de código aquí o descargar el libro electrónico completo. Cree una guía de estilo de C#: Escriba código más limpio y escalable.
No puede definir variables con espacios en el nombre porque C# usa el carácter de espacio para separar identificadores. Los esquemas de mayúsculas y minúsculas pueden aliviar el problema de tener que utilizar nombres o frases compuestos en el código fuente.
A continuación se enumeran varias convenciones de nomenclatura y mayúsculas y minúsculas bien conocidas:
El caso de Carmel
También conocido como mayúsculas de camello, el caso camello es la práctica de escribir frases sin espacios ni puntuación, separando las palabras con una sola letra en mayúscula. La primera letra está en minúscula.
Normalmente, las variables locales y los parámetros del método aparecen en formato camel. Por ejemplo:
examplePlayerController
maxHealthPoints
endOfFile
caso Pascal
El caso Pascal es una variación del caso camel, donde la letra inicial está en mayúscula. Úselo para nombres de clases y métodos en el desarrollo de Unity. Los campos públicos también pueden ser en caso pascal. Por ejemplo:
ExamplePlayerController
MaxHealthPoints
EndOfFile
caso de serpiente
En este caso, los espacios entre palabras se reemplazan por un carácter de subrayado. Por ejemplo:
example_player_controller
max_health_points
end_of_file
caso kebab
Aquí, los espacios entre palabras se reemplazan por guiones. Luego, las palabras aparecen en una especie de “brocheta” de caracteres de guión. Por ejemplo:
example-player-controller
Puntos de salud máximos
fin del documento
El problema con el caso del kebab es que muchos lenguajes de programación utilizan el guión como signo menos. Además, algunos idiomas interpretan los números separados por guiones como fechas del calendario.
Notación húngara
El nombre de la variable o función suele indicar su intención o tipo. Por ejemplo:
iCounter int
cadena strPlayerName
La notación húngara es una convención más antigua y no se usa comúnmente en el desarrollo de Unity.
Considere estas reglas para sus variables y campos:
- Utilice sustantivos para nombres de variables: Los nombres de las variables deben ser claros y descriptivos porque representan una cosa o estado específico. Utilice un sustantivo al nombrarlos, excepto cuando la variable sea del tipo bool (ver más abajo).
- Prefijos booleanos con un verbo: Estas variables indican un valor verdadero o falso. A menudo son la respuesta a una pregunta, como por ejemplo: ¿Está funcionando el jugador? ¿Se acabó el juego?
- Prefiérales un verbo para que su significado sea más evidente. A menudo, esto se combina con una descripción o condición, por ejemplo, isDead, isWalking, hasDamageMultiplier, etc.
- Utilice nombres significativos. No abrevie (a menos que sea matemática): Los nombres de sus variables revelarán su intención. Elija nombres que sean fáciles de pronunciar y buscar.
- Si bien las variables de una sola letra están bien para bucles y expresiones matemáticas, no las abrevie en otras situaciones. La claridad es más importante que el tiempo que se ahorra al omitir algunas vocales.
- Para crear prototipos rápidamente, puede utilizar nombres cortos "basura" temporalmente y luego refactorizarlos con nombres más significativos más adelante.
- Utilice mayúsculas y minúsculas pascal para campos públicos y mayúsculas y minúsculas camel para variables privadas: Como alternativa a los campos públicos, utilice propiedades con un "captador" público (consulte las secciones anterior y siguiente).
- Evite demasiados prefijos o codificaciones especiales: Puede anteponer a las variables miembro privadas un guión bajo (_) para diferenciarlas de las variables locales.
- Alternativamente, use la palabra clave this para distinguir entre variables miembro y locales en contexto y omita el prefijo. Los campos y propiedades públicos generalmente no tienen prefijos.
- Algunas guías de estilo usan prefijos para variables miembro privadas (m_), constantes (k_) o variables estáticas (s_), por lo que el nombre puede revelar más sobre la variable de un vistazo.
- Muchos desarrolladores los evitan y, en su lugar, confían en el Editor. Sin embargo, no todos los IDE admiten resaltado y codificación de colores, y algunas herramientas no pueden mostrar ningún contexto enriquecido. Considere esto al decidir cómo (o si) aplicarán prefijos juntos como equipo.
- Especifique (u omita) modificadores de nivel de acceso de forma coherente: Si omite el modificador de acceso, el compilador asumirá que el nivel de acceso debe ser privado. Esto funciona bien, pero sea coherente al omitir el modificador de acceso predeterminado.
- Recuerde que necesitará usar protected si desea esto en una subclase más adelante.
Las enumeraciones son tipos de valores especiales definidos por un conjunto de constantes con nombre. De forma predeterminada, las constantes son números enteros y cuentan desde cero.
Utilice mayúsculas y minúsculas pascal para nombres y valores de enumeración. Puede colocar enumeraciones públicas fuera de una clase para hacerlas globales. Utilice un sustantivo singular para el nombre de la enumeración.
Nota: Las enumeraciones bit a bit marcadas con System.FlagsAttribute son la excepción a esta regla. Normalmente los pluralizas ya que representan más de un tipo.
Siga estas reglas estándar al nombrar sus clases e interfaces:
Utilice sustantivos en caso pascal para nombres de clases: Esto mantendrá tus clases organizadas.
Si tiene un MonoBehaviour en un archivo, el nombre del archivo fuente debe coincidir: Es posible que tenga otras clases internas en el archivo, pero solo debe existir un MonoBehaviour por archivo.
Prefije los nombres de las interfaces con una “I” mayúscula: Siga 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 aplique estas reglas para nombrarlos en consecuencia:
Comienza el nombre con un verbo: Agregue contexto si es necesario (por ejemplo,GetDirection,FindTarget, etc.)
Utilice el caso camel para los parámetros: Formatee los parámetros pasados al método como variables locales.
Los métodos que devuelven bool deberían hacer preguntas: Al igual que las propias variables booleanas, los métodos deben anteponerse un verbo si devuelven una condición de verdadero o falso. Esto los expresa en forma de pregunta (por ejemplo,IsGameOver,HasStartedTurn).
Nota: Los términos "función" y "método" a menudo se usan indistintamente en el desarrollo de Unity. Sin embargo, como no se puede escribir una función sin incorporarla a una clase en C#, "método" es el término correcto.
Los eventos en C# implementan el patrón de observador. Este patrón de diseño de software define una relación en la que un objeto, el sujeto (o editor), puede notificar a una lista de objetos dependientes llamados observadores (o suscriptores). Por lo tanto, el sujeto puede transmitir cambios de estado a sus observadores sin acoplar estrechamente los objetos involucrados.
Existen varios esquemas de denominación para eventos y sus métodos relacionados en el sujeto y los observadores. Pruebe las prácticas de las siguientes secciones.
Nombra el evento con una frase verbal. Asegúrese de elegir uno que comunique el cambio de estado con precisión.
Utilice el participio presente o pasado para indicar el estado de los acontecimientos antes o después. Por ejemplo, especifique "OpeningDoor" para un evento antes de abrir una puerta y "DoorOpened" para un evento posterior.
Utilice el delegado System.Action para eventos. En la mayoría de los casos, el delegado de Acción<T> puede manejar los eventos necesarios para el juego.
Puede pasar hasta 16 parámetros de entrada de diferentes tipos con un tipo de retorno nulo. El uso del delegado predefinido guarda el código.
Nota: También puede utilizar los delegados EventHandler o EventHandler<TEventArgs> . Acuerde en equipo cómo todos deberían implementar los eventos.
Anteponga "Activado" al método de generación de eventos (en el asunto). El sujeto que invoca el evento normalmente lo hace desde un método con el prefijo "On" (por ejemplo, "OnOpeningDoor" o "OnDoorOpened").
Anteponga el método de manejo de eventos (en el observador) con el nombre del sujeto y un guión bajo (_). Si el tema se llama "GameEvents", sus observadores pueden tener un método llamado "GameEvents_OpeningDoor" o "GameEvents_DoorOpened".
Decide un esquema de nombres coherente 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.
Cree EventArgs personalizados solo si es necesario. Si necesita pasar datos personalizados a su evento, cree un nuevo tipo de EventArgs, ya sea heredado de System.EventArgs o de una estructura personalizada.
Utilice espacios de nombres para asegurarse de que sus clases, interfaces, enumeraciones, etc. no entren en conflicto con los que ya existen en otros espacios de nombres o con el espacio de nombres global. Los espacios de nombres también pueden evitar conflictos con recursos de terceros de Unity Asset Store u otras escenas de prueba que no formarán parte de la versión final del proyecto.
Al aplicar espacios de nombres:
Utilice mayúsculas y minúsculas pascal sin símbolos especiales ni guiones bajos.
Agregue una directivade usoen la parte superior del archivo para evitar escribir repetidamente el prefijo del espacio de nombres.
Cree también subespacios de nombres. Utilice el operador punto (.) para delimitar los niveles de nombre, lo que le permitirá organizar sus scripts en categorías jerárquicas. Por ejemplo, puedes crear "MyApplication.GameFlow", "MyApplication.AI", "MyApplication.UI", etc., para contener diferentes componentes lógicos de tu juego.
En el código, estas clases se denominan Enemy.Controller1 y Enemy.Controller2, respectivamente. Agregue una línea de uso para ahorrar escribir el prefijo (por ejemplo,usando 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 hacer referencia a clases con el mismo nombre de diferentes espacios de nombres, utilice el prefijo para diferenciarlas. Por ejemplo, si tiene una clase Controller1 y Controller2 en el espacio de nombres Player, puede escribirPlayer.Controller1y Player.Controller2 para evitar conflictos. De lo contrario, el compilador informará un error.
Obtenga más consejos de estilo de código
Obtenga más información sobre el formato general aquí o consulte el libro electrónico completo. También puede explorar nuestro ejemplo de guía de estilo de código.