¿Cuál es el peor tipo de error que enfrenta un programador?

Estos son algunos de ellos:

Cuando tengas:

Error genérico (código 4)

Como el error no menciona el archivo y la línea, ¡realiza una búsqueda y encuentra cientos de ellos!

Luego le dices al tipo que esto es bastante inútil y no entiende: “¡Pero capto todos los errores y los registro!”.

Ahora, hice cumplir algunas reglas de registro para que no vuelva a suceder.

Y en el código, todas las excepciones se convierten de nuevo en una excepción genérica (la raíz), lo que hace imposible el manejo de una excepción particular.

¡Me he enfrentado a un comportamiento extraño de EGL (un lenguaje de IBM) donde la fecha nula se reemplaza por la fecha actual! Muy divertido de rastrear!

Intenté “depurarlo” y un colega literalmente me gritó: el depurador tiene errores, ¡eso no vale la pena! Y, de hecho, al depurar, el código tiene un comportamiento heredado ^^

Entonces, terminas “imprimiendo” en todas partes.

Otro error fue la infame etiqueta corta de PHP “

En una red, al imprimir desde algunas computadoras, aparecían cuadrados en espacios en blanco al azar.

Descubrimos que una versión específica del navegador + controlador de impresora + SO activó el “error”. Tuvimos que seleccionar “cargar fuentes” y luego “usar fuentes de impresora” para resolver el problema. Era aún más loco porque la opción predeterminada era “usar fuentes de impresora”.

Colgando JS punto y coma. El intérprete de JavaScript a veces extravía el punto y coma … (¡Por lo tanto, es mejor ser explícito sobre ellos!)

Un comercial que no entendía los íconos clásicos e hizo clic al azar en el ícono de “basura”, se quejó. Era una aplicación para personas capacitadas y tenía que ser rápida para tomar medidas, por lo que nunca se solicitó confirmación de cosas que se puedan corregir “fácilmente”. (¡Este tipo fue despedido porque era de mala fe!)

Para resumir :

• Mal manejo de errores
• Implementación de especificaciones incorrectas
• Características / especificaciones en conflicto
• Fragilidad
• Especificaciones perniciosas (y las permisivas son a menudo perniciosas)
• Personas de mala fe, incapaces de aprender, ineptas, …

“Un signo de interrogación griego en mi código C #”

¡El día fue muy desafortunado y malo puede ser mejor decir lo peor!

Estaba sentada junto a mi mejor amiga novata (una niña), mientras trabajaba en mi proyecto, ¡me estaba dando una compañía! ¡No sé cómo me estaba ayudando mientras cantaba algunas canciones horribles (Rabindra sangeet, que personalmente odio aún más que las canciones de Dhinchak pooja) en una voz extraña! ¡De repente, después de terminar de codificar mi programa, fui a traerme una taza de café y cuando entré me sorprendió ver un error de compilación!

Perdí más de una hora para encontrar lo que estaba mal , de repente comenzó a reír y lo reemplazó con un “;” y dijo que vio un meme en el que decían “Reemplazar”; con un signo de interrogación griego en el código C # de su amigo y veo a tu amigo volverse loco “.

No sé cómo las chicas no entienden la programación, pero entienden esa travesura.

¡Esto fue lo peor que sucedió!

¿Conoces aquellos en los que pasas de 3 a 4 horas y te das cuenta de que extrañaste o escribiste mal un solo personaje en alguna parte?

Esos hijos de puta y cualquier resultado de depuración aleatorio que saqueen son los peores.

Realmente sientes el tiempo perdido. He tenido varios de estos, y espero tener más; donde literalmente un personaje está en el lugar equivocado o ligeramente equivocado.

Los que te hacen decir “oh, mierda, no puedo creer que acabo de hacer eso …”

Yo diría que esto sucede más en compañías más pequeñas, las más grandes obviamente tienen muchas redes de seguridad. No puedo decirle cuántas veces he ejecutado una consulta DELETE FROM sin poner una cláusula WHERE al configurar una base de datos.

En realidad, sí puedo. 2 veces. La primera vez fue un problema. Accidentalmente eliminé 450,000 nombres de imágenes de las entradas de la base de datos. Todavía estaba configurando todo, así que solo hacía una copia de seguridad del servidor a la medianoche todos los días. Afortunadamente, esto me permitió pasar unas pocas horas comparando los cambios y calculando las diferencias, pero perjudicó mucho nuestro progreso.

En otra ocasión, conecté accidentalmente una línea de alimentación a un pin de entrada en una placa que estábamos creando prototipos. Incluso cuando estás registrando el trabajo, este tipo de cosas realmente puede arruinar tu progreso. Tuvimos que pedir una nueva placa y resolver una versión anterior para poder seguir probando mientras llegaban las nuevas. Pedimos más de una esta vez jajaja.

La mayoría de estos tipos de cosas realmente no lo retrasan tanto porque hay redes de seguridad, pero siempre hay una manera de evitar estas medidas de precaución en accidentes extraños. Nunca tienes TODOS tus extremos cubiertos. Y los menos esperados son los que hacen el daño, por lo que la mierda es exponencialmente mayor.

Por supuesto, sería un error en su código que no notó durante el desarrollo / prueba.

Código de muestra en C / C ++ y otros lenguajes también, que realiza la conversión automática de tipo de otro tipo de datos a booleano.

[código]

int i = 0;

nombres de cadena [];

consulta de cadena;

Mientras que (i = 5) {

if (nombres [i] == consulta) {

std :: cout << "encontrado";

descanso;

}

i ++;

}

[/código]

Se supone que este código buscará los primeros 5 elementos si se encuentran los resultados y luego se imprime.

En el primer intento, es difícil descubrir a la persona que escribió este fragmento.

Esto puede suceder en if, else if, do while, while y cualquier otra construcción que verifique el valor booleano.

Entonces, ¿cuál es la solución a este tipo de problemas,

[código]

mientras que (5 = i) {

if (consulta == nombres [i]) {

std :: cout << "encontrado";

descanso;

}

i ++;

}

[/código]

Esto es mejor, ya que generará un error en la etapa de compilación.

Un buen candidato son los errores intermitentes.

Conozco una historia de Continental, de uno de los equipos que trabajan en algún software que controla la pantalla dentro de los automóviles. Intermitentemente solo mostraban cosas en la pantalla no de acuerdo con lo que se suponía que debía hacer el software del microcontrolador.

Resultó, después de 6 semanas de investigaciones, que algunas interferencias electromagnéticas estaban cambiando algunos bits, las pruebas de EMC no deberían haber pasado, y al final los Mecánicos tuvieron que rediseñar la caja que contenía esa PCB.

• Cuando la excepción / stacktrace no es lo suficientemente detallada como para depurar.
• Depuración de nuevo. Cuando está arreglando el código de otra persona y ve las pruebas unitarias que no están escritas para cubrir la funcionalidad básica.
• Errores debidos a la dependencia de la plataforma. Por lo general, lleva tiempo encontrar alguna solución genérica para todas las plataformas

El peor tipo de error en realidad no es un error.

El peor tipo de error es en realidad la falta de un error.

Verá, si bien los errores pueden ser atemorizantes e ininteligibles para la persona promedio, para los programadores son vitales. Sin un error, puede ser un gran dolor en el culo descubrir qué salió mal o qué causó un problema porque la computadora no puede decirle lo que sabe.

He encontrado que el programador realmente odia debajo del error.

1. Cuando algún símbolo cambia con una notación similar. p. ej., punto y coma (;) pueden extraviarse fácilmente con el símbolo griego (;). Créanme o no, pero incluso un programador experimentado lucha por descubrir por qué el programa perfectamente codificado no funciona correctamente.

La corrupción de la memoria, que puede vencer a un desarrollador. Obtiene bloqueos aleatorios y no tiene idea de la causa raíz del problema. Un depurador no es de ayuda en una situación como las fallas de segmentación pueden estar en cualquier lugar. Puede ser una pesadilla.

Fallos intermitentes y fallos dependientes del entorno.

En ambos casos, simplemente no puede reproducirlos en su máquina de desarrollo, donde puede obtener un depurador en ellos.

Volver a rastrear registros e informes vagos de clientes 🙁

Del tipo que arreglas y no tienes idea de cómo lo arreglaste. Estará solucionando un error, tal vez esté cambiando demasiadas cosas a la vez, tal vez el error sea intermitente para comenzar, pero cualquiera sea la razón, de repente los problemas dejan de ocurrir. Un buen programador volverá a averiguar exactamente qué hizo para arreglarlo para referencia futura, mientras que uno malo se sentirá aliviado de que el problema ya no esté ocurriendo y juegue en Internet.