1.08 · Buenas Prácticas, Git Básico y Clean Code Inicial

🎯 Objetivo de aprendizaje

Al terminar este tema vas a poder:

1. Aplicar las reglas de oro del clean code: nombres descriptivos, funciones pequeñas, indentación consistente, comentarios útiles.
2. Inicializar un repositorio Git en un proyecto, hacer commits, escribir mensajes de commit profesionales.
3. Crear una cuenta de GitHub, conectarla a tu VS Code, y subir tu primer repositorio.
4. Escribir un README.md profesional que presente tu proyecto (qué hace, cómo instalarlo, cómo usarlo, cómo contribuir).
5. Crear un archivo .gitignore para no subir archivos basura (compilados, temporales, del IDE).
6. Entender qué es la deuda técnica, cómo se acumula, y por qué las buenas prácticas la previenen.
7. Reconocer código "limpio" y código "sucio" a simple vista, y refactorizar el segundo.

Este tema es la diferencia entre un programador que escribe código y un programador que escribe código profesional. Es la base sobre la que vas a construir tu carrera.

🧠 Teoría y conceptos — 1.8.1 — Qué es el clean code y por qué importa

La definición

Clean code (código limpio) es código que es fácil de leer, fácil de entender, y fácil de modificar por cualquier persona del equipo (incluido tú mismo en 6 meses). El término se popularizó por Robert C. Martin (alias "Uncle Bob") en su libro Clean Code (2008).

Por qué importa más que la sintaxis

Imagina este escenario: tu empresa te da un programa de 5,000 líneas que otro programador escribió hace 2 años y se fue de la empresa. Te piden agregar una funcionalidad. ¿Qué prefieres encontrarte?

Opción A — Código limpio:

double calcularPrecioConDescuento(double precioBase, double porcentajeDescuento) {

if (porcentajeDescuento < 0 || porcentajeDescuento > 100) {
return precioBase;  // descuento inválido, no se aplica

}

double descuento = precioBase * (porcentajeDescuento / 100);

return precioBase - descuento;

}

Opción B — Código sucio:

double f(double p, double d) {

if (d < 0 || d > 100) return p;
return p - p * d / 100;

}

Ambos programas hacen exactamente lo mismo. Ambos compilan. Ambos pasan los tests. Pero el A es 1,000 veces más fácil de leer, mantener y modificar.

Las 5 reglas de oro del clean code

El costo del código sucio (la deuda técnica)

Deuda técnica es la acumulación de decisiones de código que hoy son rápidas pero mañana costarán tiempo arreglar. Cada vez que escribes un nombre críptico, una función enorme, o un comentario obsoleto, estás contrayendo deuda.

Analogía: es como pedir dinero prestado. Te resuelve el problema hoy, pero mañana pagas intereses. Si no pagas, eventualmente quiebras.

1.8.2 — Nomenclatura profesional: variables, constantes, funciones, clases

Las reglas de nombres que se siguen en la industria

Ya vimos las reglas básicas en el Tema 1.5. Ahora vamos a las convenciones profesionales que usan empresas reales:

Variables

Constantes

Regla: MAYÚSCULAS_CON_GUIONES_BAJOS, descriptivas, agrupadas al inicio del archivo.

Funciones

Reglas para nombres de funciones:

• Empieza con un verbo (calcular, obtener, validar, imprimir, buscar, crear, eliminar).
• Sé específico: obtenerUsuarioPorID mejor que obtenerUsuario.
• Si la función retorna un booleano, usa pregunta: esValido, tienePermisos, puedeEditar.

Clases

Regla: PascalCase, sustantivo singular (una clase = un concepto).

Regla de longitud

1.8.3 — Funciones limpias: pequeñas, con una sola responsabilidad, pocos argumentos

La regla de oro

*"Una función debe hacer UNA cosa. Debe hacerla bien. Debe ser lo único que haga."* — Robert C. Martin, *Clean Code*

Si tu función hace más de una cosa, divídela en funciones más pequeñas.

El antes y el después

❌ Función "sucia" (hace 5 cosas):

void procesarEstudiante(string nombre, int edad, double calificaciones[], int n) {

// 1. Validar entradas

if (nombre == "" || edad < 0 || edad > 150) {
cout << "Datos inválidos" << endl;

return;

}

// 2. Calcular promedio

double suma = 0;

for (int i = 0; i < n; i++) {

suma += calificaciones[i];

}

double promedio = suma / n;

// 3. Determinar aprobado/reprobado

bool aprobado = promedio >= 7;

// 4. Imprimir reporte

cout << "Nombre: " << nombre << endl;
cout << "Edad: " << edad << endl;
cout << "Promedio: " << promedio << endl;
cout << "Estado: " << (aprobado ? "Aprobado" : "Reprobado") << endl;

}

✅ Funciones "limpias" (cada una hace 1 cosa):

bool sonDatosValidos(string nombre, int edad) {

return !nombre.empty() && edad >= 0 && edad <= 150;

}

double calcularPromedio(double calificaciones[], int n) {

double suma = 0;

for (int i = 0; i < n; i++) {

suma += calificaciones[i];

}

return suma / n;

}

bool esAprobado(double promedio) {

return promedio >= 7;

}

void imprimirReporte(string nombre, int edad, double promedio, bool aprobado) {

cout << "Nombre: " << nombre << endl;
cout << "Edad: " << edad << endl;
cout << "Promedio: " << promedio << endl;
cout << "Estado: " << (aprobado ? "Aprobado" : "Reprobado") << endl;

}

void procesarEstudiante(string nombre, int edad, double calificaciones[], int n) {

if (!sonDatosValidos(nombre, edad)) {
cout << "Datos inválidos" << endl;

return;

}

double promedio = calcularPromedio(calificaciones, n);

bool aprobado = esAprobado(promedio);

imprimirReporte(nombre, edad, promedio, aprobado);

}

Cada función ahora:

• Hace UNA cosa.
• Tiene un nombre que describe QUÉ hace.
• Es fácil de testear por separado.
• Es fácil de reusar en otro programa.

El número de argumentos

❌ Función con 5 argumentos:

double calcularCosto(string tipo, double distancia, int numPasajeros, double tarifaBase, double descuento);

✅ Mejor: agrupar en una struct o clase:

struct Viaje {

string tipo;

double distancia;

int numPasajeros;

double tarifaBase;

double descuento;

};

double calcularCosto(Viaje v);

1.8.4 — Indentación, espacios y formato consistente

Las 5 reglas de formato

Ejemplo de formato consistente

#include <iostream>
using namespace std;

const int MAX_INTENTOS = 3;

int leerEdad() {

int edad;

cout << "Edad: ";
cin >> edad;
return edad;

}

bool esValida(int edad) {

return edad >= 0 && edad <= 150;

}

int main() {

int edad;

int intentos = 0;

do {

edad = leerEdad();

intentos++;

} while (!esValida(edad) && intentos < MAX_INTENTOS);
if (esValida(edad)) {
cout << "Edad válida: " << edad << endl;
} else {
cout << "Demasiados intentos" << endl;

}

return 0;

}

Configurar VS Code para formatear automáticamente

1. Instala la extensión C/C++ (ya la tienes del Tema 1.6).
2. Instala la extensión Clang-Format (opcional pero recomendada).
3. Activa "Format On Save" en Archivo → Preferencias → Configuración.
4. Ahora cada vez que guardes (Ctrl + S), VS Code formatea tu código automáticamente.

El .editorconfig

Para mantener el formato consistente en todo el equipo, crea un archivo .editorconfig en la raíz de tu proyecto:

root = true

[*]

indent_style = space

indent_size = 4

end_of_line = lf

charset = utf-8

trim_trailing_whitespace = true

insert_final_newline = true

[*.{cpp,h,hpp,java,py}]

indent_size = 4

1.8.5 — Comentarios efectivos: cuándo, qué, cómo

La regla de oro

*"El código bueno se documenta a sí mismo. Los comentarios son para lo que el código NO puede decir."* — Robert C. Martin

Qué SÍ comentar

✅ La intención (el "por qué"):

// Usamos búsqueda lineal porque la lista tiene menos de 100 elementos

// y la búsqueda binaria no compensa el ordenamiento previo.

for (int i = 0; i < n; i++) {
if (lista[i] == objetivo) return i;

}

✅ Advertencias o cosas a tener en cuenta:

// OJO: este loop puede tardar hasta 30 segundos con n > 100000

for (int i = 0; i < n; i++) {

operacionCostosa(i);

}

✅ Funciones públicas (qué hacen, qué reciben, qué devuelven):

/**

• Calcula el promedio de una lista de calificaciones.
• @param calificaciones Arreglo de calificaciones (0-10)
• @param n Número de calificaciones
• @return Promedio calculado, o 0 si n <= 0

*/

double calcularPromedio(double calificaciones[], int n) {

if (n <= 0) return 0;

double suma = 0;

for (int i = 0; i < n; i++) suma += calificaciones[i];
return suma / n;

}

✅ Expresiones regulares o algoritmos complejos:

// Regex para validar email: usuario@dominio.extension

// ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
regex emailPattern("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$");

Qué NO comentar

❌ Lo obvio (lo que el código ya dice):

// ❌ MAL

i++; // incrementa i en 1

cout << x;  // imprime x

// ✅ BIEN (sin comentario, o con intención)

i++; // Pasamos al siguiente estudiante

❌ Código comentado (código que ya no se usa):

// ❌ MAL: este código está "muerto"

// double calcularAntiguo(int x) {

//     return x * 2;

// }

double calcularNuevo(int x) {

return x * 2.5;

}

❌ Información que se desactualiza:

// ❌ MAL: este comentario era cierto hace 2 meses

// Esta función solo acepta números positivos

int calcular(int n) { // Ahora también acepta negativos

return n * 2;

}

❌ Ruido (separadores sin sentido):

// ❌ MAL

// ************************************

// * Función principal *

// ************************************

int main() { ... }

El balance

Un buen balance es:

• 1-2 líneas de comentario por cada 10-20 líneas de código.
• 1 línea de comentario por cada función pública (qué hace).
• 0 comentarios en el cuerpo de funciones obvias.

1.8.6 — Refactorización: cómo mejorar código que ya funciona

Qué es la refactorización

Refactorizar es mejorar la estructura interna del código sin cambiar su comportamiento externo. Es como reorganizar los muebles de una casa: la casa sigue siendo habitable, pero ahora todo está más accesible.

Cuándo refactorizar

4 técnicas básicas de refactorización

1. Renombrar (Extract/Inline):

• Renombrar variables, funciones, clases para que sean más claras.
• Extraer una variable: si una expresión es compleja, guárdala en una variable con nombre.

1. Extraer función:

• Si una función es muy larga, divídela en funciones más pequeñas.
• Cada función debe hacer UNA cosa.

1. Mover código:

• Si una función está en la clase equivocada, muévela.
• Si una constante está en el archivo equivocado, muévela.

1. Eliminar duplicación:

• Si tienes el mismo código en 2 lugares, hazlo una función y reúsala.

Ejemplo: refactorizar paso a paso

Versión 1 (la original del LAB 1.7):

int main() {

string nombre;

int edad;

cout << "Nombre: ";
cin >> nombre;
cout << "Edad: ";
cin >> edad;
if (edad < 0) {
cout << "Edad inválida" << endl;
return 1;

}

cout << "Hola " << nombre << ", tienes " << edad << " años" << endl;
return 0;

}

Versión 2 (refactorizada):

const int EDAD_MINIMA = 0;

const int EDAD_MAXIMA = 150;

string leerNombre() {

string nombre;

cout << "Nombre: ";
cin >> nombre;
return nombre;

}

int leerEdad() {

int edad;

cout << "Edad: ";
cin >> edad;
return edad;

}

bool esEdadValida(int edad) {

return edad >= EDAD_MINIMA && edad <= EDAD_MAXIMA;

}

void imprimirSaludo(string nombre, int edad) {

cout << "Hola " << nombre << ", tienes " << edad << " años" << endl;

}

int main() {

string nombre = leerNombre();

int edad = leerEdad();

if (!esEdadValida(edad)) {
cout << "Edad inválida" << endl;
return 1;

}

imprimirSaludo(nombre, edad);

return 0;

}

La versión 2:

• Tiene 4 funciones pequeñas en vez de 1 función grande.
• Usa constantes con nombre.
• Es más fácil de testear cada parte.
• Es más fácil de modificar (si cambia la validación, solo tocas esEdadValida).

La regla de "no agregar funcionalidad mientras refactorizas"

Refactorizar es mejorar la estructura, no agregar cosas nuevas. Si quieres agregar una funcionalidad y refactorizar al mismo tiempo, vas a confundir bugs nuevos con bugs del refactor.

1.8.7 — Git: qué es, instalación, conceptos básicos

Qué es Git

Git es un sistema de control de versiones: lleva un registro de TODOS los cambios que haces a tus archivos a lo largo del tiempo. Te permite:

• Volver a una versión anterior si algo se rompe.
• Ver quién cambió qué línea y cuándo.
• Trabajar en equipo sin pisar el código del otro.
• Tener un respaldo en la nube (con GitHub).
• Demostrar tu progreso a un reclutador (un GitHub activo vale más que un CV).

Analogía: Git es como el "historial de versiones" de Google Docs, pero para código.

Por qué es la skill #1 pedida a un junior

Según el análisis de ofertas que hicimos en el Tema 1.1, Git/GitHub es la skill técnica #1 más pedida a un Desarrollador Junior en México. No saber Git te deja fuera del mercado laboral moderno.

Cómo instalar Git

En Windows:

1. Ve a [https://git-scm.com/download/win](https://git-scm.com/download/win).
2. Descarga el instalador.
3. Ejecuta y deja las opciones por defecto (recomendado para principiantes).
4. Verifica abriendo una terminal y escribiendo: git --version.

Alternativa con winget:

winget install -e --id Git.Git

En Mac:

brew install git

# o

xcode-select --install

En Linux (Debian/Ubuntu):

sudo apt install git

Configuración inicial (obligatoria)

Después de instalar, dile a Git quién eres:

git config --global user.name "Tu Nombre Completo"

git config --global user.email "tu.correo@example.com"

Este nombre y correo aparecerán en todos tus commits (es como tu firma digital).

Los 5 comandos que vas a usar el 90% del tiempo

Tu primer repositorio local (paso a paso)

Paso 1: Abre la terminal de VS Code en tu carpeta de proyecto.

Paso 2: Inicializa Git:

git init

Verás: Initialized empty Git repository in C:/Dev/.../proyectos/calculadora/.git/

Paso 3: Verifica el estado:

git status

Verás: Untracked files: ... (tus archivos todavía no están siendo seguidos).

Paso 4: Agrega los archivos al "staging area":

git add .

El . significa "todos los archivos de la carpeta".

Paso 5: Haz el primer commit:

git commit -m "Primer commit: estructura inicial del proyecto"

Verás un mensaje confirmando el commit con un hash único.

Los mensajes de commit

Los mensajes de commit son cartas a tu yo del futuro (y a tus compañeros). Buenos mensajes:

✅ Buenos mensajes:

• "Agrega función calcularPromedio"
• "Corrige bug en validación de edad (negativa pasaba el filtro)"
• "Refactoriza: extrae función imprimirReporte"
• "Actualiza README con instrucciones de instalación"
• "Agrega tests para validar entrada"

❌ Malos mensajes:

• "cambios" (¿qué cambios?)
• "fix" (¿qué arreglaste?)
• "asdf" (irrelevante)
• "versión final" (no existe tal cosa)
• "ya funciona" (¿qué funciona?)

El flujo diario con Git

# Al empezar a trabajar:

git status # ¿qué cambió desde la última vez?

git pull # bajar cambios del remoto (si trabajas en equipo)

# Mientras trabajas:

# ... edita archivos ...

git status # ver qué archivos cambiaron

git diff # ver QUÉ líneas cambiaron (opcional)

# Al terminar una "feature":

git add . # agregar todo

git commit -m "Mensaje claro" # guardar

# Al final del día o cuando termines:

git push # subir a GitHub

1.8.8 — GitHub: cuenta, repositorio remoto, conexión con VS Code

Qué es GitHub

GitHub es una plataforma en la nube que aloja repositorios Git. Es como Google Drive, pero para código. Tiene:

• Alojamiento gratuito para repositorios públicos y privados.
• Interfaz web para revisar código.
• Pull requests para colaborar.
• Issues para trackear tareas y bugs.
• GitHub Pages para hosting gratuito.
• Integración con VS Code.

Cómo crear una cuenta

1. Ve a [https://github.com/](https://github.com/).
2. Haz clic en "Sign up".
3. Usa tu correo institucional si eres estudiante (muchas escuelas dan packs especiales).
4. Elige un nombre de usuario profesional: nada de "xxgatito123xx". Usa tu-nombre-apellido o tu-nombre-dev.
5. Confirma tu correo.

Crear un repositorio remoto

1. Una vez logueado, haz clic en el + (esquina superior derecha) → "New repository".
2. Nombre: curso-programacion-junior (o el nombre de tu proyecto).
3. Descripción: "Proyectos del curso de programación junior - Capítulo 1".
4. Público (visible para todos, bueno para tu portafolio) o Privado (solo para ti).
5. NO inicialices con README ni .gitignore (ya los vas a crear tú).
6. Haz clic en "Create repository".

Conectar tu repositorio local con GitHub

Después de crear el remoto, GitHub te da instrucciones. Las más comunes:

Si ya tienes un repositorio local (como en el paso anterior):

git remote add origin https://github.com/TU-USUARIO/curso-programacion-junior.git

git branch -M main

git push -u origin main

Si NO tienes repositorio local todavía:

git clone https://github.com/TU-USUARIO/curso-programacion-junior.git

cd curso-programacion-junior

# ... crear archivos ...

git add .

git commit -m "Primer commit"

git push -u origin main

VS Code + GitHub: autenticación

VS Code se integra con GitHub de manera transparente:

1. Abre VS Code.
2. Abre la paleta de comandos (Ctrl + Shift + P).
3. Escribe "Git: Sign in to GitHub".
4. Sigue las instrucciones (te abre el navegador para autorizar).
5. Una vez conectado, puedes hacer todo desde VS Code sin tocar la terminal.

Operaciones frecuentes en VS Code:

• Ver cambios: Panel "Control de código fuente" (icono de rama en la barra lateral).
• Stage cambios: Clic en + al lado del archivo.
• Commit: Escribe mensaje en el cuadro y presiona Ctrl + Enter.
• Push/Pull: Botones en la barra inferior o paleta de comandos.
• Ver historial: Click derecho en un archivo → "Open Git History".

1.8.9 — README.md: cómo documentar un proyecto

Qué es un README

README.md es un archivo Markdown en la raíz de tu proyecto que le dice a cualquiera (incluido tú en 6 meses) qué es el proyecto, cómo usarlo, y cómo contribuir. Es la "portada" de tu repositorio.

La estructura recomendada

# Nombre del Proyecto

Descripción breve en una línea de qué hace.

## Descripción

Explicación más detallada: qué problema resuelve, para quién es, qué tecnologías usa.

## Instalación

Requisitos previos y pasos para instalar.

## Uso

Cómo ejecutar el programa, con ejemplos.

## Características

Lista de lo que puede hacer el programa.

## Tecnologías

Lenguajes, frameworks, librerías usadas.

## Estructura del proyecto

Descripción de las carpetas y archivos principales.

## Autor

Tu nombre y cómo contactarte.

## Licencia

MIT, GPL, Apache 2.0, o "solo para uso educativo".

Ejemplo real: README para la calculadora del Boss 1

# 🧮 Calculadora de Calificaciones

Una aplicación de consola en C++ que calcula el promedio, la calificación más alta, la más baja y el número de aprobados/reprobados de un grupo de N alumnos.

## 📋 Descripción

Este proyecto es la evaluación final (Boss 1) del Capítulo 1 del curso de Programación Junior. Permite al usuario capturar las calificaciones de N alumnos y obtener estadísticas del grupo.

## ⚙️ Instalación

### Requisitos previos

• Compilador g++ (MinGW-w64 en Windows, gcc en Linux, clang en Mac)
• Git (opcional, para clonar el repositorio)

### Pasos

1. Clona el repositorio:

git clone https://github.com/TU-USUARIO/calculadora-calificaciones.git cd calculadora-calificaciones ```

1. Compila el programa:

g++ main.cpp -o calculadora.exe

1. Ejecuta:

./calculadora.exe

🚀 Uso

Al ejecutar, el programa pide:

1. El número de alumnos (N).
2. Para cada alumno, su nombre y sus 3 calificaciones.
3. Al final, muestra: promedio general, calificación más alta, más baja, número de aprobados y reprobados.

Ejemplo de salida:

=================================

Calculadora de Calificaciones

=================================

Número de alumnos: 3

Nombre del alumno 1: Ana

Calificación 1: 9

Calificación 2: 8

Calificación 3: 10

...

=================================

Resumen del grupo

=================================

Promedio general: 8.50

Calificación más alta: 10.00

Calificación más baja: 6.00

Aprobados: 2 de 3

Reprobados: 1 de 3

🛠️ Tecnologías

• C++11
• Compilador g++ 13.2.0
• Markdown para documentación
• Git para control de versiones

📂 Estructura del proyecto

calculadora-calificaciones/

├── main.cpp # Programa principal

├── README.md # Este archivo

├── .gitignore # Archivos ignorados por Git

└── bitacora/ # Carpeta con las notas a mano del proceso

✍️ Autor

[Tu Nombre] — [tu.correo@example.com](mailto:tu.correo@example.com)

📄 Licencia

Este proyecto es solo para uso educativo. © 2026.

> Anota en tu cuaderno: escribe el README del proyecto del Boss 1. Pega aquí solo la estructura general con placeholders.

---

## 1.8.10 — .gitignore: qué subir y qué no subir

### Qué es un .gitignore

Es un archivo de texto que le dice a Git: "estos archivos/carpetas NO los rastrees, NO los subas al remoto". Sirve para no contaminar el repositorio con archivos generados, binarios o personales.

### Qué NO se debe subir a un repositorio

| Tipo | Ejemplos | Por qué no |

|------|----------|-------------|

| Archivos compilados | `*.exe`, `*.o`, `*.class`, `*.pyc` | Se pueden regenerar; pesan mucho |

| Carpetas de build | `build/`, `dist/`, `target/`, `bin/`, `obj/` | Generadas automáticamente |

| Archivos de IDE | `.vscode/`, `.idea/`, `*.swp`, `*.swo` | Configuraciones personales |

| Archivos temporales | `*.tmp`, `*.bak`, `*.log`, `*.swp` | No aportan al código |

| Credenciales | `.env`, `config.json` con claves | ¡PELIGRO! Secretos filtrados |

| Archivos del sistema | `.DS_Store` (Mac), `Thumbs.db` (Windows) | Basura del SO |

### El .gitignore típico para un proyecto C++

.exe .o .obj .out .a .so *.dll

build/ bin/ obj/ dist/ target/

.vscode/ .idea/ .swp .swo *.swn

.tmp .bak .log .DS_Store Thumbs.db

.gcda .gcno

### El .gitignore típico para Python

__pycache__/ .pyc .pyo *.egg-info/ venv/ .env

### Cómo crear el .gitignore

1. En la raíz de tu proyecto, crea un archivo llamado `.gitignore` (con el punto al inicio, sin extensión).
2. Pega el contenido apropiado para tu lenguaje.
3. `git add .gitignore`
4. `git commit -m "Agrega .gitignore"`
5. Git ya no rastreará esos archivos.

> Anota en tu cuaderno: crea el .gitignore para tu proyecto. Haz `git status` antes y después de agregarlo. ¿Qué archivos desaparecieron de la lista?

---

## 🤖 AI Mission 1.8 — Refactorización asistida con prompts

> Regla de los 3 minutos: primero intenta refactorizar por tu cuenta. Si después de 3 minutos no avanzas, primero relee la teoría, luego consulta tu cuaderno, luego consulta la IA.

### Prompts sugeridos

Prompt 1 — Detectar código "sucio":

> "Te voy a pegar un programa en C++/Java/Python. NO me corrijas el código. Solo dime: (1) ¿qué partes son difíciles de leer? (2) ¿qué nombres son malos? (3) ¿qué funciones hacen más de una cosa? (4) ¿qué buenas prácticas no se siguen? Sé concreto, máximo 250 palabras."

Prompt 2 — Sugerir nombres mejores:

> "Te voy a pegar una lista de nombres de variables que usé en mi código. NO me digas qué hacen. Solo sugiéreme mejores nombres según las buenas prácticas: claridad, descriptivo, sin abreviaciones. Máximo 100 palabras."

Prompt 3 — Encontrar funciones que hacen mucho:

> "Te voy a pegar una función. NO me la dividas. Solo dime: ¿cuántas cosas hace? Sugiere nombres para las sub-funciones en que se dividiría. NO me des el código, solo los nombres. Máximo 150 palabras."

Prompt 4 — Mensaje de commit:

> "Te voy a pegar un diff (cambios) que hice en mi código. NO me expliques los cambios. Solo sugiéreme un mensaje de commit profesional, en español, en imperativo, máximo 50 caracteres en la primera línea. Máximo 50 palabras."

Prompt 5 — Mejorar el README:

> "Te voy a pegar el README.md de mi proyecto. NO me reescribas el README. Solo dime: (1) qué secciones faltan, (2) qué partes son confusas, (3) qué información técnica no es clara. Máximo 200 palabras."

---

## ❌ Errores típicos del razonamiento

### Error 1: "Clean code es pura estética, no importa"

Idea equivocada: "Si el código funciona, ¿para qué renombrar variables o dividir funciones?"

Realidad: un junior que entrega código limpio es 3 veces más rápido en code reviews y en su primera tarea de trabajo. Las empresas modernas (Google, Microsoft, Mercado Libre) rechazan candidatos cuyo código "huele".

Cómo evitarlo: desde el primer programa, aplica las 5 reglas de oro.

### Error 2: "Comentarios en todo, mejor que falta de comentarios"

Idea equivocada: "Es mejor comentar de más que de menos."

Realidad: comentarios innecesarios (que dicen lo obvio) son ruido. Un código con 30% de comentarios obvios es más difícil de leer que un código con 0% de comentarios pero nombres claros.

Cómo evitarlo: comenta solo la INTENCIÓN. Si el código se entiende solo, no comentes.

### Error 3: "Las funciones largas son más eficientes"

Idea equivocada: "Llamar a una función toma tiempo. Mejor pongo todo en main."

Realidad: la diferencia de performance entre una función larga y 5 funciones pequeñas es despreciable (nanosegundos). La diferencia de MANTENIMIENTO es enorme (3 veces más fácil de leer y modificar).

Cómo evitarlo: divide. La optimización prematura es la raíz de muchos males.

### Error 4: "Git es complicado, mejor lo uso solo para el final"

Idea equivocada: "Voy a empezar a usar Git cuando termine el proyecto."

Realidad: Git debe usarse desde el primer commit. Si lo usas solo al final, no tienes historial, no puedes volver atrás, y si pierdes el código antes del push, perdiste todo.

Cómo evitarlo: `git init` el primer día de cualquier proyecto. Commit por cada feature pequeña.

### Error 5: "Subir binarios al repositorio es buena idea"

Idea equivocada: "Si compilé el .exe, lo subo para que otros lo descarguen."

Realidad: los binarios pesan mucho, no se pueden leer, cambian cada vez que compilas, y el repositorio se vuelve lento. El código fuente es lo único que va en Git. Los binarios se generan o se distribuyen por separado (Releases de GitHub, por ejemplo).

Cómo evitarlo: usa .gitignore correctamente. Nunca subas `*.exe`, `*.o`, `build/`, etc.

---

## 🧪 LAB 1.8 — Setup profesional del proyecto

Tiempo total: 1 h 30 min | Entregable: un proyecto con Git + GitHub + README.md + .gitignore + commits limpios.

### Ejercicio 1 — Refactoriza un programa del LAB 1.7 (básico, 25 min)

Enunciado. Toma el programa de IMC o el conversor de unidades del LAB 1.7 y refactorízalo siguiendo las reglas de clean code:

• Nombres descriptivos.
• Funciones pequeñas con un solo propósito.
• Comentarios de intención (no de qué).
• Constantes nombradas.

Criterio de éxito: el programa refactorizado compila, hace lo mismo, y es más fácil de leer.

Rúbrica (10 pts): nombres (3 pts) + funciones pequeñas (3 pts) + comentarios de intención (2 pts) + formato (2 pts).

### Ejercicio 2 — Inicializa Git en tu proyecto (básico, 20 min)

Enunciado. En la carpeta del proyecto del ejercicio anterior, inicializa Git y haz 5 commits progresivos:

1. `"Agrega estructura inicial del programa"`
2. `"Refactoriza: extrae función calcularIMC"`
3. `"Refactoriza: extrae función obtenerClasificacion"`
4. `"Agrega comentarios de intención"`
5. `"Corrige bug en validación de entradas negativas"`

Criterio de éxito: los 5 commits están en el historial con mensajes claros.

Rúbrica (10 pts): 5 commits × 1.5 pts + mensaje claro de cada uno (2.5 pts).

### Ejercicio 3 — Crea el .gitignore (básico, 10 min)

Enunciado. Crea un archivo `.gitignore` para tu proyecto C++ con al menos 10 reglas.

Criterio de éxito: el archivo existe, tiene 10+ reglas relevantes, y `git status` después de agregarlo muestra menos archivos no rastreados.

Rúbrica (10 pts): 10 reglas (5 pts) + verificación con `git status` (5 pts).

### Ejercicio 4 — Crea el README.md (intermedio, 20 min)

Enunciado. Escribe un README.md profesional para tu proyecto con todas las secciones de la estructura recomendada.

Criterio de éxito: tiene al menos 7 secciones (descripción, instalación, uso, características, tecnologías, estructura, autor).

Rúbrica (10 pts): 7 secciones (5 pts) + formato Markdown correcto (2 pts) + ejemplo de uso (3 pts).

### Ejercicio 5 — Sube el proyecto a GitHub (avanzado, 15 min)

Enunciado. Crea una cuenta de GitHub, crea un repositorio remoto, conecta tu proyecto local, y haz push de los 5 commits. Captura la pantalla del repositorio en GitHub.

Criterio de éxito: los 5 commits aparecen en GitHub con sus mensajes, y el README se ve bien renderizado.

Rúbrica (10 pts): cuenta creada (1 pt) + repo creado (2 pts) + remoto conectado (2 pts) + 5 commits subidos (3 pts) + README renderiza bien (2 pts).

### Ejercicio bonus — Configura VS Code con tu GitHub (opcional, 20 min)

Enunciado. Conecta VS Code con tu cuenta de GitHub. Verifica que puedes hacer commit, push y pull desde VS Code sin tocar la terminal.

Rúbrica bonus (5 pts): conexión exitosa (2 pts) + flujo de trabajo desde VS Code (3 pts).

---

## 📝 Quest 1.8 — Autoevaluación

### Sección A — Opción múltiple

1. ¿Cuál de estos nombres de variable es MEJOR según clean code?

• A) `x`
• B) `n`
• C) `numeroIntentos`
• D) `n_int`

2. ¿Cuántas cosas debe hacer una función según clean code?

• A) Todas las que estén relacionadas
• B) Una sola cosa, bien hecha
• C) Máximo 3
• D) Depende del tamaño

3. ¿Qué tipo de comentario es MEJOR?

• A) `i++; // incrementa i`
• B) `i++; // Pasamos al siguiente alumno`
• C) `// Esta función hace cosas con números`
• D) `/* ********************************* */`

4. ¿Cuál es el comando para hacer un commit en Git?

• A) `git save`
• B) `git commit -m "mensaje"`
• C) `git push`
• D) `git upload`

5. ¿Qué hace `git add .`?

• A) Sube los cambios al remoto
• B) Marca todos los archivos de la carpeta actual para el próximo commit
• C) Crea un nuevo repositorio
• D) Elimina los archivos

6. ¿Para qué sirve un archivo .gitignore?

• A) Para ignorar todos los archivos
• B) Para decirle a Git qué archivos NO rastrear
• C) Para comprimir el repositorio
• D) Para hacer commits más rápido

7. ¿Cuál es la estructura recomendada de un README?

• A) Solo título
• B) Descripción, instalación, uso
• C) Título, descripción, instalación, uso, tecnologías, autor, licencia
• D) No es necesario un README

8. ¿Por qué NO se debe subir el archivo `.exe` al repositorio?

• A) Es obligatorio
• B) Porque es un binario, se puede regenerar, y hace el repo pesado
• C) Porque Git no lo permite
• D) No hay razón, sí se puede

9. ¿Cuándo se debe hacer un commit?

• A) Solo al final del proyecto
• B) Después de cada feature pequeña o cambio lógico
• C) Una vez al día
• D) Cuando te acuerdes

10. ¿Por qué Git es importante para un junior?

• A) No es importante, es opcional
• B) Es la skill #1 más pedida en ofertas de trabajo junior
• C) Solo lo usan los seniors
• D) Solo para proyectos grandes

### Sección B — Preguntas abiertas

11. Explica con tus palabras qué es la deuda técnica y por qué las buenas prácticas de clean code ayudan a prevenirla. Da 2 ejemplos concretos.

12. Tienes un programa con una función `main` de 80 líneas que hace todo. ¿Cómo lo refactorizarías? Escribe los nombres de las funciones que extraerías y qué haría cada una.

13. ¿Por qué los mensajes de commit son importantes? Escribe 3 ejemplos de BUENOS mensajes y 3 de MALOS mensajes, justificando cada uno.

---

## ✅ Respuestas modelo — Quest 1.8

### Sección A

1. C — `numeroIntentos`.
2. B — Una sola cosa, bien hecha.
3. B — `i++; // Pasamos al siguiente alumno` (intención).
4. B — `git commit -m "mensaje"`.
5. B — Marca todos los archivos.
6. B — Decirle a Git qué NO rastrear.
7. C — Estructura completa.
8. B — Binarios, regenerables, pesados.
9. B — Después de cada feature pequeña.
10. B — Skill #1 pedida en ofertas.

### Sección B (modelos)

11. (Modelo) La deuda técnica es como la deuda financiera: son decisiones que tomas HOY para resolver el problema rápido, pero que mañana te van a cobrar intereses en forma de horas extra de trabajo. Ejemplos: (1) Nombrar variables con letras (`x`, `n`, `aux`) en vez de nombres descriptivos. Hoy escribes el código en 5 minutos, pero cuando vuelvas en 2 meses (o un compañero), vas a tardar 30 minutos en entender qué hace cada variable. (2) Poner toda la lógica en `main` en vez de dividir en funciones. Hoy lo escribes rápido, pero cuando llegue un cambio (nueva validación, nuevo cálculo), vas a tener que modificar 50 líneas enredadas en vez de 1 función específica. Las buenas prácticas de clean code previenen esto: nombres claros, funciones pequeñas, comentarios de intención. Es más trabajo al inicio, pero te ahorra horas en el futuro.

12. (Modelo) Refactorizaría el main extrayendo: (1) `leerNombre()`: pide y valida el nombre. (2) `leerCalificaciones(int n)`: pide N calificaciones y las valida (entre 0 y 10). (3) `calcularPromedio(double[] notas, int n)`: calcula el promedio. (4) `encontrarMaximo(double[] notas, int n)`: encuentra la más alta. (5) `encontrarMinimo(double[] notas, int n)`: encuentra la más baja. (6) `contarAprobados(double[] notas, int n)`: cuenta los >= 7. (7) `imprimirReporte(...)`: imprime los resultados formateados. (8) `main` solo orquesta: llama a las funciones en orden y muestra el resultado.

13. (Modelo) Los mensajes de commit son la HISTORIA de tu proyecto. Cuando vuelvas en 6 meses (o un reclutador revise tu GitHub), los commits son la forma más rápida de entender qué hiciste, por qué, y cuándo. Buenos mensajes: (1) `"Agrega validación de edad negativa"` — claro, específico, indica la acción y el porqué. (2) `"Refactoriza: extrae función calcularPromedio"` — indica el cambio estructural. (3) `"Corrige bug en división por cero"` — explica el problema y la corrección. Malos mensajes: (1) `"cambios"` — no dice nada. (2) `"fix"` — ¿qué arreglaste? (3) `"ya funciona"` — ¿qué funciona? ¿qué condiciones?

---

## 🎯 Cierre del tema

Lo que aprendiste hoy:

• Las 5 reglas de oro del clean code.
• Nomenclatura profesional para variables, constantes, funciones, clases.
• Cómo escribir funciones pequeñas con un solo propósito.
• Cómo formatear código consistentemente.
• Cómo comentar efectivamente (intención, no descripción).
• Git: init, add, commit, status, push.
• GitHub: crear cuenta, repositorio remoto, conexión con VS Code.
• README.md profesional.
• .gitignore.

Lo que sigue: el Boss Final 1: Calculadora de Calificaciones. Vas a aplicar TODO lo aprendido en el Capítulo 1: algoritmos, pseudocódigo, variables, tipos, operadores, E/S, clean code, Git, README. Es el examen final del capítulo. Si lo apruebas, recibes la insignia *PixelForge Certified Junior Trainee* y asciendes a DEV-J2 para el Capítulo 2.

Antes de seguir, asegúrate de tener en tu cuaderno:

• [ ] Programa refactorizado del LAB 1.8.
• [ ] Repositorio local con 5 commits.
• [ ] Repositorio en GitHub con README.md y .gitignore.
• [ ] Glosario con: clean code, deuda técnica, nomenclatura, refactorización, Git, GitHub, commit, push, README, .gitignore, KISS, DRY.

XP obtenida al completar este tema: 100 base + 30 por LAB + 20 por Quest = 150 XP.

Insignia desbloqueada al cerrar el capítulo: *Clean Coder* (parcial).

> *"El código se lee más veces de las que se escribe. Si te da flojera ponerle nombre a una variable, imagina a tu yo del futuro leyendo ese código a las 3 AM con un bug en producción."*

> — De la introducción de este manual.

---

Fin del Tema 1.8

📝 Quest · Cuestionario — 📝 Quest — Reactivos para autoevaluación

Sección A · Opción múltiple

Elige la opción correcta (A, B, C o D). Las respuestas están en la sección Respuestas modelo.

1. ¿Qué es Git?
   • Un lenguaje
   • Un sistema de control de versiones distribuido
   • Un editor
   • Una base de datos
2. ¿Qué comando inicia un repositorio Git?
   • git start
   • git init
   • git create
   • git new
3. ¿Qué hace git add?
   • Confirma cambios
   • Agrega archivos al staging area
   • Sube al remoto
   • Crea rama
4. ¿Qué hace git commit?
   • Sube al servidor
   • Guarda los cambios del staging en el historial local
   • Borra archivos
   • Crea rama
5. ¿Qué hace git push?
   • Borra
   • Sube los commits locales al repositorio remoto
   • Hace commit
   • Crea archivo
6. ¿Qué es una rama (branch) en Git?
   • Una copia del proyecto
   • Un apuntador a un commit que avanza con nuevos commits
   • Un archivo
   • Un commit
7. ¿Qué hace git pull?
   • Borra el remoto
   • Descarga y fusiona cambios del remoto al local
   • Crea commit
   • Borra rama
8. ¿Cuál es la diferencia entre git merge y git rebase?
   • Son iguales
   • merge preserva historia, rebase la reescribe linealmente
   • rebase es más rápido
   • merge borra commits
9. ¿Qué es clean code según Robert C. Martin?
   • Sin comentarios
   • Código legible, mantenible, con buenas prácticas
   • Solo compila
   • Sin tests
10. ¿Por qué son importantes los commits pequeños y frecuentes?
    • Ocupan menos espacio
    • Facilitan el code review, revert y el seguimiento de bugs
    • Son más rápidos
    • No son importantes

Sección B · Preguntas abiertas

Desarrolla tu respuesta en al menos 3 líneas. Compara con la respuesta modelo después de escribir.

1. Explica el flujo de Git: working directory, staging area, repository. ¿Qué comandos mueven entre estas zonas?
   → Escribe tu respuesta aquí (en tu cuaderno o mentalmente)…
2. ¿Qué es un buen mensaje de commit? Da un ejemplo bueno y uno malo.
   → Escribe tu respuesta aquí (en tu cuaderno o mentalmente)…
3. ¿Por qué es importante hacer commits pequeños y frecuentes en lugar de uno grande al final?
   → Escribe tu respuesta aquí (en tu cuaderno o mentalmente)…