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...
El propio John Carmack respondió a este artículo: http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
#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.
#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!
#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).
#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?
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.
#11 ¿Eres indio?
#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++).
#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?
Se lo ha currado un huevo y tiene razón, esta bonito y bien hecho.
#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.
#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?
#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
#102 El else se evita con un if invertido:
if (x=y)
#118 Pues no deberíamos haber llamado a troll.feed()
Joer como se flipan algunos
#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
#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.
#79 #25 Esto sólo lo entendemos los que hemos aprendido a programar en monitores de 14 pulgadas a 800x600 o 1024x768
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".
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.
#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
#121 ¿El bolsillo de Microsoft está dañado? ¿El de Google (Chroome es C++)? ¿El de Valve? ¿Autodesk?... ¿Cuál es la alternativa real, portable y no interpretada a C++?
"(léase no tener que andar preocupándose de cazar memory leaks"
¿Te crees que se puede aprovechar bien el hardware sin lidiar con la memoria?
Fap Fap Fap Fap ...
#14 Si
#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!
#26 Menos de 3 espacios no es tabulación, es error tipográfico. 2 espacios, golpe de remo. 1 espacio, pelotón de fusilamiento.
#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
¡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í.
Pues hay fallos por la mezcla de diferentes estilos. Incluso dentro de un mismo fuente. Por ejemplo en ui/BindWindow.cpp:
68 if (waitingOnKey)
#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
Y que nadie haya subido esto, tras la airada discusión sobre los tabuladores vs espacios...
#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.
#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?
#108 Que se caiga el edificio por lo malos que son los ladrillos no es responsabilidad del arquitecto, igual que si falla una aplicación por lo mal que la ha compilado el compilador no es responsabilidad del programador.
#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”.
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.
#117 A mi que
CapitanObvio es un troll orientado a objetos y que sus comentarios solo eran para tocar las narices.
#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/
#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.
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.
#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?
Disidentes!!
#126 la memoria es más barata que horas de programación por eso Java EE desde hace más de una década está presente en gran parte de los servidores de soluciones empresariales transacionales. Al César lo que es del César.
la regla que más me gusta: fuera comentarios, el código debe ser autoexplicativo
el mejor apoyo:
- funciones pequeñas
- no te repitas
- cuida el diseño
- busca las mejores pautas de programación para el lenguaje que se trate y aplícalas sistemáticamente
llevo toda mi vida profesional siguiendo esa pauta. A veces, si reviso mi código antiguo, todavía puedo seguirlo
#25 tu ni caso, que les den
#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.
#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.
#130 GNUstep http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_1.html
Sí, OSX está a años luz, pero con GNUstep y Objc han mantenido hasta servidores...
#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.
#148 Solo por lo que has dicho te mereces la peor de las torturas.
Así te pases debugueando días y noches
#25 yo lo hago como tu... la verdad es que nadie me ha dicho nada... la otra forma me parece de retrasados...
#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.
#51
Dios, no puedo creer que digas eso en público.
#105
Al compilar los condicionales no se convierten en saltos incondicionales. Hay instrucciones específicas de ensamblador que evalúan una condición y saltan o no saltan según si se cumple o no la condición. El compilador GCC por ejemplo admite el uso de macros (likely, unlikely) para ayudarle en la toma de decisiones a la hora de ordenar las instrucciones según la predicción más común de salto.
Es en este tipo de saltos en los que las tablas de predicción de los procesadores funcionan mejor, lo cual incluye a los bucles, algo muy común en cualquier programa normal.
#142 Das en el clavo con las 2 cosas. También está el problema que he mencionado en #132, el indentado puede inducirte a pensar erróneamente que está bien, cuando el else en realidad pertenece al último if (de hecho, eso me ha pasado, lo que dices tú no por que siempre me acuerdo de añadir llaves :P). Alguna vez he pensado en poner las llaves siempre por comodidad al añadir luego cosas, pero no me termino de poner de acuerdo conmigo mismo, no me gusta poner elementos que no son necesarios
.
#140 Se puede usar C++ sólo parcialmente y es muy útil. Quizás tengas razón en lo que dices, pero programar un juego completo en C a secas es una locura, hacer un uso aunque sea básico de objetos ayuda mucho. Además tiene un montón de cosas que pueden facilitar la vida (o complicarla). Lo bueno es que puedes usar un nivel de abstracción diferente en cada parte de la aplicación.
#145
Me he leído el comentario de 140 y de razón más bien poca.
Personalmente te recomiendo que le eches un vistazo a C++11.
La mayoría de quejas de C++ que estoy leyendo vienen por una forma de programar cuanto menos cuestionable. Si vas a criticar a un lenguaje no lo hagas por lo que haces sino por lo que no te permite hacer o por si cosas que te permite hacer las complica demasiado. Muchas cosas de las mencionadas no son necesariamente tan complicadas, pero C++ si lo deseas te deja hacerlas de la forma más retorcida que prefieras, y Java no se queda corto. Sin embargo no son lenguajes intrínsecamente retorcidos.
Respecto a los setters y getters, me parece una soberana estupidez lo que se comenta y no hace falta leerse gromenawer y jaiclander para llegar a la conclusión de que no hace falta poner getters y setters para todo. La regla básica es mantener un acoplamiento entre clases mínimo y poner la funcionalidad donde toca sin redundancias, algo que requiere un poco de pensamiento.
#146 Yo no me voy a pronunciar al respecto, no tengo experiencia suficiente como para criticar o alabar un lenguaje por encima de los demás salvo para algunas cosas que me parecen obvias (como que Java es demasiado lento para hacer videojuegos ). Pero sí que tengo la sensación de que los que critican a C/C++ (sobretodo los que critican C) es por que no saben o no quieren saber programar. Especialmente cuando se quejan de problemas con la gestión de memoria (¿alguien tendrá que hacerla no? ¿O se piensan que los lenguajes que te abstraen de ella no tienen máquinas virtuales o sistemas que lidian con ella y que alguien tiene que programar?
#148 A eso no le veo sentido alguno. Las funciones ya se diferencian por el nombre y los paréntesis. Además, generalmente no es como dices, por ejemplo, todas las funciones de OpenGL empiezan con minúscula (glVertex3f(), glEnable()...) y las de la API de Windows, y en general no he visto nunca nombrarlas con mayúscula.
Y los nombres de objetos me parece muy absurdo ponerlos con mayúscula.
#152 ¿Sabes por qué ya no está el pinball en Windows? Por que su código, al parecer, era una castaña, y no pudieron actualizarlo. Que un programa esté bien hecho es muy importante a niveles que ni sospechas. Claro que a un usuario le interesa la jugabilidad, pero la jugabilidad se va a la mierda cuando no se puede corregir un bug, cuando va lento, cuando la física se comporta de forma poco predecible, etc.
#157
Los getters y setters son necesarios, tener un montón de clases singleton no lo es. No hace falta usar Spring o JEE para saber lo que es el estado.
Si no has aprendido o no te han enseñado bien entonces quizá sí que necesites leer gromenawers y klandersjanders, y entonces es cuando se puede cagar de una forma muy sencilla por falta de información contrastada de calidad o incapacidad de un uso adecuado de la misma.
C++11 no arregla nada, añade nueva funcionalidad y tampoco llega tarde, llega cuando está terminado.
Mi campo tampoco es el de los videojuegos, pero C++ no es una mierda que convierte el código en inmantenible. Eso lo hacen los que programan. Y el tema de utilizar python o lua o perl o cualquier otro lenguaje incluido cualquier lenguaje de consola se combina con cualquier cosa, no sólo C.
Cualquiera que diga que C++ es una mierda más vale que se dedique a otra cosa. Lo mismo va para C.
#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.
#88 mmm, pero en videojuegos no puedes usar Try and Catch, son muy lentos y algunas consolas no lo soportan...
#110 Si sigues leyendo el artículo verás que habla de eso:
Another thing that id does that I believe is "right" and not a style issue is they ALWAYS use even when optional. I think it's a crime to skip the brace brackets.
[..]
Omitting the optional makes parsing this while() block more time consuming than it needs to be. It also makes editing it a pain
#3 Ya
#129 El principal problema de no usar llaves está en las revisiones del código y los despistes, creo yo.
Tu pones:
..if ( condition )
....doSomething();
..else
....doSomethingElse();
y no hay problema.
Hasta que alguien se da cuenta de además de llamar a doSomethingElse() hay que llamar a doEvenAnotherThing() y te pone esto:
..if ( condition )
....doSomething();
..else
....doSomethingElse();
....doEvenAnotherThing();
La identación en este caso hace incluso más difícil ver el fallo. Pero puede ser algo muy, muy maligno.
#139 No es cuestión de tamaño. Añadir más memoria es fácil (a veces, como matiza #141): hacerla más rápida no. Cuanto más tengas que acceder a memoria, más lenta será tu aplicación, y necesitarás más servidores rendundantes para dar soporte a la misma cantidad de gente. Éstos servidores, claro, consumen su electricidad (mensual), requieren de refrigeración, y por supuesto de mantenimiento. ¿Pagas a los programadores el doble de tiempo o mejor pagas todos estos extras mensualmente? Pues supongo que dependerá del caso concreto te compensará o no...
Y eso hablando de servidores, hablando de aplicaciones interactivas ya pues ni te cuento lo que requerir el doble de memoria puede hacer.
#167
en c++ existen tipos básicos mezclados con objetos.
Como en cualquier lenguaje.
- En Java existe una jerarquia de objetos, todo es un Object. C++ carece de un tipo raiz.
Esto es falso y el que en Java los objetos hereden de la clase Object tampoco es una ventaja.
Respecto al tema de las aplicaciones es una pena que se utilicen lenguajes como Java, objective-c, ruby o python. Así se notan los retardos y falta de interactividad en muchas aplicaciones, resultando en programas de baja calidad.
Te puedes ir a contar mentiras y demostrar tu inutilidad a otro sitio.
¿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...
#18 hombre 'Rage' usa un motor del que ha sido padre y como juego no esta nada mal
#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".
#158 Pues nada hombre, tu sigue usando getters&setters y no leas libros que ya lo sabes todo, ains... que paciencia. (por cierto, lee mejor, que exista una sóla instancia no implica necesariamente que estemos hablando de un singleton, en realidad en el caso de spring/jee no son singletons, simplemente se instancian sólo una vez, que no es lo mismo).
Evidentemente un lenguaje no es el culpable de un mal código, ni tampoco el responsable de uno bueno, eso es cosa de los programadores. Cuando se analiza un lenguaje se hace desde la perspectiva de como de facil es hacer las cosas bien y como de dificil es hacer las cosas mal con ese lenguaje. Y c++ comparativamente con otros lenguajes de similares características, ni pone facil hacerlo bien ni pone difícil equivocarse.
Por cierto, nadie ha dicho que c++ "sea una mierda", simplemente que hay cosas mejores. Sólo los talibanes hacen valoraciones absolutas.
PD: ahhh una ultima cosa, si se trata de usar algo de más alto nivel para hacer más mantenible ciertas partes del código, por dios, no useis PERL!
#2 Se tiene o no se tiene.
Que me hagáis leer los comentarios de esta noticia me preocupa, más por mí que por vosotros, panda de zumbaos.
#173
Java tiene un objeto base para todos los objetos, pero eso no significa que todo pertenezca a la clase Object ya que en Java existen también los tipos básicos. Y me parece insultante que pretendas comparar las utilerías y genericidad de código con Java y C++ (y más aún con C++11) con Python, Ruby y demás fauna y las incompatibilidades entre intérpretes.
Hay mucha gente con 20 años de experiencia y no ha aprendido a utilizar realmente un lenguaje, tú pareces ser uno de ellos. Si buscas rendimiento y aprovechamiento del hardware junto con una gran flexibilidad y reutilización del código escoges C++, por otra parte C también es un lenguaje de alto nivel pero sin orientación a objetos, aunque existen bibliotecas como GTK que emulan la orientación a objetos gracias a la potencia de los punteros, potencia que combinada con un lenguaje ya orientado a objetos como C++ tienes una herramienta genial. Orientación a objetos sin un lenguaje orientado a objetos es un dolor de huevos.
C++ te permite estar donde quieras, gracias a su naturaleza multiparadigma. Ahora bien, la potencia sin control no sirve de nada por lo que quizá es mejor que utilices otros lenguajes mejores para manos incautas sin control, míster 20 años desaprovechados.
#167 ¿Te pido una alternativa a C++ y me pones lenguajes totalmente orientados a objetos? ¿Y, peor aún, interpretados?
#181 Esa comparación de pollas que has pedido es bastante absurda y sus resultados también. Especialmente cuando ya has quedado en evidencia dando un lenguaje interpretado y orientado a objetos como alternativa a un lenguaje nativo y multiparadigma.
#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.
#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.
#112 Se nota que no eres programador.
La calidad del proceso influye directamente en la calidad del producto final.
Pensándolo bien no creo que haya que ser programador para darse cuenta de eso, sucede en cualquier profesión...
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...
#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
#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á.
La verdad es que yo uso los get/set cuando uso las librerías del framework (ahora estoy con Zend), cuando son clases propias, intento hacer funciones pensadas.
A decir verdad yo siempre veo mi código mejorable, nunca he hecho algo que diga me gusta, siempre veo el código y pienso que es mejorable, no digo que mi código sea malo si no que es mejorable.
Y bueno, sobre las llaves, a mi me enseñaron asi:
if(condición)
else
Aunque si es una sentencia, hago esto if(condición) acción
Y bueno, poco mas comento porque qui esta hablando gente bastante mas experimentada que yo.
#167 #168 Creo que es bastante evidente que comparar Ruby/Python con C++ no es demasiado acertado, más que nada porque se usan en ámbitos muy distintos, y cada uno aprovecha mejor sus características.
Yo como estoy haciendo aplicaciones web ni se me ocurriría programarlas en C++, sino que tiro por ruby (como podría tirar por python) o, como en la universidad me imponen, java. Lo mismo para hacer scripts rápidos o scrapping de datos online. No, C++ no sería lo más eficiente.
De la misma manera si quisiera programar un juego 3D con alto rendimiento ni de coña lo haría en ruby/python, sino en C++, que iría mil veces mejor.
No entiendo estas luchas talibanescas (si me dices la pelea ruby vs python aún, pero ruby/python vs C++?), cada herramienta tiene su función.
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 ??
#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.
¿Hay que decir 'melofo'?
#25 Pues yo siempre lo hago así, me parece más legible.
#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?
#109 En un edificio lo importante es que no se caiga, en un juego lo importante es que le guste a la gente. El concepto de responsabilidad es diferente.
#120 Los nombres de las funciones y objetos se ponen con la primera mayuscula y los nombres de las variables se ponen en minúscula. Si lo haces de otra forma es porque te huele el pito a cebolla.
Paz!
#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.
#30 A las 2:00 en la puerta del colegio me lo cuentas.
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.
#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.