428 meneos
20499 clics

La excepcional belleza del código fuente de Doom 3 [ENG]  imagen

Esta es una historia sobre el código fuente de Doom 3 y de lo hermoso que es. Sí, hermoso. Permitidme que me explique: después de lanzar mi videojuego —Dyad— me tomé un pequeño descanso. Al mes o así de holgazanear, pensé en extraer las partes del motor gráfico de mi juego para un nuevo proyecto pero, como el código fuente era un lío espantoso, me puse a buscar proyectos donde orientarme en la organización de dicho código. Fue cuando encontré un artículo sobre el código fuente de Doom 3, así que me puse a revisarlo.
etiquetas: belleza, código fuente, doom 3, john carmack
usuarios: 221   anónimos: 207   negativos: 3  
195comentarios mnm karma: 545
«12
  1. #1   El propio John Carmack respondió a este artículo: kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=
    votos: 36    karma: 324
  2. #2   Joer como se flipan algunos :-D
    votos: 6    karma: 49
  3. #3   ¿y donde pones que está en inglés?
    votos: 3    karma: 15
  4. #4   #3 Ya :-D
    votos: 1    karma: 24
  5. #5   #4 Gracias majo ;)
    votos: 0    karma: 8
  6. #6   #2 Se tiene o no se tiene.
    votos: 2    karma: 22
  7. #7   Se lo ha currado un huevo y tiene razón, esta bonito y bien hecho.
    votos: 5    karma: 64
  8. #8   Si nombras adecuadamente a tus funciones y variables y tu código es claro, la necesidad de comentar el código es practicamente mínima.
    votos: 9    karma: 87
  9. #9   #8 Tú dale ideas a los que hacen código ofuscado, que son una gran parte de la gente que programa.
    votos: 0    karma: 9
  10. #10   #8 Un buen código se lee solo, lo que tu comentas no es que sea necesario comentarlo puesto que seria repetir lo mismo 2 veces.

    He estado revisando y hasta la estructura de la solución es buena.
    votos: 1    karma: 21
  11. #11   ¿Por que la gente leer Kotaku? Tienen los peores columnistas. Con diferencia.

    Y no me refiero a que tengan gustos diferentes a mi. Me refiero que hacen artículos que no tienen ni pies ni cabeza.
    votos: 3    karma: 9
     *   TaoTao TaoTao
  12. #12   #1 Justo ayer o antes de ayer :-P Lo puso en su twitter. Lo tengo guardado para echarle un vistazo cuando tenga tiempo :-P
    votos: 0    karma: 7
  13. #13   En su día ese título hizo pasar bastante miedo (suspense y sobresaltos) a bastantes gamers, incluso a quienes por entonces ya estaban de vuelta de muchos otros shooters.
    La terrorífica y oscura atmósfera que lo rodeaba todo causó sensación en su época. Y su I.A. también causó sensación.
    votos: 1    karma: 13
     *   SevenPeaks SevenPeaks
  14. #14   #11 ¿Eres indio?
    votos: 9    karma: 78
  15. #15   John Carmack es mi ídolo de la infancia y también de la actualidad. Hacen falta más matarmarcianos como este señor sabe hacer y menos emos chuloputas xD

    Saben de algún juego que utilice el motor del doom 3 (IDtech4 ) que este para jugar en linux ??
    votos: 1    karma: 19
  16. #16   #14 Si o_o
    votos: 4    karma: 40
  17. #17   Fap Fap Fap Fap ...
    votos: 3    karma: 41
  18. #18   #15 Lo bueno es que libera su código. Lo malo es que hace mucho tiempo que no hace nada arrasador en el ámbito tecnológico.
    votos: 1    karma: 18
  19. #19   S.O.L.I.D. (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion)
    votos: 1    karma: 17
  20. #20   Pues hay fallos por la mezcla de diferentes estilos. Incluso dentro de un mismo fuente. Por ejemplo en ui/BindWindow.cpp:

    68 if (waitingOnKey) { // Sin espacios tras los paréntesis

    108 if ( waitingOnKey ) { // Hay espacios tras los paréntesis

    Y ese error se repite bastante. Además he visto sitios donde utilizan tabulaciones y sitios donde utilizan espacios, con lo que descuadra.

    En definitiva: todo es mejorable :-P
    votos: 3    karma: 36
  21. #21   #20 Yo paso todo mi código por AStye antes de subirlo al repositorio.

    ¿Soy un hereje sin educación en formateo de código? ¿O alguien practico?

    astyle.sourceforge.net/
    votos: 3    karma: 32
  22. #22   ¿Excepcional belleza? ¿Y uno de los primeros ejemplos que veo es una secuencia if-else if-else, algo que casi siempre (por no decir siempre) es un ejemplo de mal diseño?

    Seguiré echando un vistazo al artículo, pero parece que para él, un código "bello" es un código bien formateado. El formato del código es importante, está claro, pero la belleza de un código fuente está en el diseño.

    Y me ha parecido ver lo que es básicamente un "getter". Si pones un getter estás exponiendo los datos de tu clase, y cargándote la encapsulación, que es uno de los fundamentos de la programación orientada a objetos. Algunos (la mayoría) piensan que por poner un campo privado y un getter público están cumpliendo con la encapsulación...
    votos: 2    karma: 23
     *   CapitanObvio CapitanObvio
  23. #23   #21 ¡¡¡¡HEREJÍA!!! ¡¡¡A LA HOGUERA!!! :-P

    Yo prefiero hacerlo a mano. Pero sea a mano o sea con una herramienta, creo que es importante la coherencia de formato. Facilita bastante la legibilidad.
    votos: 1    karma: 19
  24. #24   #18 hombre 'Rage' usa un motor del que ha sido padre y como juego no esta nada mal :-)
    votos: 2    karma: 23
  25. #25   Aquí un programador que aprendió por costumbre a escribir condicionales así:

    if ( x ) {
    } else {
    }

    y no así
    if ( x )
    {

    }
    else
    {


    }


    JODEROS! LO SABÍA, ME DECIAIS QUE PROGRAMABA COMO UN RETRASADO MENTAL, JODEROS TODOS!!! ya tengo el aval de idSoftware.

    Si, lo siento si me he excedido pero llevo alrededor de 6 años programando y no dejan de decirme que el estilo de mis condicionales es estúpido. Lo he pasado muy mal en mi vida como programador...
    votos: 83    karma: 732
     *   Cidwel Cidwel
  26. #26   #20 Dos espacios, una tabulación, todo lo demás: golpe de remo.

    #25 Eso lo tengo visto por costumbres del lenguaje más que por otra cosa, yo también soy partidario de las llaves en la misma linea, eso sí, para los sibaritas eres un hereje xD
    votos: 4    karma: 48
     *   --9388-- --9388--
  27. #27   #25

    Normalmente cada lenguaje de programación tiene unos estándares explícitos o por convención.

    Y siento decirte que un if-else es casi siempre un síntoma de mal diseño y casi siempre hay una solución mejor.
    votos: 11    karma: -67
  28. #28   #26 cuatro espacios, una tabulación. Hereje.
    #27 Es muy dificil que crees un portal web o proyecto entero y no metas un else. Búscame un proyecto de más de 100,000 lineas donde no veas un else para condicionales muy triviales. I DARE YOU!
    votos: 11    karma: 118
     *   Cidwel Cidwel
  29. #29   #25 yo lo hago como tu... la verdad es que nadie me ha dicho nada... la otra forma me parece de retrasados...
    votos: 4    karma: 26
  30. #30   #26 #28 3 espacios. Estáis matando gatitos cada vez que abrís la boca.
    votos: 1    karma: 17
  31. #31   #24 Sus texturas dan pena, de las peores que he visto en PC (otros jugos como mínimo en el salto a PC ponen unas buenas texturas, que en PC hacen falta al estar tan cerca de la pantalla). Es demasiado consolero. No digo que sea malo (aunque tampoco es que haya reventado la crítica) pero no es la revolución técnica a la que nos tenía acostumbrados antes.

    #26 No se pueden mezclar tabulaciones con espacios, es horrible. Además, yo uso tabulaciones de 4 espacios. Y en Python si metes menos o más de 4 ni siquiera funciona xD
    votos: 0    karma: 7
     *   Kherom Kherom
  32. #32   #30 A las 2:00 en la puerta del colegio me lo cuentas.
    votos: 1    karma: 18
  33. #33   Fuck is necessary
    votos: 1    karma: 20
  34. #34   ¿Hay que decir 'melofo'? :troll:
    votos: 1    karma: 19
  35. #35   #28 Tu no seras del Frente Popular de Judea?? Cuatro espacios me parece una aberración, sobre todo en bloques de código largos, 2 más fácil de seguir.

    #30 Tres????... secundo a #32

    #31 Evidentemente, uso de tabulador: Golpe de Remo, los hombres de verdad usan espacios para tabular.
    votos: 1    karma: 21
     *   --9388-- --9388--
  36. #36   #28 Si pudiera, te daría el código de la aplicación web que estamos construyendo. No es código abierto, por desgracia, aunque esto no depende de mí.

    Por otra parte, el 90% de los proyectos de 100.000 líneas o más se podrían escribir en una cuarta parte de líneas. El diseño del 90% de proyectos es malo, que otros lo hagan mal no es excusa.
    votos: 3    karma: 32
     *   CapitanObvio CapitanObvio
  37. #37   #35 Soy del frente popular judáico, y aquí usamos 4 espacios, queda simple el código y muy bien legible para los que están acostumbrados al código como a los que no. Por cierto, siempre decirle a tu editor que trate los tabs como espacios. SIEMPRE.

    #36 digo yo que dependerá de la complejidad de un proyecto, ¿no?. Obviamente todo código puede reducirse de tamaño. Pero eso es irte al comodín facil de la programación, y es que rara vez hay personas que gastan un 40% de su tiempo en optimizar su código
    votos: 3    karma: 36
     *   Cidwel Cidwel
  38. #38   #25 tu ni caso, que les den :-)
    votos: 2    karma: 29
  39. #39   #18 Doom 3 me parece muy bueno y el rage es un juego de la vieja escuela que cuando pueda va a caer. Recuerda también que los call of duty utilizan un motor basado en el IDtech3 ( quake 3 arena ). Y para ver que esta en la cresta de todo este mundillo. AMD puede que utilicen en las nuevas consolas y gráficas una tecnología creada por carmack para su IDtech6 ...
    votos: 1    karma: 20
  40. #40   Algunos de los puntos que se comentan en el artículo son realmente buenos. Otros, en cambio, son meros detalles estéticos con los que se puede o no estar de acuerdo pero que no son en ningún caso verdades absolutas.

    #25 Yo también pongo los condicionales como dices. Ahora bien, sí que suelo separar cosas o dejar líneas en blanco para mejorar la legibilidad. Por ejemplo, entre dos bloques if consecutivos dejo una línea en blanco. No creo que eso sea un problema ni que haga el código más "feo".
    votos: 4    karma: 46
  41. #41   #35 Viva el código lasaña! xD Con 4 para mí se sigue más fácil, y es más típico. Ya te digo que en Python son 4 quieras o no.

    #25 A mí me gusta el condicional terciario de c++, por lo menos para una línea :-P
    votos: 3    karma: 38
     *   Kherom Kherom
  42. #42   ¡Bueno si será bonito!

    No he podido dejar de leerlo hasta llegar a la última página....¡y no os podéis imaginar qué final tan sorprendente!!

    Nadie nunca averiguará que el asesino es Jack el forastero (L.Luthiers dixit)

    :-)
    votos: 3    karma: 38
  43. #43   #25 Pues yo siempre lo hago así, me parece más legible.
    votos: 1    karma: 19
  44. #44   Disidentes!!
    votos: 3    karma: 30
  45. #45   #37 Yo no hablo de optimización. Por optimización entiendo mejoras de rendimiento, y eso no tiene que ver con el tamaño del código y se hace al final del todo. Premature optimization is the root of all evil, Donald Knuth dixit.

    Yo hablo de diseño. Una aplicación bien diseñada y que siga a rajatabla los fundamentos de la POO (si hablamos de POO) tendrá menos líneas que una hecha "a lo loco".
    votos: 2    karma: 23
     *   CapitanObvio CapitanObvio
  46. #46   #22 La encapsulación no va de esconder, sino de controlar el acceso.

    #45 C++ es multiparadigma, puedes mezclar. Hacer un juego basado 100% en objetos es un error (por el rendimiento).
    votos: 12    karma: 116
     *   Kherom Kherom
  47. #47   int Comida;
    Espero que os duelan los ojos. Pero ESE fallo lo he visto muchas veces, y me da vomitera.
    votos: 0    karma: 10
     *   Cidwel Cidwel
  48. #48   #41 Con 2 es más que suficiente para poder seguir el código, hereje.

    #37 Evidentemente, se da por hecho que se modifica el editor para cambiar las tabulaciones por espacios, que piensas que soy como esos del Frente Popular Judáico a los que hay que explicarle algo tan básico?? ¬¬
    votos: 0    karma: 10
     *   --9388-- --9388--
  49. #49   El manual del buen estilo de google choca en muchos puntos con el manual de ID. google-styleguide.googlecode.com/svn/trunk/cppguide.xml
    Fight!

    #8 Dependerá de la dificultad del algoritmo que estés haciendo.
    votos: 4    karma: 43
     *   chulonsky chulonsky
  50. #50   #22 Y siento decirte que un if-else es casi siempre un síntoma de mal diseño

    ¿Y eso por qué? No conozco ningún lenguaje de programación que no tenga condicionales (¡incluso Haskell tiene!).
    Si fueran malos ya los habrían quitado (como se ha hecho con los GOTOs o los bucles for estilo C/C++).
    votos: 6    karma: 68
  51. #51   #46 Nos ponía un ejemplo hace poco nuestro arquitecto software de una aplicación bancaria en la que había una clase Préstamo, en la que había un campo de coma flotante con la cantidad, y un hermoso getter. Cuando hubo que refactorizar, resulta que ese getter se invocaba desde docenas de sitios. ¿Es eso para ti encapsular? Docenas de clases tenían acceso a un dato cuando sólo la clase Préstamo debería tratar con él.

    Si tienes una clase Préstamo, el campo con la cantidad no le interesa a ninguna otra clase. Si quieres hacer una operación con un Préstamo, todo lo que tenga que ver con la cantidad se debe realizar en la propia clase, porque es la clase que entiende de préstamos y la responsable de los mismos.

    ¿Que quieres aumentar un préstamo? Creas otra instancia de Préstamo con la cantidad a aumentar (que se la pasas en el constructor) y tienes en tu clase Préstamo un método aumentar_préstamo, que toma otro Préstamo, los suma y devuelve una nueva instancia de Préstamo.

    Préstamo incial = Préstamo.new(10000)
    Préstamo aumento = Préstamo.new(2000)
    Préstamo final = inicial.aumentar_préstamo(aumento)

    Voilà. En la variable final tendrás tu Préstamo de 12.000, valor al que nadie que no sea un Préstamo tiene acceso.
    votos: 7    karma: -36
     *   CapitanObvio CapitanObvio
  52. #52   #45 En cualquier caso, que mas da da si tu proyecto se puede reducir 10k lineas? Que va a suponer eso? Y el coste en tiempo?
    votos: 1    karma: 19
  53. #53   #50 ¿De dónde se han quitado los goto y los bucles for? Por que de c/c++ no, siguen ahí, y siguen siendo útiles, y por más que te hayan comido la cabeza, goto es una sentencia más y es perfectamente válida, además de ser conveniente a veces. Los puedes encontrar en el código de Linux mismamente.
    votos: 2    karma: 26
  54. #54   Yo hace muchos años pensé que quería ser programador... Hasta que me dí cuenta de que el diseño de los lenguajes de programación era absurdo.
    votos: 1    karma: 18
  55. #55   #53 goto sólo tiene sentido en código que tiene que estar muy, muy optimizado. Cosas como el kernel de Linux. El 99% de código que se escribe a diario en el mundo debe huír como de la peste.
    votos: 1    karma: 17
  56. #56   #51 Si sólo la clase Préstamo debe conocer ese dato no debería ser accesible, pero yo puedo querer encapsular algo para tratarlo de una determinada forma, no para que no se pueda modificar. Por cierto, con tu ejemplo me has matado, madre de dios qué chapuza...

    #55 Yo no lo uso. Pero no tiene por qué ser malo. Por ejemplo un goto end en una función puede simplificar las cosas.
    votos: 4    karma: 47
     *   Kherom Kherom
  57. #57   #52 Tú, como el otro, piensas: "hago un proyecto, e intento reducir el número de líneas". NO. DISEÑAS un proyecto BIEN, y tu programa tendrá un número reducido de líneas. No es algo a posteriori.
    votos: 1    karma: 17
  58. #58   Hola???

    Podría haberse traducido parte de esa belleza en el juego... porque vaya decepción después del DOOM 2, este es el peor de todos sin duda, una chusta que no aguanté jugando ni 3 días.
    votos: 1    karma: 16
  59. #59   #56 Vaya, ahora es una chapuza un ejemplo que se usa en el MIT, ilústranos con tus conceptos de orientación a objetos, anda.

    No me lo digas.

    class Préstamo {

    private double cantidad;

    public Préstamo(double cantidad) {this.cantidad = cantidad;}

    public double getCantidad(return this.cantidad);

    public void setCantidad(double cantidad) {this.cantidad = cantidad;}

    }

    Préstamo préstamo = new Préstamo(10000);
    préstamo.setCantidad(préstamo.getCantidad() + 2000);

    ¿Me equivoco?

    Con respecto a esto:

    "Si sólo la clase Préstamo debe conocer ese dato no debería ser accesible, pero yo puedo querer encapsular algo para tratarlo de una determinada forma, no para que no se pueda modificar."

    No he entendido nada.
    votos: 0    karma: 6
     *   CapitanObvio CapitanObvio
  60. #60   #57 Eso está muy bien cuando el diseño inicial es el final, pero en mi experiencia, rara vez es así.
    votos: 0    karma: 8
  61. #61   #51 Y si ahora tienes otro objeto del tipo CuentaBancaria y quieres actualizar el campo saldo para reflejar el aumento del mismo a causa del prestamo, ¿como lo haces si le clase Prestamo no tiene método alguno para devolver la cantidad?
    votos: 8    karma: 89
  62. #62   #25 En C de Kernighan y Ritchie se escribe como tú lo haces. Yo también lo hago así. Si se usa bien la identación esta manera creo que es la major. La otra solo contribuye a hacer código alargado y complicado de leer, en mi opinión.

    Me cabreaba mucho lo de las llaves abajo. En Coritel me obligaban a ponerlo así como norma de estilo interna... Una estupidez, vamos.
    votos: 5    karma: 56
  63. #63   #59 En el sector bancario no lo sé, pero como solución genérica para cambiar datos (que es como lo planteas) es una chapuza. A hacer copias de objetos por un tubo!
    votos: 3    karma: 40
     *   Kherom Kherom
  64. #64   La peña se hace pajas con cada cosa...
    votos: 1    karma: 20
  65. #65   #53 ¿De dónde se han quitado los goto y los bucles for?

    Pues los GOTO y los bucles for estilo for(inicialización, condición, incremento) no suelen existir en los lenguajes que no tienen a C como influencia directa.

    por más que te hayan comido la cabeza, goto es una sentencia más y es perfectamente válida

    Muchas gracias por enseñarme que hay mundo más allá del académico. Lo que tú deberías saber es que hay mundo más allá de C/C++.
    votos: 0    karma: 10
     *   Bedel_roolmo Bedel_roolmo
  66. #66   #64 eres programador o eres de los que dicen "a mi no me ralles que TU haces tu trabajo y yo el mio?"
    votos: 1    karma: 17
  67. #67   Nada que no se pueda hacer en cualquier consultoria informatica de este pais.... :\
    votos: 0    karma: 10
    jrz jrz
  68. #68   #57 Nadie ha dicho que revises tu código para optimizarlo sino que cada vez que hagas una función te pares a pensar que puedes reducir eso que has hecho en 20 lineas en solo 5. Admitamoslo, hay un montón de trucos de la programación que te dejan boqueabierto cuando los ves, y que sólo la práctica hace que los acabes usando. A menos claro que seas superdotado, en ese caso menéame no es para tí.
    votos: 5    karma: 56
     *   Cidwel Cidwel
  69. #69   #66 creo que no soy ninguna de las dos cosas. Me gustan las tortugas, eso sí.
    votos: 3    karma: 37
  70. #70   Eso es como si un arquitecto dice:"Que bonitos son los ladrillos de ese edificio". Una chorrada porque que no se van a ver.
    votos: 6    karma: -44
     *   McAstur McAstur
  71. #71   #25 Yo también lo hago así. No me gusta el código de una función si hay que mover mucho el scroll.
    votos: 1    karma: 17
  72. #72   Mucho código limpio y aseado y no incluyeron una linterna pegada a las armas...XD O más acción y menos sustitos.
    votos: 1    karma: 18
  73. #73   #70 No es lo mismo. Un arquitecto nunca volver a por los ladrillos de una obra para hacer otra nueva. Un ingeniero software si, y cuando mas bonitos sean, mas faciles serán de reutilizar.
    votos: 2    karma: 27
  74. #74   #36 No entiendo, ¿por qué un if-else es síntoma de mal diseño? Si por ejemplo en mi aplicación tengo que antes de generar un presupuesto tengo una función que comprueba si está dentro de plazo de modo que si no lo está se muestra un mensaje de usuario en lugar de generarlo, cómo hago esto si no es con un if-else o similar?
    votos: 6    karma: 68
  75. #75   #73 Si pero por muy bonitos que sean, no se ponen solos. Más importante es que el resultado sea bonito, creo yo.
    votos: 0    karma: 8
  76. #76   #26 Menos de 3 espacios no es tabulación, es error tipográfico. 2 espacios, golpe de remo. 1 espacio, pelotón de fusilamiento.
    votos: 3    karma: 39
  77. #77   Tienes que salir mas
    votos: 0    karma: 6
  78. #79   #25 Estoy completamente de acuerdo contigo, odio ver una maldita línea de código malgastada para poner un maldito "abrir llave"... Y ya si encima hay gente que trabaja con una resolución vertical de 768px es desastroso.

    Yo siempre escribo:
    if (condition) {
    code1;
    } else {
    code2;
    }
    votos: 4    karma: 52
  79. #80   #45 Parece que estás haciendo una equivalencia entre buen diseño y POO.

    ¿Acaso es el único paradigma que permite diseñar bien?
    votos: 4    karma: 53
  80. #81   Para código bonito bonito, el del quake1.

    #22 Es "posible" que lo hagan así para generar un código mas rápido, aun programando en C siempre tengo el ASM en mente.
    votos: 0    karma: 7
  81. #82   #70 Si que se ve, el doom y el quake están portados a casi cualquier trasto electrónico porque su código está muy bien hecho y no han tenido que modificar casi nada.
    votos: 0    karma: 7
  82. #83   Que me hagáis leer los comentarios de esta noticia me preocupa, más por mí que por vosotros, panda de zumbaos.
    votos: 2    karma: 22
  83. #84   #70 y #73 Por alusiones ;) :
    El arquitecto no va a coger los ladrillos de la obra hecha (del mismo modo que los ladrillos que forman el Doom, forman el Doom y no otro juego) pero lo que si va a hacer, si ha realizado un detalle constructivo de la fachada donde están esos ladrillos y ha resultado ser eficiente, fácil de ejecutar, resuelve bien los encuentros, etc. es reutilizar esa solución, ese detalle constructivo (ese código fuente) o el modo que le llevó a hacer ese diseño, a otra obra.
    votos: 1    karma: 25
  84. #85   #84 Yo creo que la comparación arquitecto <-> ingeniero de software siempre está un poco cogida por los pelos. Entiendo que yo no he sido suficientemente especifico por que no conozco la arquitectura, pero creo que es mejor no meterse a establecer comparaciones.

    Eso de que lso ladrillos forma el Doom y no otro juego es una verdad a medias. No son ladrillos, son mas bien herramientas, y con ellas, si juntas arte y gameplay tienes un juego.
    votos: 0    karma: 8
  85. #86   #51

    Dios, no puedo creer que digas eso en público.
    votos: 2    karma: 26
  86. #87   #27 ¿que un if-else es casi siempre un síntoma de mal diseño? Ilumíname, porque en 10 años de programación, no he dejado de verlos.

    Por ejemplo, un tratamiento básico de un mensaje de respuesta:

    if (messageResponse.hasError()) {
    hazLoQueSeaConElError(messageResponse.getError());
    else {
    sigueLaEjecucion;
    }
    votos: 1    karma: 18
  87. #88   #87
    Para ese caso muchos lenguajes emplean try/catch
    votos: 1    karma: 18
  88. #89   Al que le interese el tema, tirando de enlaces se llega a esta web:
    fabiensanglard.net/

    Donde se analiza el código de los Quake I, II y III y los Doom I, II, III; así como otros juegos, como el código del Another World.
    votos: 2    karma: 33
  89. #90   #20 Soy igual de maniático compulsivo, yo también he visto ....){ , masticaba las visceras de los que hacen eso, primero empezando por los deditos para que no pudieran seguir programando.
    votos: 0    karma: 9
  90. #91   #88 No estoy hablando de una excepción, sino de un error ya tratado y encapsulado por el servicio que estoy llamando.
    votos: 1    karma: 18
  91. #92   #88 mmm, pero en videojuegos no puedes usar Try and Catch, son muy lentos y algunas consolas no lo soportan...
    votos: 2    karma: 25
  92. #93   Las normas de estilo de C++ dictan sangrados de 4 espacios. Respecto al posicionamiento de los corchetes, ponerlos en línea reduce espacio. Ponerlos en líneas distintas es redundante, pero allá cada uno lo que ponga.
    votos: 0    karma: 7
  93. #94   #79 #25 Esto sólo lo entendemos los que hemos aprendido a programar en monitores de 14 pulgadas a 800x600 o 1024x768
    votos: 4    karma: 47
     *   calomar calomar
  94. #95   No he jugado en mi vida al Doom 3, habría que ver como funciona el juego, si no tiene bugs y tal.

    Creo que mi código es bastante limpio, mi secreto:

    ** Definir o seguir los/tus patrones de diseño que sean.
    ** Seguir estándares.
    ** Código autocomentado siempre que se pueda.
    ** Comentar siempre las funcionalidades correctamente, sin vaguerias o errores funcionales, ni siquiera con faltas de ortografía. Muy propias cuando se comenta código.
    ** Reducir métodos al mínimo.
    ** Correcto nombramiento de los métodos y variables.
    ** Repasar y rehacer tu código, creando nuevas clases, eliminando o reduciendo si es mejorable o colisiona con los patrones de diseño.
    ** Clases y métodos con visibilidad correcta.
    ** Siempre es posible(no dependencias de terceros etc) acabar tus funcionalidades del todo, jamás parcialmente, tratar de cerrarlas, eso ocurre cuando se pasan todos los test necesarios cubriendo toda casuistica y funcionalidades, se cumple con lo que dice el DT, si lo hubiere, se cumple con los estándares, patrones de diseño y las auditarías de código ya sean externas o definidas por tu equipo. Si no se corre el peligro del síndrome del 90% lo que ocurre cuando esta todo casi acabado pero no acaba nunca.
    ** Dedicar tiempo suficiente a los que menos saben, o los mas nuevos, enseñando y tratando de que corrijan sus errores, dejando que se peguen con el código pero sin dejarles solos. Repasar su código y mostrar errores. Solo así harán un código correcto.
    ** Asignar a cada miembro del equipo tareas que entren dentro de los margenes de sus capacidades, contratos o cualificaciones.
    ** Exigencias dentro de los margenes de lo humanamente posible y del horario laboral. Las prisas, al final casi siempre son contraproducentes. Bien porque se haga mal el trabajo o bien quemar al personal, lo que desemboca en discusiones, estreses y malos rollos. Obviamente, esto repercute en la calidad del código y esto ultimo al final desemboca en errores funcionales y problemas en mantenimientos o evolutivos.
    ** Coherencia en los tiempos de desarrollo, si como jefe tienes que decir que no puede estar a los de arriba, hay que decirlo, se explica, te comes el marron y ya está. Bajo mi experiencia mentir o comprometerse a cosas imposibles es también peor a la larga, obviamente repercute completamente en la calidad del código. También aplica a los programadores; esos que dicen "eso en día y medio lo tengo" y luego tardan 8 y la siguiente vez estiman lo mismo. Hay que entender que en los equipos siempre hay gente excesivamente positiva y gente excesivamente pesimista que se llevan las manos a la cabeza por cualquier cosa. Ni una cosa ni otra. Hay que tratar de hacer entender que el positivo tiene una responsabilidad con sus compromisos y que el pesimista no puede estar cargando al mundo con frases apocalípticas en plan "esto no va a salir nunca". En programación, realismo con margen para intangibles, siempre.
    ** Ser bastante exigente con todo lo anterior, contigo mismo y si mandas, con los demás.

    Si reduces los libros de Clean Code 'solo' a esto, ya ganas muchísimo. Pero los que programamos ya sabemos que 'solo' esto, no se cumple casi nunca.
    votos: 3    karma: 32
  95. #96   #25 depende si te pagan por linea o te pagan por trabajo o si es para ti :troll:

    aun recuerdo lo de DiscountForCoupon y CouponForDiscount dos clases que median iguales con el mismo numero de métodos y los de mi equipo confundiéndose casi todo el rato :troll:
    votos: 1    karma: 20
  96. #97   #27 Te equivocas. Un if-else es lo normal y lógico dentro de cualquier aplicación. Lo que suele ser un síntoma de mal diseño (digo suele porque no siempre es verdad) es varios if-else-if-else anidados.
    votos: 13    karma: 129
  97. #98   #70 Tu comparación es incorrecta. Un arquitecto diría “qué bonitos son los planos de este edificio” igual que un informático dice “qué bonito es el código fuente de esta aplicación”. Si el arquitecto dice lo de los ladrillos, el informático tendría que decir “qué bonito es el código binario de este programa”.
    votos: 2    karma: 34
  98. #99   #51 esa lógica se cae en cuanto otra clase dependa de la cantidad de ese préstamo.

    Por ejemplo, si hay que evaluar el riesgo del cliente, ¿cómo sumas la cantidad de dinero que tiene asignado en préstamos?

    De hecho, ¿qué información expone esa clase Prestamo al exterior, es una clase autista de la que nadie depende para nada?
    votos: 2    karma: 31
  99. #100   #51 Eso está muy bien en la teoría. Cuando llegas a la realidad, ves que no todo son objetos (la POO es de las mejores cosas que se han inventado para programar pero no es la panacea) y que para incrementar un préstamo (por usar tu ejemplo) lo mejor es usar un número real.
    votos: 2    karma: 35
«12
comentarios cerrados

menéame