Puede parecer una pregunta razonable, pero hace algunas suposiciones terribles: líneas de código = esfuerzo, líneas de código = valor, todas las líneas de código son iguales. Nada de eso es cierto. ¿Por qué un arreglo que parece tan simple cuando se observan los cambios realizados tomó dos días para completarse?
|
etiquetas: programación , bugs
Apretar tornillo, un dolar, saber qué tornillo apretar, 9.999.
¿Que el primer método es técnicamente perfecto? Sí. ¿Que el segundo método es una chapuza horrible y no has resuelto nada? También, pero se tarda menos y hasta puede llegar a dar el pego.
Por desgracia, en España no hay cultura laboral. Los jefes quieren todo YA de cualquier manera, y si luego pasa algo, que lo resuelva el siguiente becario.
La solución no era especialmente voluminosa en cuanto a cantidad de código y recibí la susodicha frasecita del tiempo vs el número de líneas...
Maldito Shadow DOM
Un maldito punto y coma tras la condición en un bucle while....
Encima el código era mío
Hoy día cualquier compilador o el propio IDE me hubieran insultado con cientos de warnings avisando del error ... pero esto fue hace treinta años...
Todavía tengo pesadillas
Yo voy llenando la issue de información, sobre: dependencias, modelos, sugerencias...
No para justificar mi tiempo, sino porque sé que me va a ser útil en el futuro.
// pon lo que quieras
/* lo que
tu quieras
*/
En videojuegos, los QA, graban continuamente la partida, así por lo menos hay constancia del bug y como se produjo..
Pero es que en Java un Integer.parseInt() de un número con decimales te da una java.lang.NumberFormatException (que por otro lado, no entiendo por qué hacían un parseInt() de unos cálculos intermedios. Me suena a alguna chapuza estilo parseInt() de un BigDecimal.toString() o algo por el estilo).
Y un BigDecimal una java.lang.ArithmeticException: Division by zero si intentas dividir por 0. Sí es cierto que con Double o Float lo que obtendrías es un POSITIVE_INFINITY, pero no son simplemente números muy grandes y en cuanto intentaras usarlos como valores numéricos obtendrás una excepción igualmente: por ejemplo, un new BigDecimal(Double.POSITIVE_INFINITY) te va a dar java.lang.NumberFormatException: Infinite or NaN.
Otra cosa es que, como comentas, escriban sus propias implementaciones de división...
Pero vamos, la cosa es que difícilmente en Java vas a obtener silenciosamente un número muy grande al dividir por cero, salvo que así lo implementes expresamente capturando las excepciones. No quiero ni pensar con qué tipo de enrevesado código te encontraste y todo por lo que dices, no usar lo que el lenguaje ya te da hecho por ejemplo con Calendar.