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.
![La excepcional belleza del código fuente de Doom 3 [ENG]](https://cdn.mnmstatic.net/cache/1b/a8/media_thumb_2x-link-1812717.jpeg?1417833704)
Comentarios
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...
#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
#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!
#26 #28 3 espacios. Estáis matando gatitos cada vez que abrís la boca.
#30 A las 2:00 en la puerta del colegio me lo cuentas.
#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.
#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
#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".
#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).
#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.
#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.
#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
public double getCantidad(return this.cantidad);
public void setCantidad(double 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.
#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!
#59 (cc #63 #51)
Quizás en el caso de préstamos sea válido lo de crear un nuevo préstamo pero si tienes una cuenta y quieres hacer un ingreso espero que no crees una cuenta "ingreso" y luego hagas "aumentarCuenta" porque a mi me parece absurdo.
La idea se que un objeto cuenta tiene muy probablemente un número de cuenta y crear un número de cuenta para un ingreso no tiene ningún sentido.
Análogamente me parece raro crear un préstamo para modificar la cantidad de otro préstamo, pero quizás sí que funcione así.
Lo más raro es hacer eso llamando al método "aumentaPréstamo". Si almenos fuera "juntaPréstamo" o algo así.
¿Se nota que no tengo ningún préstamo?
#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?
#61 parece que no obtienes respuesta.
CapitanObvio ha estado echando pestes del if-else y de los métodos get* y nadie sabe por qué. Y nadie lo sabrá jamás.
#61 Hace muchos años que no toco C++, pero sería con un friend?
#51
Dios, no puedo creer que digas eso en público.
#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?
#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.
#51 ¿Y si resulta que no se hace un getter para seguir las normas sino porque quieres ponerle una comprobación al valor que se introduce? Quizás hacer un getter (o un setter) de una única línea y que tenga sólo un return variable o un variable = parámetro sea una salvajada, pero es como todo. Si tienes que comprobar los valores (¿no se supone que es una práctica?) viene bien crear tanto el getter como el setter (sobre todo este último).
#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?
#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.
#57 Eso está muy bien cuando el diseño inicial es el final, pero en mi experiencia, rara vez es así.
#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í.
#45 Parece que estás haciendo una equivalencia entre buen diseño y POO.
¿Acaso es el único paradigma que permite diseñar bien?
#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??
#35 Viva el código lasaña!
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
#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.
#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?
#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
#26 Menos de 3 espacios no es tabulación, es error tipográfico. 2 espacios, golpe de remo. 1 espacio, pelotón de fusilamiento.
#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.
#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())
#87
Para ese caso muchos lenguajes emplean try/catch
#88 No estoy hablando de una excepción, sino de un error ya tratado y encapsulado por el servicio que estoy llamando.
#91 Command(response).execute() para tener la lógica separada del cuerpo del if y del else... y es que cuando hay un else, en una revisión puede venir otro más y luego otro. Es un ejemplo, en muchos casos sería un sobrediseño pero ya que lo preguntabas.
#92 diseño y mantenibilidad vs bajo_nivel. Muchas veces hay que pensar en bajo nivel, no lo niego en la práctica, aunque teoría para eso están las optimizacionse de los compiladores. Carmack era un maestro en diseñar los algoritmos y sólo empleaba asm en bucles concretos ya que pesa mucho más lo primero que lo segundo para ir más allá.
#88 mmm, pero en videojuegos no puedes usar Try and Catch, son muy lentos y algunas consolas no lo soportan...
#169 Es que el error está en el ejemplo que has planteado en #87. Una cosa es una comprobación de un booleano en una rutina y otra una gestión de errores. He ahí la diferencia entre un uso correcto o no.
¿Y si en la próxima revisión es necesario hacer otro tratamiento dependiente del tipo error? ¿Y si en diferentes entornos el error requiere un tratamiento especifico? Al final lo que era un sentencia simple deriva en modificaciones para añadir if-else encadenados lo que es una falta de aplicación de polimorfismo y/o patrones. Y como dije en #88 y me parece que tu ejemplo es java, pues es un error usar if/else en lugar del manejo de excepciones.
Si en #87 sólo querías mostrar el if-else como sentencia condicional es correcto faltaría más, como diseño nunca. Incluso como sentencia cualquier lenguaje y proyecto serio tiene sus convenciones para su uso por la fuente de errores y limitaciones que produce.
Pero como veo por tu segunda frase que tú eres un experto no sé porqué he pérdido tiempo en aportar mi punto de vista por mi experiencia precisamente. Mi intención del comentario era mostrate una alternativa y que lo puedas revisar y confrontar no darte una masterclass porque podrías buscar en google entre las 100M de páginas sobre 'if else bad practices' y sacar tus propias conclusiones y 'no quedarte tan ancho'.
#175 Mi comentario sobre el no tener mucha idea no iba por ti, si no por el posteador inicial de la frase en #27, que lo ha soltado sin más argumentos.
Por cierto, a mi modo de ver mi ejemplo en #87 utilizo un if (message.hasErrors()), cosa que para mi indica una condición booleana en el cual haré A si hay cualquier error y B si no hay, no un tratamiento de códigos de errores diferentes. Y eso creo que no puede conllevar en ningún caso a un anidamiento de if-else, por eso no entendía tu contestación.
Dicho lo cual, estoy totalmente deacuerdo que un anidamiento de condiciones if-else-if suele ser mala práctica, pero es que la frase original era "Y siento decirte que un if-else es casi siempre un síntoma de mal diseño". Y sigo sin ver como un jodido if-else sin más puede ser síntoma de mal diseño
#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.
#27 Eso me repetían a mi una y otra vez en la universidad. Claro que en la universidad casi nunca hacías nada donde el rendimiento importase lo más mínimo. Dedícate a meter Commands y funciones virtuales en el bucle que está dentro de un bucle dentro de un bucle en un simulador de físicas en tiempo real y verás qué rápido deja de ir en tiempo real...
#115 "There are only two kinds of languages: the ones people complain about and the ones nobody uses" -- Bjarne Stroustrup
#25 yo lo hago como tu... la verdad es que nadie me ha dicho nada... la otra forma me parece de retrasados...
#25 tu ni caso, que les den
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".
#25 Pues yo siempre lo hago así, me parece más legible.
#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.
#25 Yo también lo hago así. No me gusta el código de una función si hay que mover mucho el scroll.
#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) else
#79 #25 Esto sólo lo entendemos los que hemos aprendido a programar en monitores de 14 pulgadas a 800x600 o 1024x768
#25 depende si te pagan por linea o te pagan por trabajo o si es para ti
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
#25 El ejemplo que ponen en esa página de los if-else es un poco tendencioso... si el cuerpo del bloque if-else sólo tiene una línea, no es necesario abrir y cerrar con llaves, se pone en la misma línea del if o el else y es mucho más legible.
if (condicion) accion
else otraAccion;
Aquí se nos muestra unos bloques abiertos y cerrados con llaves con sólo una línea dentro, lo cual queda ridículo. Pero cuando dentro del bloque hay muchas líneas, cambia mucho la legibilidad de una forma y de otra.
Pero vamos, a mí me parece más legible con las llaves en distinta línea y el código interior tabulado, pero no llamaría retrasado a quien prefiera la otra forma... hay mucho intransigente.
#25 Estoy de acuerdo contigo, yo también lo hago así y debería ser lo correcto.
Escribir:
if ()
else
Lo hace largo hasta el infinito.
Otra cosa acerca de la privacidad (métodos/atributos privados, protegidos...), en python
una cosa que llama mucho la atención por internet, es que no existe tal cosa.
Según python, somos adultos; no hay ningún interés en utilizar un método al que has comentado que es privado.
Carmack es dios.
#25 Lo de los condicionales, me da igual siempre que no escribas los nombres de las funciones empezando con mayúscula. Eso lo odio.
#25 Reconozco que me gusta más la segunda forma que pones y es la que suelo usar, me parece el código más legible (uso siempre fuentes pequeñas para minimizar el "efecto alargado"), pero yo me encuentro la mayoría de código apretujado que te gusta a ti, y creo que ahora mismo es el "estándar". De hecho el Eclipse te lo pone así si le das a la opción de reordenar el código, por ejemplo.
El propio John Carmack respondió a este artículo: http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
#1 Justo ayer o antes de ayer Lo puso en su twitter. Lo tengo guardado para echarle un vistazo cuando tenga tiempo
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.
#8 Tú dale ideas a los que hacen código ofuscado, que son una gran parte de la gente que programa.
#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.
El manual del buen estilo de google choca en muchos puntos con el manual de ID. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Fight!
#8 Dependerá de la dificultad del algoritmo que estés haciendo.
#8 Los buenos programadores no ponen comentarios. El código es obvio!
Se lo ha currado un huevo y tiene razón, esta bonito y bien hecho.
Joer como se flipan algunos
#2 Se tiene o no se tiene.
Fap Fap Fap Fap ...
¡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)
#66 creo que no soy ninguna de las dos cosas. Me gustan las tortugas, eso sí.
#69 Jajaja...
me has hecho reír... gracias, no todos los días hay motivos para sacar una sonrisa.
Pues hay fallos por la mezcla de diferentes estilos. Incluso dentro de un mismo fuente. Por ejemplo en ui/BindWindow.cpp:
68 if (waitingOnKey)
#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?
http://astyle.sourceforge.net/
#21 ¡¡¡¡HEREJÍA!!! ¡¡¡A LA HOGUERA!!!
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.
#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.
Al que le interese el tema, tirando de enlaces se llega a esta web:
http://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.
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.
Disidentes!!
#18 hombre 'Rage' usa un motor del que ha sido padre y como juego no esta nada mal
¿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...
#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++).
#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.
#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.
#55 un break o un continue son gotos vestidos de lagarterana, sólo que mejor vistos.
Y un throw es un goto a lo bestia, desde ahí hasta el catch más cercano que puede estar en el culo del mundo.
Usamos más gotos de los que parece, sólo que de otra forma.
#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++.
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.
Que me hagáis leer los comentarios de esta noticia me preocupa, más por mí que por vosotros, panda de zumbaos.
Fuck is necessary
#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 ...
La peña se hace pajas con cada cosa...
#64 eres programador o eres de los que dicen "a mi no me ralles que TU haces tu trabajo y yo el mio?"
¿Hay que decir 'melofo'?
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
Saben de algún juego que utilice el motor del doom 3 (IDtech4 ) que este para jugar en linux ??
#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.
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.
Mucho código limpio y aseado y no incluyeron una linterna pegada a las armas...XD O más acción y menos sustitos.
S.O.L.I.D. (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion)
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.
¿y donde pones que está en inglés?
#3 Ya
#4 Gracias majo
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.
int Comida;
Espero que os duelan los ojos. Pero ESE fallo lo he visto muchas veces, y me da vomitera.
Nada que no se pueda hacer en cualquier consultoria informatica de este pais.... :\
¿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.
#11 ¿Eres indio?
#14 Si
#11 Gawker, en general, da la risa.
Label1.text = textbox1.text
Eso si que es codigo limpio
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.
Tienes que salir mas
Eso es como si un arquitecto dice:"Que bonitos son los ladrillos de ese edificio". Una chorrada porque que no se van a ver.
#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.
#73 Si pero por muy bonitos que sean, no se ponen solos. Más importante es que el resultado sea bonito, creo yo.
#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.
#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.
#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.
#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”.
#98 Y suele pasar que por fijarse en cosas menos importantes como esa, luego se cae el edificio...