¿Cuáles son algunos malos hábitos de codificación que obtienes de la programación competitiva?

Answer 1

¿Qué tipo de programación competitiva estamos hablando aquí? ¿Demoscene?

Con ese tipo de desarrollo, nombrar algo “aspectRatio” frente a “a” podría ser potencialmente un problema (lo más probable es que no si tienes un buen compilador, pero hay que tenerlo en cuenta).

Cada byte, cada ciclo de CPU debe entenderse completamente, tanto en su uso de memoria como en su impacto en el rendimiento.

Tienes que hacer cosas como deshacer los bucles en ciertos casos porque te ahorra 2 milisegundos.

Casi NINGUNO de esto se aplica al desarrollo de aplicaciones del mundo real.

En el mundo real, quieres que tus cosas funcionen, pero que sean completamente legibles sin necesidad de un comentario en cada línea para descubrir qué está pasando.

No refactoriza un método en algo 10 veces más complicado simplemente porque esa versión se ejecuta 1/10 de segundo más rápido y tiene un impacto cero en el rendimiento general.

En la programación de la competencia, absolutamente debería desenrollar esos bucles en algo casi completamente incomprensible, para ahorrar incluso 1 milisegundo.

Sin optimización prematura en el desarrollo del mundo real. Usted escribe, prueba, analiza el rendimiento y luego vuelve a visitar las áreas en las que es necesario mejorar. El resto lo puedes dejar solo.

Y hazlo lo más legible posible.

En algo así como una demostración 4k, vas a ver esto:

[31:29] TokenType
0x0 – NOP (requiere que todos los bits DWORD sean cero)
0x1 – selector de flujo
0x2 – definición de datos de flujo (mapa a memoria de entrada de vértice)
0x3 – memoria de entrada de vértice de tessellator
0x4 – memoria constante del shader
0x5 – extension
0x6 – reservado
0x7 – fin de la matriz (requiere que todos los bits DWORD sean 1)

En su trabajo diario habitual, es más probable que vea (solo con un ejemplo de un nivel intermedio, .NET Framework / C # LINQ):

var products = myORM.GetProducts ();
var productsOver25 = products.Where (p => p.Cost> = 25.00);

Debería quedar inmediatamente claro que obtendrá una colección de productos cuyo costo es de más de $ 25. Hay muchas cosas detrás de escena con ese código C #, pero usted mide, determina el impacto y solo lo refactoriza si tiene problemas graves de rendimiento.

En general, el código como ese no tiene un impacto significativo, por lo que en dos líneas de código tiene una buena colección enumerable de objetos de Productos fuertemente tipados, todos ellos por más de $ 25. Limpio, legible, performante, simple.

Estás lejos de preocuparte por cuánto te está haciendo daño el 0x3 del tessellator.

Mundos totalmente diferentes.

Answer 2

• Nombres de variables y funciones : variables como n, m, a, b, x, y y funciones como f, dp y resolver son normales en CP pero un gran no no en el mundo real
• Macros : muchas personas usan macros como REP (i, n) para que puedan escribir más rápido. Esto hace que el código sea difícil de leer
• Sobre acortamiento : es bueno resolver un problema en menos líneas. Pero en CP hay una tendencia a acortarlo demasiado haciendo que el código sea ilegible.
• No utilice líneas vacías : las líneas vacías harán que su código sea legible. En CP, a menudo se puede encontrar cca 100loc sin una sola línea vacía
• Código no modular : a pesar de que a muchos competidores les gustan las funciones de escritura para poder usarlas más adelante, a menudo se encuentra el núcleo de la solución en el método principal () o resolver ()
• Programación sin OOP : gran cantidad de códigos no tienen una sola clase o estructura escrita. En RL, no encontrarás variables como el nombre y la edad que están por ellos mismos.
• Variables globales : es muy común tener muchas variables globales en CP. Obviamente, en RL esto no es recomendable.