¿Cuál es el consejo que le daría a un principiante cuyo código pasa todos los casos de prueba públicos pero falla alrededor del 40-50% de los casos de prueba?

Tienes que aprender a usar dos sombreros:
En el caso de la programación competitiva y las katas de código, puede darse el lujo de que alguien con experiencia use el sombrero idiota para usted. Para comenzar a obtener más de sus exámenes y para aprender a escribir códigos del mundo real, debes aprender a usar el sombrero de idiota.

La idea general es iteraciones rápidas entre la creación y la ruptura: algunas personas comienzan con la construcción primero, otras prefieren comenzar directamente con la ruptura: esto se denomina Test Driven Development y sus variantes, donde la idea es escribir código que intente usar su nueva función Primero, y establece todas las suposiciones acerca de la salida que debería obtener, y solo entonces comienza a escribir el código para hacer que las pruebas pasen. La otra opción es escribir una función que casi funciona primero, y escribir las pruebas más tarde, o incluso no escribirlas y simplemente hacerlo como un ejercicio mental (una mala idea: debes escribir lo que estás pensando, porque de esta manera no olvidará; simplemente ejecute “probar todo” cuando haga cambios).

Por ejemplo, digamos que necesita escribir una función que ordene las manzanas por color, donde el color se representa como una cadena.

Usando el sombrero del constructor, intenta imaginar el problema de la manera más simple posible y resolverlo de alguna manera. Parece que ya estás cómodo con ese sombrero.

Usando el sombrero de idiota, intentas ordenar:

  • -1, 0, 1 y 2 manzanas; si es relevante, INT_MAX e INT_MIN.
  • Colores como el valor NULO, una cadena vacía y el nombre del color EN TODAS LAS TAPAS, así como los valores que no son realmente colores.

Entonces se pone más difícil. Debe tratar de usar ambos sombreros al mismo tiempo y verificar combinaciones idiotas de entradas, según la estructura de su código.

  • Se le pide que ordene 10 manzanas, pero solo le dan 5 (o ninguna).
  • Todas las manzanas son del mismo color o todas son diferentes.
  • Las manzanas que te dan ya están ordenadas.
  • Combinaciones de número y color de manzanas que salen mal.

La idea es pasar por esto lo antes posible después de cada cambio “atómico” (es decir, la parte más pequeña e indivisible del código, tal vez solo una línea, quizás un par de expresiones, tal vez una clase simple completa), y ejercer tantas combinaciones como sea posible. posible. Si el código tiene muchas interdependencias, los pequeños cambios causarán explosiones combinatorias de las cosas que necesita verificar. Por eso es importante escribir su código en capas de abstracciones, porque las interfaces en las capas limitan el número total de conexiones entre los nodos. En la gráfica de tu programa. Si sus abstracciones son buenas, se sentirá seguro de hacer cambios en su código mientras resuelve el problema.

Existen marcos de prueba que automatizan gran parte de lo anterior en cierta medida: por ejemplo, dado que ha codificado una descripción clara de los supuestos y los “grados de libertad” de su código, QuickCheck intentará combinaciones de entradas que desconcertarán incluso a los mejores idiotas Se origina en Haskell, donde el estilo del código es tal que es casi plug-and-play (si está usando el sistema de tipos correctamente), pero está disponible para muchos idiomas. También hay cientos de opciones más convencionales: simplemente busque “pruebas de unidad de ” y verá lo que quiero decir.

para asegurarse de que su programa tenga muchos errores lógicos o que se esté arrastrando algo de basura en su programa mientras ejecuta, simplemente intente depurar su programa

Por cierto, estoy enfrentando un problema diferente. Otro problema en el que estoy resolviendo todos los casos de prueba, pero aún así, codechef me dice que mi código es incorrecto cuando lo presento.