Primero, aclarar que aquí no importan los tochos. De hecho, habrá que leer bastante, así nos vamos acostumbrando
Ariath escribió:Respecto al tema de Windows y Linux, creo que es mejor hacer una sola versión, en la que se pueden ir añadiendo las bifurcaciones que sean necesarias (los que conocen ya C, hablo de los típicos #ifdef _WIN32 o #ifdef _UNIX, etc ... (hablo de memoria, así que seguramente he puesto ambos ifs mal xD)).
Eso es malo para mantener y hace que el código sea enorme innecesariamente. Tener 2 proyectos diferenciados es más claro, aunque se repita código. En Linux no habŕia problema en usar enlaces blandos para no tener que, pero tampoco veo ningún problema en tener 2 proyectos separados. Es mucho más limpio y mantenible en mi opinión.
Ariath escribió:Respecto al servidor SVN, voto por Assembla por 2 razones: Primero es un hosting SVN gratuito y de buena calidad, y segundo, es bastante intuitivo de gestionar.
Yo voto por Google Code, es una empresa que sabes no va a cerrar, porque ya he manejado varios proyectos en él también (el HBL está en Google Code por ejemplo), porque es gratis, porque apoya el software libre, y no he tenido ningún problema en gestionarlo (de todas formas yo todas las gestiones de código por SVN las hago desde el cliente).
Ariath escribió:Y bueno, hay una cosa en que me gustaría hacer especial hincapié: La legibilidad del código.
Cierto, no lo comenté antes porque... iokese

Estoy totalmente de acuerdo con lo que dices, y si te fijas en
mi código, yo siempre intento mantenerlo lo más ordenado, legible y comentado posible.
De hecho, ya que lo comentas, me gustaría proponer unas reglas de estilo. Y nada mejor que un ejemplo comentado:
esta_cabecera.hCódigo: Seleccionar todo
/*
- Donde digo "int" digo cualquier tipo
- Uso de TABULACIONES (no espacios) para el sangrado
- Una tabulación por cada sangrado
- Las llaves siempre al principio de línea (no al final aaaargh grgrgrgr)
- Todo lo que va dentro de llaves va sangrado (con excepciones sobre todo en C++)
*/
// Esto SIEMPRE, ahorra innumerables errores compilación de referencias circulares
#ifndef ESTA_CABECERA_H
#define ESTA_CABECERA_H
// Primero las cabeceras estándar
#include <stdio.h>
// Luego librerías extra
#include <peasograficos.h>
// Luego las propias de la aplicación
#include "cabezabolo.h"
// Constantes con mayúsculas!!
#define CONSTANTE_DEFINE
#define OTRA_CONSTANTE
// typedef struct siempre directamente
// Siempre pongo los tipos con "t" por delante
typedef struct
{
// Interesante estructura
}tUnTipo;
// Descripción de la clase y su funcionalidad
class cClase: public cClasePadre
{
private:
// Lo que vaya en cada, tabulado como se debe
protected:
public:
}
#endif
cclase.cpp
Código: Seleccionar todo
// Sólo ésta a ser posible, sólo ésta
#include "cabeceraquecorresponda.h"
// Descripción del cometido del método, de los parámetros de entrada y valor de retorno
int cClase::hace_algo_importante(int parametro1)
{
// Siempre incializar
int describeme = 0;
// Nunca valores literales en el código, siempre usar constantes, salvo valores intrínsecos del lenguaje
// Siempre con llaves, aunque la sintaxis permita que no se usen
if (describeme == CONSTANTE_DEFINE)
{
// Usa y abusa de los paréntesis (se ve(que programo(en lisp?)))
while ((describeme > 0) && (describeme < CONSTANTE_DEFINE))
{
// Muchas cosas difíciles y complicadas
}
}
else
{
// Buah, más difícil aún
}
// Todo sangrado en el switch
switch(describeme)
{
case CONSTANTE_DEFINE:
// Un solo return por función!
return OTRA_CONSTANTE;
}
Los nombres de fichero siempre en minúscula.
Estoy abierto a cualquier discusión, pero intentemos no perder mucho tiempo en esto. Es más fácil aceptar un determinado modelo (el mío, claro

) y empezar a lo importante
