Estándares de Codificación C++

Estándares de Codificación C++ (C++ Core Guidelines)

Estándares de codificación completos para C++ moderno (C++17/20/23) derivados de las C++ Core Guidelines. Aplica seguridad de tipos, seguridad de recursos, inmutabilidad y claridad.

Cuándo Usar

• Escribir código C++ nuevo (clases, funciones, plantillas)
• Revisar o refactorizar código C++ existente
• Tomar decisiones arquitectónicas en proyectos C++
• Aplicar un estilo consistente en un código base C++
• Elegir entre características del lenguaje (ej., enum vs enum class, puntero crudo vs puntero inteligente)

Cuándo NO Usar

• Proyectos que no sean C++
• Código base C heredado que no pueda adoptar características modernas de C++
• Contextos embebidos/sin sistema operativo donde guías específicas entren en conflicto con restricciones de hardware (adaptar selectivamente)

Principios Transversales

Estos temas se repiten en todas las guías y forman la base:

1. RAII en todas partes (P.8, R.1, E.6, CP.20): Vincular la vida del recurso a la vida del objeto
2. Inmutabilidad por defecto (P.10, Con.1-5, ES.25): Comenzar con const/constexpr; la mutabilidad es la excepción
3. Seguridad de tipos (P.4, I.4, ES.46-49, Enum.3): Usar el sistema de tipos para prevenir errores en tiempo de compilación
4. Expresar intención (P.3, F.1, NL.1-2, T.10): Nombres, tipos y conceptos deben comunicar propósito
5. Minimizar complejidad (F.2-3, ES.5, Per.4-5): El código simple es código correcto
6. Semántica de valor sobre semántica de puntero (C.10, R.3-5, F.20, CP.31): Preferir devolver por valor y objetos con ámbito

Filosofía e Interfaces (P., I.)

Reglas Clave

Regla	Resumen
P.1	Expresar ideas directamente en código
P.3	Expresar intención
P.4	Idealmente, un programa debe ser estáticamente seguro en tipos
P.5	Preferir comprobación en tiempo de compilación a comprobación en tiempo de ejecución
P.8	No filtrar ningún recurso
P.10	Preferir datos inmutables a datos mutables
I.1	Hacer las interfaces explícitas
I.2	Evitar variables globales no constantes
I.4	Hacer las interfaces precisa y fuertemente tipadas
I.11	Nunca transferir propiedad mediante un puntero crudo o referencia
I.23	Mantener bajo el número de argumentos de función

HACER

// P.10 + I.4: Interfaz inmutable fuertemente tipada
struct Temperature {
    double kelvin;
};

Temperature boil(const Temperature& water);

NO HACER

// Interfaz débil: propiedad poco clara, unidades poco claras
double boil(double* temp);

// Variable global no constante
int g_counter = 0;  // violación I.2

Funciones (F.*)

Reglas Clave

Regla	Resumen
F.1	Empaquetar operaciones significativas como funciones cuidadosamente nombradas
F.2	Una función debe realizar una sola operación lógica
F.3	Mantener las funciones cortas y simples
F.4	Si una función puede evaluarse en tiempo de compilación, declararla constexpr
F.6	Si una función no debe lanzar excepciones, declararla noexcept
F.8	Preferir funciones puras
F.16	Para parámetros "de entrada", pasar tipos baratos de copiar por valor y otros por const&
F.20	Para valores "de salida", preferir valores de retorno a parámetros de salida
F.21	Para devolver múltiples valores "de salida", preferir devolver una estructura
F.43	Nunca devolver un puntero o referencia a un objeto local

Paso de Parámetros

// F.16: Tipos baratos por valor, otros por const&
void print(int x);                           // barato: por valor
void analyze(const std::string& data);       // costoso: por const&
void transform(std::string s);               // sumidero: por valor (se moverá)

// F.20 + F.21: Valores de retorno, no parámetros de salida
struct ParseResult {
    std::string token;
    int position;
};

ParseResult parse(std::string_view input);   // BIEN: devolver estructura

// MAL: parámetros de salida
void parse(std::string_view input,
           std::string& token, int& pos);    // evitar esto

Funciones Puras y constexpr

// F.4 + F.8: Pura, constexpr donde sea posible
constexpr int factorial(int n) noexcept {
    return (n <= 1) ? 1 : n * factorial(n - 1);
}

static_assert(factorial(5) == 120);

Anti-patrones

• Devolver T&& desde funciones (F.45)
• Usar va_arg / variádicos al estilo C (F.55)
• Capturar por referencia en lambdas pasadas a otros hilos (F.53)
• Devolver const T que inhibe la semántica de movimiento (F.49)

Clases y Jerarquías de Clases (C.*)

Reglas Clave

Regla	Resumen
C.2	Usar class si existe invariante; struct si los miembros de datos varían independientemente
C.9	Minimizar la exposición de miembros
C.20	Si puedes evitar definir operaciones predeterminadas, hazlo (Regla de Cero)
C.21	Si defines o =delete cualquier constructor copia/movimiento/destructor, manéjalos todos (Regla de Cinco)
C.35	Destructor de clase base: public virtual o protected no virtual
C.41	Un constructor debe crear un objeto completamente inicializado
C.46	Declarar constructores de un solo argumento como explicit
C.67	Una clase polimórfica debe suprimir copia/movimiento públicos
C.128	Funciones virtuales: especificar exactamente uno de virtual, override, o final

Regla de Cero

// C.20: Dejar que el compilador genere los miembros especiales
struct Employee {
    std::string name;
    std::string department;
    int id;
    // No se necesitan destructor, constructores copia/movimiento, ni operadores de asignación
};

Regla de Cinco

// C.21: Si debes gestionar un recurso, define los cinco
class Buffer {
public:
    explicit Buffer(std::size_t size)
        : data_(std::make_unique<char[]>(size)), size_(size) {}

    ~Buffer() = default;

    Buffer(const Buffer& other)
        : data_(std::make_unique<char[]>(other.size_)), size_(other.size_) {
        std::copy_n(other.data_.get(), size_, data_.get());
    }

    Buffer& operator=(const Buffer& other) {
        if (this != &other) {
            auto new_data = std::make_unique<char[]>(other.size_);
            std::copy_n(other.data_.get(), other.size_, new_data.get());
            data_ = std::move(new_data);
            size_ = other.size_;
        }
        return *this;
    }

    Buffer(Buffer&&) noexcept = default;
    Buffer& operator=(Buffer&&) noexcept = default;

private:
    std::unique_ptr<char[]> data_;
    std::size_t size_;
};

Jerarquía de Clases

// C.35 + C.128: Destructor virtual, usar override
class Shape {
public:
    virtual ~Shape() = default;
    virtual double area() const = 0;  // C.121: interfaz pura
};

class Circle : public Shape {
public:
    explicit Circle(double r) : radius_(r) {}
    double area() const override { return 3.14159 * radius_ * radius_; }

private:
    double radius_;
};

Anti-patrones

• Llamar a funciones virtuales en constructores/destructores (C.82)
• Usar memset/memcpy en tipos no triviales (C.90)
• Proporcionar argumentos predeterminados diferentes para una función virtual y su reemplazo (C.140)
• Hacer que los miembros de datos sean const o referencias, lo que suprime movimiento/copia (C.12)

Gestión de Recursos (R.*)

Reglas Clave

Regla	Resumen
R.1	Gestionar recursos automáticamente usando RAII
R.3	Un puntero crudo (T*) no posee
R.5	Preferir objetos con ámbito; no asignar en el montículo innecesariamente
R.10	Evitar malloc()/free()
R.11	Evitar llamar a new y delete explícitamente
R.20	Usar unique_ptr o shared_ptr para representar propiedad
R.21	Preferir unique_ptr sobre shared_ptr a menos que se comparta la propiedad
R.22	Usar make_shared() para crear shared_ptrs

Uso de Punteros Inteligentes

// R.11 + R.20 + R.21: RAII con punteros inteligentes
auto widget = std::make_unique<Widget>("config");  // propiedad única
auto cache  = std::make_shared<Cache>(1024);        // propiedad compartida

// R.3: Puntero crudo = observador no propietario
void render(const Widget* w) {  // NO posee w
    if (w) w->draw();
}

render(widget.get());

Patrón RAII

// R.1: La adquisición de recursos es inicialización
class FileHandle {
public:
    explicit FileHandle(const std::string& path)
        : handle_(std::fopen(path.c_str(), "r")) {
        if (!handle_) throw std::runtime_error("Error al abrir: " + path);
    }

    ~FileHandle() {
        if (handle_) std::fclose(handle_);
    }

    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;
    FileHandle(FileHandle&& other) noexcept
        : handle_(std::exchange(other.handle_, nullptr)) {}
    FileHandle& operator=(FileHandle&& other) noexcept {
        if (this != &other) {
            if (handle_) std::fclose(handle_);
            handle_ = std::exchange(other.handle_, nullptr);
        }
        return *this;
    }

private:
    std::FILE* handle_;
};

Anti-patrones

• new/delete directos (R.11)
• malloc()/free() en código C++ (R.10)
• Múltiples asignaciones de recursos en una sola expresión (R.13 -- peligro de seguridad de excepciones)
• shared_ptr donde unique_ptr es suficiente (R.21)

Expresiones y Sentencias (ES.*)

Reglas Clave

Regla	Resumen
ES.5	Mantener los ámbitos pequeños
ES.20	Inicializar siempre un objeto
ES.23	Preferir sintaxis de inicializador {}
ES.25	Declarar objetos const o constexpr a menos que se pretenda modificación
ES.28	Usar lambdas para inicialización compleja de variables const
ES.45	Evitar constantes mágicas; usar constantes simbólicas
ES.46	Evitar conversiones aritméticas de estrechamiento/con pérdida
ES.47	Usar nullptr en lugar de 0 o NULL
ES.48	Evitar conversiones de tipo
ES.50	No eliminar const con un cast

Inicialización

// ES.20 + ES.23 + ES.25: Siempre inicializar, preferir {}, por defecto const
const int max_retries{3};
const std::string name{"widget"};
const std::vector<int> primes{2, 3, 5, 7, 11};

// ES.28: Lambda para inicialización const compleja
const auto config = [&] {
    Config c;
    c.timeout = std::chrono::seconds{30};
    c.retries = max_retries;
    c.verbose = debug_mode;
    return c;
}();

Anti-patrones

• Variables no inicializadas (ES.20)
• Usar 0 o NULL como puntero (ES.47 -- usar nullptr)
• Conversiones al estilo C (ES.48 -- usar static_cast, const_cast, etc.)
• Eliminar const con un cast (ES.50)
• Números mágicos sin constantes con nombre (ES.45)
• Mezclar aritmética con signo y sin signo (ES.100)
• Reutilizar nombres en ámbitos anidados (ES.12)

Manejo de Errores (E.*)

Reglas Clave

Regla	Resumen
E.1	Desarrollar una estrategia de manejo de errores temprano en el diseño
E.2	Lanzar una excepción para señalar que una función no puede realizar su tarea asignada
E.6	Usar RAII para prevenir fugas
E.12	Usar noexcept cuando lanzar sea imposible o inaceptable
E.14	Usar tipos definidos por el usuario diseñados específicamente como excepciones
E.15	Lanzar por valor, capturar por referencia
E.16	Los destructores, desasignación y swap nunca deben fallar
E.17	No intentar capturar cada excepción en cada función

Jerarquía de Excepciones

// E.14 + E.15: Tipos de excepción personalizados, lanzar por valor, capturar por referencia
class AppError : public std::runtime_error {
public:
    using std::runtime_error::runtime_error;
};

class NetworkError : public AppError {
public:
    NetworkError(const std::string& msg, int code)
        : AppError(msg), status_code(code) {}
    int status_code;
};

void fetch_data(const std::string& url) {
    // E.2: Lanzar para señalar fallo
    throw NetworkError("conexión rechazada", 503);
}

void run() {
    try {
        fetch_data("https://api.example.com");
    } catch (const NetworkError& e) {
        log_error(e.what(), e.status_code);
    } catch (const AppError& e) {
        log_error(e.what());
    }
    // E.17: No capturar todo aquí -- dejar que los errores inesperados se propaguen
}

Anti-patrones

• Lanzar tipos integrados como int o literales de cadena (E.14)
• Capturar por valor (riesgo de segmentación) (E.15)
• Bloques catch vacíos que tragan errores silenciosamente
• Usar excepciones para control de flujo (E.3)
• Manejo de errores basado en estado global como errno (E.28)

Constantes e Inmutabilidad (Con.*)

Todas las Reglas

Regla	Resumen
Con.1	Por defecto, hacer los objetos inmutables
Con.2	Por defecto, hacer las funciones miembro const
Con.3	Por defecto, pasar punteros y referencias a const
Con.4	Usar const para valores que no cambian después de la construcción
Con.5	Usar constexpr para valores computables en tiempo de compilación

// Con.1 a Con.5: Inmutabilidad por defecto
class Sensor {
public:
    explicit Sensor(std::string id) : id_(std::move(id)) {}

    // Con.2: funciones miembro const por defecto
    const std::string& id() const { return id_; }
    double last_reading() const { return reading_; }

    // Solo no constante cuando se requiere mutación
    void record(double value) { reading_ = value; }

private:
    const std::string id_;  // Con.4: nunca cambia después de la construcción
    double reading_{0.0};
};

// Con.3: Pasar por referencia constante
void display(const Sensor& s) {
    std::cout << s.id() << ": " << s.last_reading() << '\n';
}

// Con.5: Constantes en tiempo de compilación
constexpr double PI = 3.14159265358979;
constexpr int MAX_SENSORS = 256;

Concurrencia y Paralelismo (CP.*)

Reglas Clave

Regla	Resumen
CP.2	Evitar condiciones de carrera
CP.3	Minimizar el compartir explícito de datos modificables
CP.4	Pensar en términos de tareas, más que de hilos
CP.8	No usar volatile para sincronización
CP.20	Usar RAII, nunca lock()/unlock() directos
CP.21	Usar std::scoped_lock para adquirir múltiples mutex
CP.22	Nunca llamar código desconocido mientras se mantiene un bloqueo
CP.42	No esperar sin una condición
CP.44	Recordar nombrar tus lock_guards y unique_locks
CP.100	No usar programación libre de bloqueos a menos que sea absolutamente necesario

Bloqueo Seguro

// CP.20 + CP.44: Bloqueos RAII, siempre nombrados
class ThreadSafeQueue {
public:
    void push(int value) {
        std::scoped_lock lock(mutex_);  // CP.21: adquiere mutex(es) de forma segura
        data_.push(value);
    }

    std::optional<int> pop() {
        std::scoped_lock lock(mutex_);
        if (data_.empty()) return std::nullopt;
        int value = data_.front();
        data_.pop();
        return value;
    }

private:
    std::queue<int> data_;
    mutable std::mutex mutex_;  // mutable porque lock_guard modifica el mutex en métodos const
};

Conclusión

Seguir las C++ Core Guidelines conduce a un código que es:

• Seguro: Los errores se detectan en tiempo de compilación mediante el sistema de tipos
• Eficiente: Las abstracciones tienen costo cero o mínimo
• Mantenible: La intención es clara, los recursos se gestionan automáticamente
• Moderno: Aprovecha las características de C++17/20/23 para simplificar el código

Consulte siempre las C++ Core Guidelines completas para obtener explicaciones detalladas y ejemplos.