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

#101   #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.

#102   #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?

Edit: Por cierto ¿cómo evitas un else en general? Me refiero a ¿cómo gestionas alternativas?

#103   Pues la verdad es que respeto mucho a Carmack pero justo los punto que propone el articulo no estoy muy deacuerdo:

- me encanta los parentesis en lineas diferentes, anyaden legibilidad y la pantalla del codigo la tengo en horizontal, con lo cual el espacio no es un problema

- me gusta comentar casi todas los metodos, asi sabes a vista rapida done empieza y acaba cada uno cuando lees un cpp

- usar const es importante, pero no es necesario en las varables int, el compilador lo optimiza de todas formas y creo que solo anyaden ruido al codigo

Por otra parte estoy muy de acuerdo en abolir getter y setters cuando sea posible asi como no implementar los metodos inline en la misma cabecera.

#104   #101
Un throw es condicional.

#103
Si indentas bien los paréntesis en distintas líneas no añaden legibilidad, todo lo contrario, terminan añadiendo confusión.

Los const son importantes para evitar modificaciones de memoria no autorizadas. Si una variable es sólo de entrada, declárala como tal.

#105   #101 Incluso cuando compilas cualquier condicional termina convirtiendose en un goto. No estan mal vistos porque funcionalmente sean incorrectos, sino porque complican la lectura y comprensión del código.
Y no soy muy talibán de los gotos. En sistemas de tiempo real, kernels, juegos.... es muy importante optimizar la ejecución del código y un goto te puede ahorrar ciclos de reloj. Si lo muliplicas por miles de ejecuciones de esa párte del código te puede ahorrar mucho.
Eso si, si veo a alguien que para calcular un préstamo mete un goto le crujo

#106   Es un artículo bastante ameno, e instructivo.

#107   #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.

#108   #98 Y suele pasar que por fijarse en cosas menos importantes como esa, luego se cae el edificio...

#110   #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.

#111   #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).

#112   #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.

#113   Odio C++

#114   #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.

#115   #113 Como persona que en su día gustaba de C++ y que gracias al cielo tuve la suerte de poder ampliar miras y descubrir vida más allá de talibanismos varios, aquí te dejo un regalito (en inglés eso sí), para que puedas fundamentar tus críticas a C++. Eso sí, está en inglés:
yosefk.com/c++fqa/

#116   #115
¿Quieres decir que te dejó de gustar C++?

yosefk.com/c++fqa/picture.html
Me parece una risa.

#117   #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.

#118   #117 A mi que @CapitanObvio es un troll orientado a objetos y que sus comentarios solo eran para tocar las narices.

#119   #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

#120   #25 Lo de los condicionales, me da igual siempre que no escribas los nombres de las funciones empezando con mayúscula. Eso lo odio.

#121   #116 Quiero decir que descubrí que se podían hacer cosas igual de buenas o mejores mucho más rápido y de forma mucho más segura con lenguajes que no eran una chapuza, inconsistentes, llenos de features y que sólo servían para inflar los egos de la gente que escribía en ellos (o sea, C++).

Como dice el autor del fqa, si quieres trabajar a bajo nivel, usas C, compacto, predecible, coherente y que permite orientación a objetos si se necesita y conoces bien el lenguaje.
Si necesitas un lenguaje orientado a objetos, usas cualquier otro con soporte para objetos de verdad, no la mezcla ridícula de C++ que tiene todos los inconvenientes de un lenguaje de bajo nivel, y todos los inconvenientes de un lenguaje orientado a objetos, pero ninguna de las ventajas. Otra gran verdad que dice el autor del fqa: si necesitas rendimiento y optimización, no usas C++, usas C. Si te preocupas por medir el rendimiento (es decir cronometrar) tus programas en lugar de hablar de rendimiento teórico no usarías C++, porque entonces te serviría con cualquier otro lenguaje en teoría mucho menos "rápido" (digamos Java, C#, el que sea) que te ofrezca soporte real para objetos (léase no tener que andar preocupándose de cazar memory leaks, mensajes de error crípticos en templates, y cosas por el estilo que pueden consumir un porcentaje de tiempo gigantesco en un proyecto de C++ y que a la hora de la verdad no aportará nada al producto final aparte de un riesgo constante de bugs que en otros lenguajes símplemente no existen).


Es un lenguaje que trabaja duramente para hacer la vida difícil y complicar las cosas mucho más allá de lo necesario, con un montón de supuestas features mal diseñadas, casos raros, inconsistencias y features (como las excepciones) que muchas veces hacen lo contrario de lo que deberían hacer en cuanto a facilitar la labor.

Yo he llegado a programar videojuegos con C++, unas jerarquías de clases que te cagas, con mucha satisfacción por empezar a dominar un lenguaje tan puñetero, y en aquella época como no conocía mucho, me parecía la panacea. Cuando no conoces nada más, es normal. Hasta que descubres que has estado haciendo el primo y malgastando neuronas en resolver no-problemas que otros lenguajes han resuelto hace milenios. Hay una serie de razones por la cual gente como Linus Torvalds y otros no lo quieren ni cerca.

Es una pena que tenga poco soporte, pero D (de Digital Mars) es lo que debería haber sido C++ desde el principio.

Java tuvo el éxito que tuvo en el mundo empresarial por la sencilla razón de que es una evolución de C++ pero mucho mejor diseñada, quitando gran parte de lo que hace mal C++ que en última instancia daña el bolsillo de quien paga el proyecto. Y eso a los programadores puede no importarles mucho, pero a los que sueltan la pasta ya te digo yo que sí.
Incluso uno de los nichos en los que se sigue usando muy a pesar de muchos que lo tienen que sufrir (videojuegos), en una conferencia de hace unos años del GDC se habló del problema que suponía tener que usar C++ para proyectos tan grandes y complejos, que los bugs introducidos por la inseguridad inherente del lenguaje les suponían en muchos casos más del 60% del tiempo de desarrollo y que si cambiasen a otros lenguajes más adecuados los proyectos saldrían más rápido y con menos bugs.

#122   #8 Los buenos programadores no ponen comentarios. El código es obvio!

#123   #121
Lo que le pasa al autor del FQA es que no sabe C++ y probablemente no sepa programar.

Lenguajes no hay ninguno perfecto, eso ya lo sabemos todos, pero esa FQA dice muchas tonterías. Quizá debería hablar con Bjarne Stroustrup y de paso no basarse en un FAQ de una página web de terceros mantenida por no se sabe quién.

Lo que haga o deje de hacer Linus Torvalds es poco relevante para C++, ya que no vas a utilizar dicho lenguaje para programar un kernel, eso lo sabe hasta el apuntador.

Y respecto al resto de tu comentario, por favor, directamente vete al cuerno

#124   #102 El else se evita con un if invertido:

if (x<y) {}
if (x>=y) {}



#118 Pues no deberíamos haber llamado a troll.feed()

#125   Una pregunta, por qué se supone que está mal lo siguiente?

if (condicion)
lo que sea
else
lo que sea

Me enseñaron así, pregunto por ver la opinión general.

PD: No salen las tabulaciones, pero lo de debajo del if y del else está tabulado.

#126   #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?

#127   #125 Está perfecto (si lo tabulas). Aunque siempre depende del contexto.

#128   #126 Como no sea Objetive C...

#129   #127 lo decía más que nada porque en la susodicha web acusan no menos que de crimen el no usar las llaves, y yo no encuentro el problema, la verdad...

#130   #128 No creo que tenga la misma portabilidad ni de lejos, aunque lo desconozco. Yo no lo usaría fuera de Apple suponiendo que se pueda.

#131   #130 GNUstep www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManu

Sí, OSX está a años luz, pero con GNUstep y Objc han mantenido hasta servidores...

#132   #129 Puede haberlos:

if ()
....if ()
........//algo
else
....//algo

Ahí tendrías un problema que puede surgir sin darte cuenta. Mierda sin los espacios no se entiende bien EDIT: Ahora son puntos.

#133   #111 No es una salvajada por que se trata de abstraer el uso de la implementación mediante una interfaz. Y si la función es inline en teoría ni siquiera hay merma en el rendimiento.

#134   #69 Jajaja... me has hecho reír... gracias, no todos los días hay motivos para sacar una sonrisa.

#135   #11 Gawker, en general, da la risa.

#136   #131
Bueno, si es por rendimiento, Objective-C no podrá sustituir a C++. Se acerca más a Java, lenguaje en el que también hay servidores hechos.

#137   #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

#138   #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á.

#139   #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.

#140   Después de muchos años programando en C++ de lo que más me alegro es de no tenerlo que usarlo más. Para mi incumple la regla número de 1 de cualquier sistema software: mantenerlo lo más simple posible. C++ es complejo hasta decir basta. Si quieres rendimiento C (rendimiento algorítmico o en consumo de memoria se entiende, que la realidad es que salvo motores gráficos y cuatro cosa más en 90% de los problemas de rendimiento del software tienen más que ver con IO que con ninguna otra cosa). Si quieres otras cosas como mantenibilidad, legibilidad, productividad entonces tira por lenguajes como java o C# o mejor aún, por lenguajes dinámicos tipo python, ruby, groovy... o incluso funcionales como scala, clojure o haskell.

Sobre el tema de los getters/setters, en realidad son una practica de programación bastante horrenda que tiene más que ver con seguir las pautas de determinados frameworks (spring o jee por ejemplo) que con una necesidad real. Suelen ser un sintoma bastante evidente de la presencia de un modelo anemico (martinfowler.com/bliki/AnemicDomainModel.html), existen mejores alternativas com por ejemplo diseñar OO centrandonos en el paso de mensajes (El GOOS quizá sea el mejor libro sobre el asunto www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/032150) o por ejemplo realizar un diseño centrado en el dominio (el libro de referencia de esto ultimo: books.google.es/books/about/Domain_Driven_Design.html?id=7dlaMs0SECsC&). Además los dos enfoques anteriores no son en absoluto incompatibles. Incluso en el libro clasico de la OO de meyer (otro que hay leerse antes de hablar de OO alegremente: www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/01) no creo que encontreis muchos getter&setters.

Personalmente estoy bastante de acuerdo con algunas de los "consejos" del articulo, como no escribir comentarios sino código claro, escribir funciones cortas etc,etc. Aunque en realidad la mayoría de los consejos son muy "C++" y no aplican en general (el tema de los templates y la stl por ejemplo). Incluso en los ejemplos que pone hay algunas cosas que me rechinan bastante como funciones que reciben muchos parámetros (2 o 3 es mi limite) o un uso excesivo de "if-else-if" que puede ser sustituido con un uso más adecuado del poliformismo, aunque no dire que esta mal, porque tratandose de un motor gráfico quizá obedezca más a temas de rendimiento que a temas de diseño, lo que sería perfectamente comprensible. El polimorfismo, especialmente en C++, añade un nivel de indirección que logicamente cuesta ciclos de CPU.

#141   #139 No. Es más barata cuando es para ti. 1000 horas más o 10GB más? Pero si esas 1000 horas son para un programa con millones de usuarios ya no es para nada una opción despreciar la memoria. Además, en determinados ámbitos la memoria está limitada y no se puede ampliar (teléfonos móviles, consolas...).

#142   #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.

#143   #141,#142 claro, la clave es esa... cada propósito requiere su herramienta. Yo he puesto un contraejemplo en el que java se usa mayoritariamente.

#144   #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...

#145   #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.

#146   #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.

#147   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)
{
/* código */
}
else
{
/* código 2 */
}

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.

#148   #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!

#149   #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.

#150   #148 Solo por lo que has dicho te mereces la peor de las torturas.
Así te pases debugueando días y noches

#151   #150 #149 Eso que comenta #148 no lo he visto nunca

#152   #144 Solo te falta explicar por qué. Seguramente lo leíste en algún sitio y así te quedó. Pero la realidad es que una buena herramienta no garantiza que el resultado vaya a ser bueno. El éxito de un programa en el mundo real no es que sea bonito para los programadores. Ejemplos a montones si quieres.

#153   #152
Depende como midas el éxito. Si mides el éxito como cantidad de gente que utiliza el programa, entonces WhatsApp es un logro. Ahora bien, si añades a la medida de éxito las dimensiones de «seguridad» y «fiabilidad» entonces WhatsApp pierde muchos puntos.
Y aunque eso la gente no lo valora a la larga pasa factura y no sólo en cuestiones inmateriales sino también económicas (productos no contratados, información no solicitada, pérdida de tiempo, etc.).

¿Nadie recuerda que en el MSN Messenger ponía que nunca dieras tus números de teléfono, tarjeta, etcétera utilizando dicho programa? Pues si lo ponía ese mensaje era precisamente porque siempre hay alguien que lo hace, y con las redes wifi sin cifrar que te puedes encontrar en muchos sitios utilizar un servicio como WhatsApp es una jodida mina. Vamos, tengo el suficiente tiempo libre y no dudaría en irme a cualquier lugar público a ver lo que pesco.

#154   #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.

#155   Se puede conseguir un rendimiento igual o superior a C con C++ (también peor si no sabes lo que haces) sin problemas

#156   #153 Tu mismo lo dices WhatsApp es un éxito sin duda. Facebook empezó como una basura y ahí está. Influyen muchos factores. Por ejemplo en su día Google tenía competencia y sus competidores no eran mucho peores pero la publicidad empezó a molestar y Google tuvo una buena idea.

#154 Ya pero es que yo no dije lo contrario, un programa tiene que estar bien hecho, hasta ahí íbamos a llegar...

#157   #146 Hombre evidentemente las relgas basicas son bajo acoplamiento, alta cohesión y evitar duplicación. Pero si vieras una base de código de 100k lineas llena de "javaBeans" absolutamente anemico y con toda la logica en "clases función" (clases de las que sólo existe una instancia en la aplicación y que no tienen estado, los que usen spring o jee saben de que hablo) entenderías que la critica a los getters&setters más que por la "maldad" o no propia de estos es porque suele ser sintoma de problemas mucho más graves.

Y diseñar bien no es tan sencillo para todos, no esta de más leer gromenawers y klandersjanders para aprender de la experiencia de otros y no pensar "que basta" con lo que uno sabe y que "todo esta inventao y es muy sencillo", la realidad es que tan sencillo no debe ser cuando la mayoría de los proyectos que superan cierta embergadura terminan convirtiendose en una autentica pesadilla de mantenimiento.

C++11 arregla cosas, pero llega tarde no, lo siguiente, y digo "llega" por no decir "va llegando" que ni de coña todos los compiladores de C++ tienen soporte todavía.

No es mi campo los videojuegos, pero si he visto mucha gente utilizar C para el bajo nivel mezclado con algún lenguaje de más alto nivel como python o lua para scriptar logica que no requiere técnicas de bajo nivel.

#158   #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.

#159   #152 Te estás liando: yo he dicho que el proceso influye en el producto, no que un buen proceso garantice un buen producto. Obviamente son cosas diferentes.

Y por otra parte estás mezclando éxito y calidad, que de nuevo son cosas muy diferentes.

#160   #116 "Don't switch from C to C++ unless you need virtual functions!" WTF

#161   #159
Claro que influye, influye todo y el método también.
Yo no hablé en ningún comentario de calidad. La calidad se puede medir, si hay normas internacionales de calidad de código me parece muy bien pero las empresas buscan éxito no calidad, por algo son empresas con ánimo de lucro.

#162   #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!

#163   #162 ¿Cuáles son esas cosas mejores? Por que si la mayoría de aplicaciones de escritorio se escriben en C/C++ por algo será...

#164   #162
Sólo los talibanes hacen valoraciones absolutas.
Como por ejemplo, ¿tu?

#165   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

#166   #61 Hace muchos años que no toco C++, pero sería con un friend?

#167   #163 hombre hay muchas cosas, algún ejemplo sencillo con distintos lenguajes:

- En ruby todo es un objeto, en c++ existen tipos básicos mezclados con objetos.
- En Java existe una jerarquia de objetos, todo es un Object. C++ carece de un tipo raiz.
- En C# existen funciones lambda/closures.
- En Scala existe soporte para mixins/traits que son una buena solución a los problemas de la herencia multiple.
- En Eiffel existe soporte para diseño por contrato como parte del lenguaje

Hay mil ejemplos más, uno anecdótico pero que ejemplifica el problema de complejidad de c++, el hola mundo:

En C++ :

#include <iostream>
int main()
{
std::cout << "Hola mundo\n";
return 0 ;
}

en Ruby:

puts 'hola mundo'

Respecto al tema de las aplicaciones de escritorio, hoy en día representan una parte bastante minoritaria del conjunto de proyectos software, podriamos preguntarnos también porque nuevas plataformas de desarrollo (android, ios, cualquier servicio de cloud como heroku o google application engine) no optan ninguna de ellas por c++ y prefieren java, objetive-c, ruby o python. No se puede negar que C++ se sigue usando bastante (mirar el indice tiobe www.tiobe.com/index.php/content/paperinfo/tpci/index.html) y existen buenas librerías y buenos desarrollos en C++ , QT mismo, pero eso no quita para existan otras alternativas más interesantes para comenzar hoy en día un nuevo proyecto.

#168   #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.

#169   #138 Cuando dices "en una revisión puede venir otro más", no acabo de entender cuando puede haber otro else cuando haces una condición sobre un elemento booleano, pero vale.

De todas maneras a mi modo de ver es un debate estéril, decir que un if - else es mal diseño sin más argumentos y quedarse tan ancho para mi es síntoma bastante claro de no tener mucha idea.

#170   #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.

#171   #170
Yo no he iniciado ninguna discusión vacía, aunque haya colaborado en la misma. Por otra parte utilizar Java para aplicaciones web pues depende de las ganas que tengas de hacer algo y también del rendimiento que quieras y de la memoria que tengan tus servidores. Para Java hay muchísimas bibliotecas hechas de todo tipo y para todos los colores.

Ahora bien, si vas a hacer webs para dispositivos empotrados, una mezcla de CGI hecho en C++ con JavaScript que se ejecuta en el cliente es una gran idea.

#172   #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.

#173   #168 Hombre no niegues evidencias, ruby o smalltalk por poner otro ejemplo, no tienen tipos básicos. Busca en interné Lo mismo lo de la jerarquía de objetos, TODOS los lenguajes OO posteriores a C++ incluyen un tipo base. Puede ser que TODOS los diseñadores de java, c#, python, ruby... esten equivocados y tu tengas razón, de momento y sin conocer tus meritos, me inclino a pensar lo contrario.

Por resumir, ¿no habría que usar nunca java, ruby o pyton?, ¿c++ es siempre la mejor opción que si no las cosas van lentas?.

#170 Exacto, si estoy contigo, los lenguajes son sólo herramientas. Personalmente no elegiría C++ salvo que no me quede otra alternativa (librerías heredadas, continuar con un proyecto etc,etc) si quiero rendimiento y aprovechamiento del hard prefiero C, si quiero alto nivel también prefiero otras cosas. Y esto lo digo sabiendo programar en C++ desde hace casi 20 años y después de haberme ganado la vida programando en el durante más de 8, vamos que algo de cariño y respeto le tengo, pero siendo objetivos, tiene demasiados defectos.

#174   Y que nadie haya subido esto, tras la airada discusión sobre los tabuladores vs espacios...  

#175   #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'.

#176   #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.

#177   #176 me canso, como decía un amigo mio cuando las discusiones sobre programación llegan a punto muerto, show me your code my friend!. Si escribes tan buen código C++ que lo que los mortales como yo consideramos complejo tu lo consideras pan comido, pon algún enlace a github, sourceforge u lo que sea y vemos realmente de que estas hablando. No pienso gastar más tiempo en palabras, show me your code or shut up!

#175 Sobre el tema del if, habéis visto: www.antiifcampaign.com/ es viejuno ya y no tiene mucha cosa, pero es simpatico

Y ya que hablamos de enseñar el código, sobre el tema de exceso if, en google code podéis echar un ojo a la kata gildedrose de refactorización que hice hace tiempo (un ejercicio para unas charlas) este es el código original a mejorar:

code.google.com/p/katagildedrose/source/browse/trunk/GildedRose/src/ma

Podéis ver en el proyecto de google code la descripción del ejercicio y luego hay un par de branchs, uno con el código con test unitarios y otro con test unitarios y el código refactorizado con un mejor diseño que evita "la maraña" de if's.

No es que los if's esten mal, los condicionales son necesarios claro esta, el problema esta en el abuso y no usar otras técnicas de programación más que el "if-else-if"...

#178   #177
Me alegro de que ante una imponente verdad decidas tener dignidad.

#179   #178 Pero pon algo de código hombre, no seas timido.

#180   #179
Para qué, seguro que dirías que el código es una mierda, es una forma fácil de continuar la discusión.

#181   #180 que va, lo facil es el bla,bla,bla y la descalificación gratuita, lo difícil es demostrar lo que uno dice. Tienes una oportunidad de demostrarnos como se hacen las cosas, no la pierdas!.

Oye, a lo mejor nos sorprendes con alguna maravilla, yo siempre estoy dispuesto a aprender de quien sabe más que yo, aunque me temo que lo más probable es que te quedes en el bla,bla,bla. Ale, hasta otra crack!

#182   #181
que va, lo facil es el bla,bla,bla y la descalificación gratuita,
Me lo creo, es lo que tú haces.

Tienes una oportunidad de demostrarnos como se hacen las cosas, no la pierdas!.
No tengo la oportunidad de demostrar nada, de lo que tengo oportunidad es de seguirte el juego o no.

aunque me temo que lo más probable es que te quedes en el bla,bla,bla. Ale, hasta otra crack!
¿Ves? lo único que buscas es la descalificación gratuita y la provocación.

Por cierto:
if (!"Sulfuras, Hand of Ragnaros".equals(items.get(i).getName())) {
....items.get(i).setQuality(items.get(i).getQuality() - 1);
}

Vigila con las indentaciones y el encadenado de llamadas a métodos, el código resultante puede ser una soberana castaña en términos de legibilidad y comprensión.

#183   #182 esto...

Ese código es el punto de partida de un ejercicio de REFACTORIZACIÓN, es código malo A PROPOSITO, y el ejercicio consiste en dado un código horrendo mejorar el diseño de este utilizando técnicas de refactorización y testing unitario. (TDD y esas cosas que, por cierto, en c++ cuesta bastante hacer por la falta de herramientas y la lentitud del compilador que te jode el ciclo rapido test-code-refactor). Una posible solución esta en el mismo repo en los branch tested y refactored, si leyeras un poco lo había explicado antes...

Por cierto el código original no es mio, es una kata bastante conocida, si buscas en google "kata gildedrose" veras muchas soluciones propuestas, algunas en C++. Echales un vistazo, es un ejercicio bastante chulo y veras muy buenas soluciones en muchos lenguajes.

Ahora en serio, deja de ponerte en evidencia y hacer el tonto, en esta profesión el día que creas saberlo todo estaras muerto, y hazme caso, te quede mucho por aprender, tu decides si seguir haciendo el idiota o no.

PD: por cierto el problema con "el encadenado de llamadas a métodos", se llama ley de demeter (en.wikipedia.org/wiki/Law_of_Demeter), hablemos con propiedad.

#184   #183
Ah claro, es un ejercicio de refactorización, está hecho a propósito. Además y por supuesto el código original no es tuyo.

El que se está poniendo en evidencia y haciendo el tonto no soy yo precisamente, me temo.


(TDD y esas cosas que, por cierto, en c++ cuesta bastante hacer por la falta de herramientas y la lentitud del compilador que te jode el ciclo rapido test-code-refactor)
Madre mía, cuando sepas programar de verdad vuelve al hilo.

#185   #184 madre mia... ¿es que no sabes leer el castellano tampoco?, dale al google primero que no es tan difícil: github.com/emilybache/Refactoring-Katas/tree/master/GildedRose

lo del TDD y eso lo dejamos para otro día mejor que ya me da la risa.

#186   #185
No te preocupes, sé que es el TDD y la integración continua. Metodologías para desarrolladores con discapacidades.

#187   #186 "yo no hago test porque mi código es perfecto", "no necesito integración continua porque mi código no se integra con el resto, lo desintegra".

Están bien como frases de chuck norris, a ver si estoy hablando con chuck y yo sin saberlo

#188   #187
Chuck Norris es sólo un pasatiempo en mis horas bajas.

#189   #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

#190   #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.

#191   #143 "Yo he puesto un contraejemplo en el que java se usa mayoritariamente."

¿Java EE eso que funciona en servidores de aplicaciones?... Si, perfectamente comparable al c++. ^^
¿Sabes el problema de citar a alguien como argumento? Que igual también le reparte a java.
keithcu.com/wordpress/?page_id=2228
www.youtube.com/watch?v=Aa55RKWZxxI

Yo te puedo dar un contra ejemplo donde no lo quiere ni el tato. En mainframes.
También he visto fallar una aplicación porque actualizaron la maquina java. Lo cual es la ostia de divertido que te suceda. Es en esos momentos cuando comienzas a enviar a la mierda a cualquiera que te diga de java que es portable(igual que cuando no hay jvm para la plataforma). ^^

PD: Tienes un sindrome del martillo de oro galopante.

#192   #191 'martillo de oro' dices ensalzando a C++ y en respuseta a una frase donde pone 'cada propósito requiere su herramienta'... tu nivel de compresión lectora si que es galopante. Y ahora has descubierto que en el software hay bugs y errores... y C++ es el mejor contraejemplo para evitarlos ¿verdad? Actualizar la máquina sin más es una burrada perdona que te diga. El lenguaje es cross-platform que no es lo mismo que lo que haga el código lo sea. No voy a entrar a explicar esto, a tortas como tu ejemplo se aprende también.

Vuelvo a insitir, Java se usa mayoriariamente en servidores de aplicaciones SI. Que prefieras otros lenguajes pues bien, pero esa afirmación no es opinable. La disponibilidad de frameworks de nivel empresarial hace que se puedan acometer arquitecturas transacionales complejas con relativa facilidad. Puedes buscar en el mundo real cualquier estadística de uso, de ofertas de trabajo, etc... y verás donde está Java respecto a tus argumentos ad baculum.

#193   #192 'martillo de oro' dices ensalzando a C++ y en respuseta a una frase donde pone 'cada propósito requiere su herramienta'... tu nivel de compresión lectora si que es galopante.
Mi nivel es normal, pero visto el tuyo, no me extraña que te parezca tan superior. Anda, vuelve a leer y si no lo comprendes repite hasta que lo entiendas.
En ningún lugar he hablado del c++, te he dicho donde no nadie quiere el java, si la realidad te duele... te aguantas. Porque precisamente no es que tampoco se utilice especialmente el c++ en los mainframes.

Y ahora has descubierto que en el software hay bugs y errores... y C++ es el mejor contraejemplo para evitarlos ¿verdad?
No era un bug. Y aún siendo un fallo, es meter una capa mas de problemas y fallos entre tu software y el hardware.


Actualizar la máquina sin más es una burrada perdona que te diga.
Pues llama a los de java y comentales que no hagan actualizaciones del jre. No era un servidor, tu que quieres.


El lenguaje es cross-platform que no es lo mismo que lo que haga el código lo sea. No voy a entrar a explicar esto, a tortas como tu ejemplo se aprende también.
Mira, el c/c++/pascal/d también son multiplataforma, y realmente mas que el java. Funcionan en muchas mas plataformas, solo tienes que compilar el código.
La idea(la que venden) del java es que compilas una y debe funcionar siempre en todas... cosa que es no es realista ya que dependes de la jvm, de que sea una versión compatible y que no tenga algún fallo que de problemas con la aplicación.


Vuelvo a insitir, Java se usa mayoriariamente en servidores de aplicaciones SI. Que prefieras otros lenguajes pues bien, pero esa afirmación no es opinable. La disponibilidad de frameworks de nivel empresarial hace que se puedan acometer arquitecturas transacionales complejas con relativa facilidad.
Y eso es prueba de... que han sabido venderlo. No de su calidad.


Puedes buscar en el mundo real cualquier estadística de uso, de ofertas de trabajo, etc... y verás donde está Java respecto a tus argumentos ad baculum.
El argumento ad baculum ha sido tuyo, tu has usado a Linus, si ahora al ver que dice de java te jode... pues te aguantas.
Ademas, las estadísticas como argumento de que es mejor también son una falacia por tu parte. ¿Te suena lo de "comamos mierda mil millones de moscas no pueden estar equivocadas"?

PD: Personalmente lo que no me gusta de java es su necesidad de una maquina virtual.

#194   En serio que lees y no entiendos o no sabes a quien respondes. ¿Dónde he usado yo a Linus? ¿Dónde he dicho que java es lo mejor del mundo para todo y para todos?
Me respondes a que digo que se usa mayoritariamente java en servidores de aplicaciones y tu réplica es que es mentira porque no tienen calidad sino que han sabido venderlo y que las estadisticas de uso son una falacia para argumentar que es mayoritario. Madre mía... sí sí qué nivel.

#195   #194 ¿Dónde he usado yo a Linus? ¿Dónde he dicho que java es lo mejor del mundo para todo y para todos?
Pues tienes razón, acepta mis disculpas, te confundí con otro. ^^

PD: No te he dicho que no tenga calidad, te he dicho que el que sea muy usado no es prueba de calidad.