Ir al contenido principal

Standard de Nomenclatura de nombres para C#

Estándar para nombrar en c#

1. **Clases y Estructuras:**
   - PascalCase: `MiClase`, `MiEstructura`.

2. **Interfaces:**
   - PascalCase: `IMiInterface`.

3. **Métodos y Propiedades:**
   - PascalCase: `MiMetodo`, `MiPropiedad`.

4. **Variables y Parámetros:**
   - camelCase: `miVariable`, `miParametro`.

5. **Constantes:**
   - MAYÚSCULAS_CON_GUIONES_BAJOS: `MI_CONSTANTE`.

6. **Campos:**
   - camelCase con subrayado inicial para campos privados: `_miCampoPrivado`.

7. **Eventos:**
   - PascalCase con el sufijo "EventHandler" para delegados de eventos: `MiEvento`, `MiEventoHandler`.

8. **Delegados:**
   - PascalCase con el sufijo "Delegate": `MiDelegado`.

Estas son las convenciones básicas, pero recuerda que lo más importante es mantener la consistencia dentro de tu código y seguir las convenciones establecidas en tu equipo de desarrollo.

Comentarios

Entradas populares de este blog

Guía Definitiva de Estrategias de Branching en Git: Elige la Mejor para tu Equipo

Imagina esta situación: lideras un equipo de desarrollo y todos están enviando código al mismo tiempo. Sin una estrategia de ramas (branching) clara, tu base de código se convierte rápidamente en un caos de conflictos, compilaciones rotas y desarrolladores frustrados. ¿Te suena familiar? Si alguna vez te has encontrado en este lío, no estás solo. Una estrategia de branching en Git es el mapa que tu equipo necesita para gestionar los cambios de código, colaborar de manera efectiva y entregar software de calidad. Es, en esencia, un conjunto de reglas que define cómo los desarrolladores interactúan con el repositorio, cuándo crear ramas, cómo fusionar cambios y cómo mantener la estabilidad del código en todo el ciclo de vida del desarrollo. Pero es más que solo reglas. Una buena estrategia de branching se alinea con la forma en que trabaja tu equipo: tus ciclos de lanzamiento, los flujos de trabajo de QA, tus pipelines de CI/CD e incluso la frecuencia con la que necesitas aplicar correcc...

Usando Retrofit para Consumir API

Usando Retrofit para Consumir API La comunicación con servicios web y APIs REST es fundamental en el desarrollo Android. Retrofit simplifica las llamadas de red, Coroutines manejan la asincronía, y un patrón Repositorio/ViewModel estructura el acceso a datos y la lógica de negocio. Para la UI, Jetpack Compose ofrece un enfoque moderno y declarativo para construir interfaces de usuario nativas con Kotlin. En este post, construiremos una app que muestra la lista de repositorios públicos del usuario de GitHub enelramon . Utilizaremos Retrofit para la llamada a la API, un Repositorio para abstraer la fuente de datos, un ViewModel con StateFlow para gestionar el estado, y Jetpack Compose para dibujar la interfaz de usuario de forma reactiva. ¿Por qué Retrofit, Repositorio, ViewModel y Jetpack Compose? Retrofit: Simplifica las llamadas HTTP, maneja la conversión de JSON y se integra perfectamente con Coroutines. Repositorio: Abstrae la fuente de datos (red). M...

Inyección de Dependencias usando Hilt

Inyección de Dependencias usando Hilt La Inyección de Dependencias (DI) es fundamental para construir aplicaciones Android robustas, escalables y fáciles de testear. Mientras que existen varias librerías para lograrlo, Hilt se ha establecido como la solución recomendada y estándar de Google. Construido sobre la potencia de Dagger, Hilt simplifica enormemente la implementación de DI en Android. Si buscas una forma estandarizada, con menos boilerplate que Dagger puro y con excelente integración con los componentes de Android Jetpack, Hilt es la respuesta. ¡Descubramos cómo funciona! ¿Por qué elegir Hilt? Hilt ofrece ventajas significativas para el desarrollo Android: Estándar de Android: Es la librería DI recomendada por Google, lo que asegura buena documentación, soporte y alineación con las prácticas modernas de Android. Menos Boilerplate (vs. Dagger): Reduce drásticamente el código de configuración necesario en comparación con usar Dagger directamente en Andr...