Menéame: comentarios [1812717]

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

Observer — Sat, 19 Jan 2013 00:19:19 +0000

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

» autor: Observer

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

gershwin — Fri, 18 Jan 2013 23:54:17 +0000

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.

» autor: gershwin

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

Observer — Fri, 18 Jan 2013 13:28:27 +0000

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

» autor: Observer

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

gershwin — Fri, 18 Jan 2013 12:07:42 +0000

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

» autor: gershwin

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

Observer — Fri, 18 Jan 2013 08:44:16 +0000

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

» autor: Observer

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

--151124-- — Wed, 16 Jan 2013 09:46:40 +0000

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

» autor: --151124--

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

Lamercillo — Wed, 16 Jan 2013 06:50:27 +0000

#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

» autor: Lamercillo

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

--347930-- — Wed, 16 Jan 2013 02:45:15 +0000

[Usuario deshabilitado]

» autor: --347930--

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

alfredo_casado — Wed, 16 Jan 2013 02:37:18 +0000

#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

» autor: alfredo_casado

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

--347930-- — Wed, 16 Jan 2013 02:22:35 +0000

[Usuario deshabilitado]

» autor: --347930--

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

alfredo_casado — Wed, 16 Jan 2013 02:10:38 +0000

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

» autor: alfredo_casado

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

--347930-- — Wed, 16 Jan 2013 01:41:13 +0000

[Usuario deshabilitado]

» autor: --347930--

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

alfredo_casado — Wed, 16 Jan 2013 01:37:20 +0000

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

» autor: alfredo_casado

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

--347930-- — Wed, 16 Jan 2013 01:10:13 +0000

[Usuario deshabilitado]

» autor: --347930--

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

alfredo_casado — Wed, 16 Jan 2013 00:53:29 +0000

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

» autor: alfredo_casado

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

--347930-- — Wed, 16 Jan 2013 00:37:07 +0000

[Usuario deshabilitado]

» autor: --347930--

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

alfredo_casado — Wed, 16 Jan 2013 00:32:17 +0000

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

» autor: alfredo_casado

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

--347930-- — Wed, 16 Jan 2013 00:29:30 +0000

[Usuario deshabilitado]

» autor: --347930--

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

alfredo_casado — Wed, 16 Jan 2013 00:26:03 +0000

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

» autor: alfredo_casado

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

--347930-- — Tue, 15 Jan 2013 23:45:11 +0000

[Usuario deshabilitado]

» autor: --347930--

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

gershwin — Tue, 15 Jan 2013 23:41:41 +0000

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

» autor: gershwin

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

ktzar — Tue, 15 Jan 2013 23:29:48 +0000

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

» autor: ktzar

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

alfredo_casado — Tue, 15 Jan 2013 23:06:42 +0000

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

» autor: alfredo_casado

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

molekiller — Tue, 15 Jan 2013 23:00:19 +0000

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

» autor: molekiller

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

--347930-- — Tue, 15 Jan 2013 22:57:33 +0000

[Usuario deshabilitado]

» autor: --347930--

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

MEV — Tue, 15 Jan 2013 22:50:46 +0000

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

» autor: MEV

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

Lamercillo — Tue, 15 Jan 2013 22:41:23 +0000

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

» autor: Lamercillo

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

--347930-- — Tue, 15 Jan 2013 22:38:22 +0000

[Usuario deshabilitado]

» autor: --347930--

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

alfredo_casado — Tue, 15 Jan 2013 22:29:56 +0000

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

» autor: alfredo_casado

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

Shinu — Tue, 15 Jan 2013 22:18:48 +0000

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

» autor: Shinu

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

patata22 — Tue, 15 Jan 2013 22:17:12 +0000

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

» autor: patata22

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

--347930-- — Tue, 15 Jan 2013 22:04:16 +0000

[Usuario deshabilitado]

» autor: --347930--

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

--151124-- — Tue, 15 Jan 2013 21:55:28 +0000

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

» autor: --151124--

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

alfredo_casado — Tue, 15 Jan 2013 21:52:54 +0000

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

» autor: alfredo_casado

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

--127171-- — Tue, 15 Jan 2013 21:35:06 +0000

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

» autor: --127171--

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

--151124-- — Tue, 15 Jan 2013 21:27:18 +0000

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

» autor: --151124--

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

Bedel_roolmo — Tue, 15 Jan 2013 21:20:11 +0000

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

» autor: Bedel_roolmo

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

--347930-- — Tue, 15 Jan 2013 21:18:19 +0000

[Usuario deshabilitado]

» autor: --347930--

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

alfredo_casado — Tue, 15 Jan 2013 21:02:25 +0000

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

» autor: alfredo_casado

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

--127171-- — Tue, 15 Jan 2013 20:52:22 +0000

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

» autor: --127171--

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

Apatikorl — Tue, 15 Jan 2013 20:46:45 +0000

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

» autor: Apatikorl

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

--151124-- — Tue, 15 Jan 2013 20:39:48 +0000

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

» autor: --151124--

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

--347930-- — Tue, 15 Jan 2013 20:39:36 +0000

[Usuario deshabilitado]

» autor: --347930--

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

--127171-- — Tue, 15 Jan 2013 20:36:58 +0000

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

» autor: --127171--

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

MacMagic — Tue, 15 Jan 2013 20:34:22 +0000

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

» autor: MacMagic

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

Yomisma123 — Tue, 15 Jan 2013 20:31:31 +0000

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

» autor: Yomisma123

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

--151124-- — Tue, 15 Jan 2013 20:27:37 +0000

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

» autor: --151124--

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

Cidwel — Tue, 15 Jan 2013 20:26:16 +0000

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

» autor: Cidwel

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

MacMagic — Tue, 15 Jan 2013 20:23:35 +0000

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.

» autor: MacMagic

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

--347930-- — Tue, 15 Jan 2013 20:18:58 +0000

[Usuario deshabilitado]

» autor: --347930--

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

--151124-- — Tue, 15 Jan 2013 20:04:15 +0000

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

» autor: --151124--

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

Bedel_roolmo — Tue, 15 Jan 2013 20:03:21 +0000

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

» autor: Bedel_roolmo

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

gershwin — Tue, 15 Jan 2013 20:00:56 +0000

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

» autor: gershwin

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

jmpep — Tue, 15 Jan 2013 19:57:02 +0000

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

» autor: jmpep

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

--151124-- — Tue, 15 Jan 2013 19:54:05 +0000

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

» autor: --151124--

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

alfredo_casado — Tue, 15 Jan 2013 19:48:25 +0000

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.

» autor: alfredo_casado

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

gershwin — Tue, 15 Jan 2013 19:41:01 +0000

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

» autor: gershwin

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

gershwin — Tue, 15 Jan 2013 19:36:22 +0000

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

» autor: gershwin

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

nuckle — Tue, 15 Jan 2013 19:31:01 +0000

#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

» autor: nuckle

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

--347930-- — Tue, 15 Jan 2013 19:23:22 +0000

[Usuario deshabilitado]

» autor: --347930--

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

TALIVAN_HORTOGRAFICO — Tue, 15 Jan 2013 19:15:58 +0000

#11 Gawker, en general, da la risa.

» autor: TALIVAN_HORTOGRAFICO

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

reygecko — Tue, 15 Jan 2013 18:57:09 +0000

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

» autor: reygecko

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

--151124-- — Tue, 15 Jan 2013 18:43:57 +0000

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

» autor: --151124--

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

--151124-- — Tue, 15 Jan 2013 18:38:33 +0000

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

» autor: --151124--

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

--125581-- — Tue, 15 Jan 2013 18:37:46 +0000

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

» autor: --125581--

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

--151124-- — Tue, 15 Jan 2013 18:35:48 +0000

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

» autor: --151124--

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

DaMSk — Tue, 15 Jan 2013 18:34:37 +0000

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

» autor: DaMSk

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

--125581-- — Tue, 15 Jan 2013 18:31:30 +0000

#126 Como no sea Objetive C...

» autor: --125581--

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

--151124-- — Tue, 15 Jan 2013 18:27:20 +0000

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

» autor: --151124--

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

--151124-- — Tue, 15 Jan 2013 18:26:27 +0000

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

» autor: --151124--

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

DaMSk — Tue, 15 Jan 2013 18:23:10 +0000

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.

» autor: DaMSk

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

--151124-- — Tue, 15 Jan 2013 18:16:02 +0000

#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()

» autor: --151124--

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

--347930-- — Tue, 15 Jan 2013 18:14:54 +0000

[Usuario deshabilitado]

» autor: --347930--

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

MaF — Tue, 15 Jan 2013 18:13:33 +0000

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

» autor: MaF

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

pollo — Tue, 15 Jan 2013 18:03:35 +0000

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

» autor: pollo

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

Yomisma123 — Tue, 15 Jan 2013 17:59:29 +0000

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

» autor: Yomisma123

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

jmpep — Tue, 15 Jan 2013 17:47:39 +0000

#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

» autor: jmpep

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

angelitoMagno — Tue, 15 Jan 2013 17:42:17 +0000

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

» autor: angelitoMagno

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

A145236 — Tue, 15 Jan 2013 17:39:58 +0000

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

» autor: A145236

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

--347930-- — Tue, 15 Jan 2013 17:25:12 +0000

[Usuario deshabilitado]

» autor: --347930--

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

pollo — Tue, 15 Jan 2013 17:08:22 +0000

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

» autor: pollo

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

Señor_Mandarina — Tue, 15 Jan 2013 16:52:34 +0000

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

» autor: Señor_Mandarina

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

Epaclon — Tue, 15 Jan 2013 16:51:19 +0000

Odio C++

» autor: Epaclon

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

--127171-- — Tue, 15 Jan 2013 16:47:08 +0000

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

» autor: --127171--

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

--2002-- — Tue, 15 Jan 2013 16:43:14 +0000

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

» autor: --2002--

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

DeadKenny — Tue, 15 Jan 2013 16:30:24 +0000

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

» autor: DeadKenny

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

mr_b — Tue, 15 Jan 2013 16:27:21 +0000

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

» autor: mr_b

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

--127171-- — Tue, 15 Jan 2013 16:24:33 +0000

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

» autor: --127171--

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

--347930-- — Tue, 15 Jan 2013 16:24:11 +0000

[Usuario deshabilitado]

» autor: --347930--

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

--50929-- — Tue, 15 Jan 2013 16:17:13 +0000

Es un artículo bastante ameno, e instructivo.

» autor: --50929--

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

Calomar — Tue, 15 Jan 2013 16:16:44 +0000

#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

» autor: Calomar

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

--347930-- — Tue, 15 Jan 2013 16:12:45 +0000

[Usuario deshabilitado]

» autor: --347930--

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

Luk4s — Tue, 15 Jan 2013 16:01:08 +0000

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.

» autor: Luk4s

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

zorion — Tue, 15 Jan 2013 16:00:46 +0000

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

» autor: zorion

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

fayser — Tue, 15 Jan 2013 15:58:27 +0000

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

» autor: fayser

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

mr_b — Tue, 15 Jan 2013 15:54:36 +0000

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

» autor: mr_b

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

fayser — Tue, 15 Jan 2013 15:52:54 +0000

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

» autor: fayser

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

mr_b — Tue, 15 Jan 2013 15:51:22 +0000

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

» autor: mr_b

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

mr_b — Tue, 15 Jan 2013 15:47:46 +0000

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

» autor: mr_b

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

fuynfactory — Tue, 15 Jan 2013 15:37:25 +0000

#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

» autor: fuynfactory

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

--104805-- — Tue, 15 Jan 2013 15:32:26 +0000

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.

» autor: --104805--

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

Calomar — Tue, 15 Jan 2013 15:20:23 +0000

#79 #25 Esto sólo lo entendemos los que hemos aprendido a programar en monitores de 14 pulgadas a 800x600 o 1024x768

» autor: Calomar

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

--347930-- — Tue, 15 Jan 2013 15:17:20 +0000

[Usuario deshabilitado]

» autor: --347930--

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

Luk4s — Tue, 15 Jan 2013 15:16:36 +0000

#88 mmm, pero en videojuegos no puedes usar Try and Catch, son muy lentos y algunas consolas no lo soportan...

» autor: Luk4s

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

Lamercillo — Tue, 15 Jan 2013 15:16:34 +0000

#88 No estoy hablando de una excepción, sino de un error ya tratado y encapsulado por el servicio que estoy llamando.

» autor: Lamercillo

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

MDman — Tue, 15 Jan 2013 15:13:24 +0000

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

» autor: MDman

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

angelitoMagno — Tue, 15 Jan 2013 15:05:40 +0000

Al que le interese el tema, tirando de enlaces se llega a esta web:
fabiensanglard.net/

Donde se analiza el código de los Quake I, II y III y los Doom I, II, III; así como otros juegos, como el código del Another World.

» autor: angelitoMagno

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

gershwin — Tue, 15 Jan 2013 15:04:33 +0000

#87
Para ese caso muchos lenguajes emplean try/catch

» autor: gershwin

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

Lamercillo — Tue, 15 Jan 2013 14:54:32 +0000

#27 ¿que un if-else es casi siempre un síntoma de mal diseño? Ilumíname, porque en 10 años de programación, no he dejado de verlos.

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

if (messageResponse.hasError()) {
hazLoQueSeaConElError(messageResponse.getError());
else {
sigueLaEjecucion;
}

» autor: Lamercillo

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

visualito — Tue, 15 Jan 2013 14:49:56 +0000

#51

Dios, no puedo creer que digas eso en público.

» autor: visualito

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

RojoVelasco — Tue, 15 Jan 2013 14:49:07 +0000

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

» autor: RojoVelasco

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

anxosan — Tue, 15 Jan 2013 14:46:22 +0000

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

» autor: anxosan

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

--328986-- — Tue, 15 Jan 2013 14:33:20 +0000

Que me hagáis leer los comentarios de esta noticia me preocupa, más por mí que por vosotros, panda de zumbaos.

» autor: --328986--

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

NapalMe — Tue, 15 Jan 2013 14:30:31 +0000

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

» autor: NapalMe

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

NapalMe — Tue, 15 Jan 2013 14:28:16 +0000

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.

» autor: NapalMe

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

Bedel_roolmo — Tue, 15 Jan 2013 14:25:53 +0000

#45 Parece que estás haciendo una equivalencia entre buen diseño y POO.

¿Acaso es el único paradigma que permite diseñar bien?

» autor: Bedel_roolmo

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

Enfin... — Tue, 15 Jan 2013 14:18:08 +0000

#25 Estoy completamente de acuerdo contigo, odio ver una maldita línea de código malgastada para poner un maldito "abrir llave"... Y ya si encima hay gente que trabaja con una resolución vertical de 768px es desastroso.

Yo siempre escribo:
if (condition) {
code1;
} else {
code2;
}

» autor: Enfin...

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

--315685-- — Tue, 15 Jan 2013 14:12:09 +0000

[Usuario deshabilitado]

» autor: --315685--

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

CharlieTopo — Tue, 15 Jan 2013 14:05:46 +0000

Tienes que salir mas

» autor: CharlieTopo

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

Penetrator — Tue, 15 Jan 2013 14:05:04 +0000

#26 Menos de 3 espacios no es tabulación, es error tipográfico. 2 espacios, golpe de remo. 1 espacio, pelotón de fusilamiento.

» autor: Penetrator

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

--127171-- — Tue, 15 Jan 2013 14:04:07 +0000

#73 Si pero por muy bonitos que sean, no se ponen solos. Más importante es que el resultado sea bonito, creo yo.

» autor: --127171--

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

gilipipas — Tue, 15 Jan 2013 14:02:24 +0000

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

» autor: gilipipas

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

RojoVelasco — Tue, 15 Jan 2013 14:00:08 +0000

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

» autor: RojoVelasco

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

Suikoden — Tue, 15 Jan 2013 13:59:32 +0000

Mucho código limpio y aseado y no incluyeron una linterna pegada a las armas...XD O más acción y menos sustitos.

» autor: Suikoden

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

gumerjam — Tue, 15 Jan 2013 13:58:30 +0000

#25 Yo también lo hago así. No me gusta el código de una función si hay que mover mucho el scroll.

» autor: gumerjam

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

--127171-- — Tue, 15 Jan 2013 13:57:20 +0000

Eso es como si un arquitecto dice:"Que bonitos son los ladrillos de ese edificio". Una chorrada porque que no se van a ver.

» autor: --127171--

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

scarecrow — Tue, 15 Jan 2013 13:55:32 +0000

#66 creo que no soy ninguna de las dos cosas. Me gustan las tortugas, eso sí.

» autor: scarecrow

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

Cidwel — Tue, 15 Jan 2013 13:54:31 +0000

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

» autor: Cidwel

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

--212323-- — Tue, 15 Jan 2013 13:53:45 +0000

[Usuario deshabilitado]

» autor: --212323--

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

Cidwel — Tue, 15 Jan 2013 13:52:54 +0000

#64 eres programador o eres de los que dicen "a mi no me ralles que TU haces tu trabajo y yo el mio?"

» autor: Cidwel

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

Bedel_roolmo — Tue, 15 Jan 2013 13:49:40 +0000

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

» autor: Bedel_roolmo

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

scarecrow — Tue, 15 Jan 2013 13:48:53 +0000

La peña se hace pajas con cada cosa...

» autor: scarecrow

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

--151124-- — Tue, 15 Jan 2013 13:47:47 +0000

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

» autor: --151124--

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

lesbiano — Tue, 15 Jan 2013 13:44:24 +0000

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

» autor: lesbiano

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

angelitoMagno — Tue, 15 Jan 2013 13:44:19 +0000

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

» autor: angelitoMagno

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

RojoVelasco — Tue, 15 Jan 2013 13:43:37 +0000

#57 Eso está muy bien cuando el diseño inicial es el final, pero en mi experiencia, rara vez es así.

» autor: RojoVelasco

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

CapitanObvio — Tue, 15 Jan 2013 13:43:04 +0000

#56 Vaya, ahora es una chapuza un ejemplo que se usa en el MIT, ilústranos con tus conceptos de orientación a objetos, anda.

No me lo digas.

class Préstamo {

private double cantidad;

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

public double getCantidad(return this.cantidad);

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

}

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

¿Me equivoco?

Con respecto a esto:

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

No he entendido nada.

» autor: CapitanObvio

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

YankoFarelli — Tue, 15 Jan 2013 13:41:57 +0000

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.

» autor: YankoFarelli

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

CapitanObvio — Tue, 15 Jan 2013 13:41:26 +0000

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

» autor: CapitanObvio

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

--151124-- — Tue, 15 Jan 2013 13:40:40 +0000

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

» autor: --151124--

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

CapitanObvio — Tue, 15 Jan 2013 13:39:43 +0000

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

» autor: CapitanObvio

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

Lucer — Tue, 15 Jan 2013 13:38:29 +0000

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.

» autor: Lucer

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

--151124-- — Tue, 15 Jan 2013 13:38:09 +0000

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

» autor: --151124--

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

RojoVelasco — Tue, 15 Jan 2013 13:36:52 +0000

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

» autor: RojoVelasco

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

CapitanObvio — Tue, 15 Jan 2013 13:36:31 +0000

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

» autor: CapitanObvio

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

Bedel_roolmo — Tue, 15 Jan 2013 13:34:54 +0000

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

» autor: Bedel_roolmo

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

chulonsky — Tue, 15 Jan 2013 13:28:19 +0000

El manual del buen estilo de google choca en muchos puntos con el manual de ID. google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Fight!

#8 Dependerá de la dificultad del algoritmo que estés haciendo.

» autor: chulonsky

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

--9388-- — Tue, 15 Jan 2013 13:28:03 +0000

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

» autor: --9388--

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

Cidwel — Tue, 15 Jan 2013 13:26:23 +0000

int Comida;
Espero que os duelan los ojos. Pero ESE fallo lo he visto muchas veces, y me da vomitera.

» autor: Cidwel

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

--151124-- — Tue, 15 Jan 2013 13:26:14 +0000

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

» autor: --151124--

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

CapitanObvio — Tue, 15 Jan 2013 13:25:24 +0000

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

» autor: CapitanObvio

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

elhombresinremedio — Tue, 15 Jan 2013 13:25:11 +0000

Disidentes!!

» autor: elhombresinremedio

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

elrao — Tue, 15 Jan 2013 13:25:11 +0000

#25 Pues yo siempre lo hago así, me parece más legible.

» autor: elrao

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

mefistófeles — Tue, 15 Jan 2013 13:23:42 +0000

¡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)

» autor: mefistófeles

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

--151124-- — Tue, 15 Jan 2013 13:22:40 +0000

#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

» autor: --151124--

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

Dasoman — Tue, 15 Jan 2013 13:22:04 +0000

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".

» autor: Dasoman

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

Vamvan — Tue, 15 Jan 2013 13:22:00 +0000

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

» autor: Vamvan

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

GentooXativa — Tue, 15 Jan 2013 13:20:39 +0000

#25 tu ni caso, que les den

» autor: GentooXativa

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

Cidwel — Tue, 15 Jan 2013 13:19:16 +0000

#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

» autor: Cidwel

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

CapitanObvio — Tue, 15 Jan 2013 13:19:12 +0000

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

» autor: CapitanObvio

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

--9388-- — Tue, 15 Jan 2013 13:17:40 +0000

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

» autor: --9388--

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

michaelknight — Tue, 15 Jan 2013 13:17:00 +0000

¿Hay que decir 'melofo'?

» autor: michaelknight

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

faelomx — Tue, 15 Jan 2013 13:16:49 +0000

Fuck is necessary

» autor: faelomx

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

Cidwel — Tue, 15 Jan 2013 13:16:09 +0000

#30 A las 2:00 en la puerta del colegio me lo cuentas.

» autor: Cidwel

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

--151124-- — Tue, 15 Jan 2013 13:15:21 +0000

#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

» autor: --151124--

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

uno_ke_va — Tue, 15 Jan 2013 13:15:11 +0000

#26 #28 3 espacios. Estáis matando gatitos cada vez que abrís la boca.

» autor: uno_ke_va

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

RolandDeschain — Tue, 15 Jan 2013 13:14:39 +0000

#25 yo lo hago como tu... la verdad es que nadie me ha dicho nada... la otra forma me parece de retrasados...

» autor: RolandDeschain

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

Cidwel — Tue, 15 Jan 2013 13:13:42 +0000

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

» autor: Cidwel

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

CapitanObvio — Tue, 15 Jan 2013 13:13:24 +0000

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

» autor: CapitanObvio

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

--9388-- — Tue, 15 Jan 2013 13:12:19 +0000

#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

» autor: --9388--

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

Cidwel — Tue, 15 Jan 2013 13:10:48 +0000

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

» autor: Cidwel

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

jsianes — Tue, 15 Jan 2013 13:10:14 +0000

#18 hombre 'Rage' usa un motor del que ha sido padre y como juego no esta nada mal

» autor: jsianes

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

uno_ke_va — Tue, 15 Jan 2013 13:08:41 +0000

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

» autor: uno_ke_va

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

CapitanObvio — Tue, 15 Jan 2013 13:07:13 +0000

¿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...

» autor: CapitanObvio

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

TaoTao — Tue, 15 Jan 2013 13:05:00 +0000

#20 Yo paso todo mi código por AStye antes de subirlo al repositorio.

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

astyle.sourceforge.net/

» autor: TaoTao

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

uno_ke_va — Tue, 15 Jan 2013 13:02:44 +0000

Pues hay fallos por la mezcla de diferentes estilos. Incluso dentro de un mismo fuente. Por ejemplo en ui/BindWindow.cpp:

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

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

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

En definitiva: todo es mejorable

» autor: uno_ke_va

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

--358984-- — Tue, 15 Jan 2013 13:01:54 +0000

S.O.L.I.D. (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion)

» autor: --358984--

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

--151124-- — Tue, 15 Jan 2013 13:00:47 +0000

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

» autor: --151124--

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

--15092-- — Tue, 15 Jan 2013 13:00:20 +0000

Fap Fap Fap Fap ...

» autor: --15092--

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

TaoTao — Tue, 15 Jan 2013 12:57:51 +0000

#14 Si

» autor: TaoTao

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

Vamvan — Tue, 15 Jan 2013 12:57:05 +0000

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

» autor: Vamvan

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

diskover — Tue, 15 Jan 2013 12:56:23 +0000

#11 ¿Eres indio?

» autor: diskover

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

--329430-- — Tue, 15 Jan 2013 12:55:48 +0000

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.

» autor: --329430--

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

--151124-- — Tue, 15 Jan 2013 12:53:42 +0000

#1 Justo ayer o antes de ayer Lo puso en su twitter. Lo tengo guardado para echarle un vistazo cuando tenga tiempo

» autor: --151124--

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

TaoTao — Tue, 15 Jan 2013 12:52:55 +0000

¿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.

» autor: TaoTao

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

--9388-- — Tue, 15 Jan 2013 12:51:08 +0000

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

» autor: --9388--

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

xenko — Tue, 15 Jan 2013 12:29:21 +0000

#8 Tú dale ideas a los que hacen código ofuscado, que son una gran parte de la gente que programa.

» autor: xenko

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

angelitoMagno — Tue, 15 Jan 2013 12:10:19 +0000

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.

» autor: angelitoMagno

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

--9388-- — Mon, 14 Jan 2013 22:16:25 +0000

Se lo ha currado un huevo y tiene razón, esta bonito y bien hecho.

» autor: --9388--

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

dreierfahrer — Mon, 14 Jan 2013 20:53:10 +0000

#2 Se tiene o no se tiene.

» autor: dreierfahrer

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

--130410-- — Mon, 14 Jan 2013 20:44:14 +0000

#4 Gracias majo

» autor: --130410--

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

mr_b — Mon, 14 Jan 2013 20:43:24 +0000

#3 Ya

» autor: mr_b

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

--130410-- — Mon, 14 Jan 2013 20:42:46 +0000

¿y donde pones que está en inglés?

» autor: --130410--

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

--198199-- — Mon, 14 Jan 2013 20:27:22 +0000

Joer como se flipan algunos

» autor: --198199--

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

mr_b — Mon, 14 Jan 2013 20:24:14 +0000

El propio John Carmack respondió a este artículo: kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=

» autor: mr_b