Ir al contenido principal

Guía Completa para Crear un README.md Profesional en GitHub

¿Qué es un README.md y por qué es importante?

Guia completa para crear un readme.md Github El archivo README.md es la primera impresión que un desarrollador obtiene al visitar un repositorio en GitHub que hayas creado. Sirve como documentación principal de un proyecto, proporcionando información sobre su propósito, estructura y uso. Un README.md bien elaborado puede mejorar la comprensión del proyecto, facilitar la colaboración y también atraer contribuyentes.

Estructura recomendada de un README.md

Una estructura comúnmente utilizada para hacer que tu README.md sea claro, informativo y atractivo:

1. Título y Descripción

El título debe ser claro y descriptivo. Pensalo también, como un término de búsqueda que alguien podría buscar en Google. Luego, una breve explicación del proyecto:
# Nombre del Proyecto
Una breve descripción sobre qué hace tu proyecto.

2. Insignias (Badges)

Podés agregar insignias para indicar el estado del build, cobertura de pruebas, licencias, entre otros:
![Estado del Build](https://img.shields.io/badge/build-passing-brightgreen)
![Cobertura de Pruebas](https://img.shields.io/badge/coverage-95%25-blue)

3. Tabla de Contenidos (Opcional)

Si tu README.md es extenso, una tabla de contenidos puede facilitar la navegación:
## Tabla de Contenidos 
1. [Instalación](#instalación) 
2. [Uso](#uso) 
3. [Contribución](#contribución) 
4. [Licencia](#licencia)

4. Instalación

Instrucciones para instalar dependencias y configurar el entorno:
## Instalación
1. Cloná el repositorio:  
       git clone https://github.com/usuario/proyecto.git

2. Instala las dependencias:
       dotnet restore

3. Ejecuta la aplicación:
       dotnet run

5. Uso 

Ejemplos sobre cómo utilizar el proyecto:
## Uso
Ejecutá el siguiente comando para iniciar la aplicación:
    dotnet run

6. Contribución

Guía para contribuir al proyecto: 
# Contribución
1. Crea un fork del repositorio.
2. Crea una rama con tu nueva funcionalidad:  
       git checkout -b nueva-funcionalidad
  
3. Realiza cambios y haz un commit:
       git commit -m 'Agrega nueva funcionalidad'

4. Envía un pull request.

7. Licencia 

Especifica la licencia de tu proyecto: 
## Licencia
Este proyecto está bajo la Licencia MIT - consultá el archivo [LICENSE](LICENSE) para más detalles.

Markdown: Sintaxis y Formato Comunes

Markdown es un lenguaje de marcado ligero que permite dar formato a los archivos README.md y que queden mucho más "estilizados a la vista". Algunos estilos populares incluyen:

Encabezados 

# Encabezado H1 

## Encabezado H2 

### Encabezado H3

Negritas y Cursivas 
**Texto en negrita** 
*Texto en cursiva* 
***Texto en negrita y cursiva***

Listas

No ordenadas:
- Elemento 1  
- Elemento 2  
  - Sub-elemento

Ordenadas: 
1. Primer elemento 
2. Segundo elemento
3. Tercer elemento

Bloques de Código
using System;

class Program
{
    static void Main()
    {
        Console.WriteLine("Hola, mundo!");
    }
}

Tablas
| Columna 1 | Columna 2 | Columna 3 |
|-----------|-----------|-----------|
|   Dato 1  |   Dato 2  |   Dato 3  |

Citas
> Esto es una cita

Nota: Acordate que si estás en la plataforma de Github tenés un botón de preview (previsualización) para ir viendo como van quedando las modificaciones.



En conclusión: un README.md bien estructurado mejora la comprensión del proyecto y facilita la colaboración. Usá Markdown para dar formato profesional y asegurarte de que la documentación sea clara y fácil de seguir.

Te dejo mi perfil de Github con algunos ejemplos, y si te gustan poder darles una estrella para no perderlos o hacer follow al perfil:

Otros artículos

Principio de Segregación de Interfaces (ISP) – SOLID explicado con ejemplos

El Principio de Segregación de Interfaces es otro de los principios SOLID y establece que: Una clase no debería verse obligada a depender de métodos que no utiliza .  En otras palabras, en lugar de crear una interfaz grande con muchos métodos, es mejor dividirla (segregar) en interfaces más pequeñas y específicas. Pero.. ¿Por qué? Obliga a implementar métodos innecesarios Si una clase solo necesita una "parte" de la funcionalidad de una interfaz, pero esta interfaz es muy grande, se va a ver obligada a implementar métodos que no usa. Esto es casi que inevitable si no buscamos la manera de separar mejor las responsabilidades. Imaginemos una interfaz IVehiculo que tiene los siguientes métodos: public interface IVehiculo { void Conducir () ; void Volar () ; void Navegar () ; } Si una clase Auto implementa esta interfaz, se ve obligado a definir métodos como Volar() o Navegar() , aunque un auto no vuela ni navega. public c...

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...

Soluciones y Proyectos .NET

Bocadillos dot NET #1 En el desarrollo de software, a menudo nos encontramos con detalles cruciales que merecen una explicación más profunda para despejar dudas y avanzar con claridad. Sin embargo, extenderse demasiado en una guía principal puede hacerla pesada de leer (cosa que no queremos que ocurra). Por eso, estoy lanzando un nuevo segmento en el blog: " Bocadillos dot Net ". 🍴 Estos breves artículos ofrecerán explicaciones concretas y breves sobre temas clave, a los que podés acceder rápidamente desde las entradas principales. De esta forma, las guías seguirán siendo ligeras fáciles de digerir, mientras exploramos a fondo los temas que lo ameriten. Para inaugurar esta sección, acompañame a descubrir las diferencias conceptuales entre una solución y un proyecto en .NET. Un tema fundamental para entender cómo organizar y estructurar nuestros desarrollos en esta tecnología. Diferencias entre una Solución y un Proyecto en .NET Cuando comenzás a...

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...

Creando un Proyecto con Entity Framework - Parte 1

En esta entrada, vamos a explorar cómo configurar un nuevo proyecto en Visual Studio(VS)  2022 utilizando el enfoque Database First de Entity Framework mencionado en el hilo anterior .  Además, realizaremos algunas operaciones básicas como Agregar (Add), Eliminar (Remove) y Actualizar con un par de tablas sencillas de ejemplo. Este paso a paso está pensado para aplicar la teoría del ORM de manera práctica y concreta. Es importante destacar que Entity Framework ofrece diferentes enfoques para trabajar con bases de datos, y este es solo uno de ellos. Algunos desarrolladores prefieren trabajar con otros entornos de desarrollo o integrar sus proyectos a través de la consola, pero lo ideal es que experimentes y encuentres el método que mejor se adapte a tu estilo de trabajo.  Herramientas necesarias Para este ejemplo práctico, utilizaremos las siguientes herramientas: Visual Studio 2022 :     Podés descargarlo desde el sitio oficial: Descargar Visual S...

Principio de Responsabilidad Única (SRP) – SOLID explicado con ejemplos

Introducción a S.O.L.I.D En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID , que son fundamentales en la programación orientada a objetos o POO . Estos principios fueron formulados, en principio, por Robert C. Martin , también conocido como " Uncle Bob ", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño: Single Responsibility Principle (SRP) – Principio de Responsabilidad Única Open/Closed Principle (OCP) – Principio de Abierto/Cerrado Liskov Substitution Principle (LSP ) – Principio de Sustitución de Liskov Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias Estos principios nos ayudan a crear software más ...