6 errores de programación favoritos

 

 

 

  • Implemente rápidamente. Implementar inteligentemente
  • Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX

  • Índice
    1. Dejar el modo de depuración activado
      1. Lecciones aprendidas
      2. Depuración cuidadosa
      3. Depuradores
    2. Desactivar el modo de depuración
      1. Lecciones aprendidas
    3. Página en blanco PHP
      1. Lecciones aprendidas
    4. Tipo de variable incorrecto
      1. Lecciones aprendidas
    5. Errores 1p
      1. Descuentos con PayPal
      2. Lecciones aprendidas
    6. Horario de verano
      1. Lecciones aprendidas
    7. Error de spam
      1. Lecciones aprendidas
    8. Conclusión
    9. Lecturas adicionales sobre SmashingMag:

    Los errores de programación se presentan en muchas formas y tamaños. En este artículo, Paul Tero comparte algunos de los errores que cometió durante su carrera de programación y las lecciones que aprendió de ellos.

     

    A lo largo de mi carrera de programación, he cometido muchos errores en varios lenguajes diferentes. De hecho, si escribo 10 o más líneas de código y funciona la primera vez, sospecharé un poco y lo probaré con más rigor de lo habitual. Esperaría encontrar un error de sintaxis o una referencia de matriz incorrecta o una variable mal escrita o algo así .

    Me gusta clasificar estos errores en tres grandes grupos: meteduras de pata (o meteduras de pata en inglés americano), errores y descuidos. Un error ocurre cuando miras fijamente la pantalla y susurras "Ups": cosas como eliminar una base de datos o un sitio web, sobrescribir tres días de trabajo o enviar correos electrónicos accidentalmente a 20.000 personas.

    Los errores cubren todo, desde simples errores de sintaxis como olvidar a }hasta errores fatales y errores computacionales. Cuando un error es tan sutil y difícil de encontrar que resulta casi hermoso, lo llamaría un descuido. Esto sucede cuando un bloque de código se ve obligado a manejar un conjunto de circunstancias completamente imprevistas y muy improbables. Te hace sentarte y pensar "Guau": como ver un arco iris brillante o una estrella fugaz, excepto que es un poco menos romántico y no tan impresionante cuando se lo describe a tu pareja durante una cena a la luz de las velas.

    Este artículo analiza algunos de los espectaculares y hermosos errores que he cometido y las lecciones que aprendí de ellos. Los tres últimos son mis favoritos.

    Dejar el modo de depuración activado

    Los dos primeros errores de este artículo fueron meteduras de pata en toda regla.

    Cuando comencé a trabajar independientemente, escribí un conjunto de bibliotecas PHP para manejar consultas de bases de datos, formularios y plantillas de páginas. Construí un modo de depuración en las bibliotecas a un nivel bastante profundo, que dependía de una variable global llamada $DEBUG.

    También guardé una copia local de todos los sitios web importantes en los que trabajé, para desarrollar, depurar y probar. Entonces, cada vez que ocurría un problema, podía configurarlo $DEBUG=1;en la parte superior de la página y me decía varias cosas, como todas las declaraciones de la base de datos que estaba ejecutando. Rara vez utilicé este método de depuración en sitios web activos; era sólo para uso local.

    Excepto un día en el que estaba trabajando hasta tarde en la noche, depurando un problema menor en un popular sitio web de comercio electrónico. Las puse $DEBUG=1;al principio de varias páginas y fui cambiando entre ellas. Todo era una borrosa y cansada medianoche, pero al final de alguna manera agregué la variable de depuración a la página más importante del sitio web, la que aparece después de que el usuario hace clic en "Pagar ahora", y la subí al sitio web en vivo.

     

    A la mañana siguiente salí temprano durante todo el día. Llegué a casa a las 9:00 pm y encontré 12 mensajes cada vez más frustrados en mi contestador automático y muchos más correos electrónicos. Durante aproximadamente 20 horas, cada vez que un cliente hacía clic en pagar, veía algo como esto:

    Lo que vieron los clientes cuando hicieron clic en "Pagar".

    Me tomó unos 10 segundos solucionarlo, pero mucho más para disculparme con mi cliente por los pedidos perdidos de un día.

    Lecciones aprendidas

    Realicé una investigación interna sobre este tema y establecí lo siguiente:

    1. Evite trabajar hasta altas horas de la noche;
    2. Realizar un pedido de prueba completo cada vez que realice un cambio en el procesamiento del pedido, por mínimo que sea;
    3. Asegúrese de que las declaraciones de depuración nunca vean la luz en un sitio web activo;
    4. Proporcione algunos datos de contacto de emergencia para mí y/o un programador de respaldo.

    Depuración cuidadosa

    Para el tercer requisito, implementé un par de funciones como esta, para asegurarme de que los mensajes de depuración se generen solo cuando estoy mirando el sitio web:

    function CanDebug() { global $DEBUG; $allowed = array ('127.0.0.1', '81.1.1.1'); if (in_array ($_SERVER['REMOTE_ADDR'], $allowed)) return $DEBUG; else return 0;}function Debug ($message) { if (!CanDebug()) return; echo 'div'; if (is_string ($message)) echo $message; else var_dump ($message); echo '/div';}

    Luego, cada vez que quiero generar algo para depurar, llamo a la Debugfunción. Esto llama CanDebuga verificar la dirección IP solicitante y la $DEBUGvariable. La $allowedmatriz contiene mi dirección IP para pruebas locales ( 127.0.0.1) y mi dirección IP de banda ancha, que puedo obtener en WhatIsMyIPAddress.com .

    Entonces puedo generar cosas como esta:

    $DEBUG = 1;Debug ("The total is now $total"); //about a debugging messageDebug ($somevariable); //output a variableDebug ("About to run: $query"); //before running any database querymysql_query ($query);

    Y puedo estar seguro de que nadie más que yo (o cualquiera que comparta mi dirección IP, como mi jefe) verá jamás ningún mensaje de depuración. Suponiendo que se configuraron las variables anteriores, el código anterior se vería así:

    Generar declaraciones de depuración.

    Para mayor seguridad, también podría haber puesto los mensajes de error dentro de los comentarios HTML, pero luego habría tenido que examinar la fuente HTML para encontrar lo que estaba buscando.

    Tengo otro código útil relacionado que puedo colocar en la parte superior de una página o archivo de configuración para garantizar que todos los avisos, advertencias y errores de PHP se me muestren a mí y solo a mí. Si la persona no soy yo, los errores y advertencias se enviarán al registro de errores pero no se mostrarán en la pantalla:

    if (CanDebug()) {ini_set ('display_errors', 1); error_reporting (E_ALL);}else {ini_set ('display_errors', 0); error_reporting (E_ALL ~E_NOTICE);}

    Depuradores

    El método anterior es útil para encontrar rápidamente errores en fragmentos de código muy específicos. También existen varias herramientas de depuración, como FirePHP y Xdebug , que pueden proporcionar una gran cantidad de información sobre un script PHP. También pueden ejecutarse de forma invisible, generando una lista de cada llamada a función en un archivo de registro sin ninguna salida para el usuario.

     

    Xdebug se puede utilizar así:

    ini_set ('xdebug.collect_params', 1);xdebug_start_trace ('/tmp/mytrace');echo substr ("This will be traced", 0, 10);xdebug_stop_trace();

    Este fragmento de código registra todas las llamadas a funciones y argumentos en el archivo /tmp/mytrace.xt , que se verá así:

    Xdebug también muestra mucha más información cada vez que hay un aviso, advertencia o error de PHP. Sin embargo, debe instalarse en el servidor, por lo que probablemente no sea posible en la mayoría de los entornos de hosting en vivo.

    FirePHP, por otro lado, funciona como una biblioteca PHP que interactúa con un complemento de Firebug, un complemento para Firefox. Puede generar seguimientos de pila e información de depuración directamente desde PHP a la consola Firebug, nuevamente, invisible para el usuario.

    Para ambos métodos, una función como CanDebugla anterior sigue siendo útil para garantizar que no todos los usuarios de Firebug puedan ver los seguimientos de la pila o generar archivos de registro grandes en el servidor.

    Desactivar el modo de depuración

    La depuración de scripts de envío de correo electrónico es más complicada. Definitivamente es difícil probar si un script envía un correo electrónico correctamente sin enviar el correo electrónico. Lo cual hice una vez por error.

    Hace unos años, me pidieron que creara un script de envío masivo de correos electrónicos para enviar correos electrónicos diarios a más de 20.000 usuarios suscritos. Durante el desarrollo, utilicé algo similar a la CanDebugfunción anterior, para poder probar el script de envío de correo electrónico sin tener que enviar un correo electrónico. La función para enviar correos electrónicos se parecía a esto:

    function SendEmail ($to, $from, $subject, $message) { if (CanDebug() = 10) Debug ("Would have emailed $to:n$message"); else { if (CanDebug()) {$subject = "Test to $to: $subject"; $to = "[email protected]";} mail ($to, $subject, $message, "From: $from"); }}

    Si lo configuro $DEBUG=1, enviaría los correos electrónicos (los 20.000) a una dirección de prueba que podría verificar. Si lo configuro $DEBUG=10, me dirá que estaba intentando enviar un correo electrónico pero en realidad no envió nada.

    Poco después del lanzamiento, surgió un problema con el script. Creo que se quedó sin memoria al realizar un procesamiento ineficiente 20.000 veces. En algún momento, fui a arreglar algo, olvidé configurar mi $DEBUGvariable (o mi dirección IP de banda ancha había cambiado de manera inconveniente) y envié un correo electrónico por error a 20.000 personas.

    Me disculpé con la agencia para la que trabajaba, pero afortunadamente no salió mucho. Supongo que los filtros de spam bloquearon muchos de los mensajes. O tal vez los destinatarios simplemente estaban contentos de que el correo electrónico no contenía nada que pudieran hacer o leer.

    Lecciones aprendidas

    Me alegré mucho de haber puesto "prueba" en el asunto y el mensaje del correo electrónico de prueba, y no una declaración que reflejara lo frustrado que me sentía por ese error en particular. Aprendí algunas lecciones:

     

    1. Tenga mucho cuidado al probar scripts de envío masivo de correos electrónicos: verifique que el modo de depuración esté funcionando.
    2. Envíe correos electrónicos de prueba a la menor cantidad de personas posible.
    3. Envíe siempre mensajes de prueba corteses, como "Por favor, ignórelo, solo prueba". No diga algo como “Mi cliente es un tonto”, en caso de que lo envíen a 20.000 inversores desprevenidos.

    Página en blanco PHP

    Ahora estamos en el reino de los errores difíciles de detectar, en lugar de en el de los errores. Si desea ver un error difícil de depurar en PHP, incluya lo siguiente en algún lugar profundo de su código:

    function TestMe() {TestMe();}TestMe();

    Dependiendo del navegador y de las versiones de Apache y PHP del servidor, es posible que obtenga una página en blanco, un mensaje de "Esta página web no está disponible", un error fatal debido a la falta de memoria o la opción de "Guardar" o "Abrir". la página, así:

    Básicamente provoca una recursividad infinita, lo que puede provocar que un subproceso del servidor web se quede sin memoria y/o falle. Si falla, es posible que quede o no un pequeño rastro en el registro de errores:

    [Mon Jun 06 18:24:10 2011] [notice] child pid 7192 exit signal Segmentation fault (11)

    Pero esto da pocos indicios de dónde o por qué ocurrió el error. Y todas las técnicas de depuración rápida de agregar líneas de salida aquí o allá pueden no ayudar mucho, porque mientras se ejecute el código infractor, la página parecerá fallar en su totalidad. Esto se debe principalmente a que PHP sólo envía periódicamente el HTML que genera al navegador. Por lo tanto, agregar muchas flush();declaraciones al menos le mostrará qué estaba haciendo su script inmediatamente antes del error recursivo.

    Por supuesto, el código que conduce a este error puede ser mucho más complicado que el anterior. Podría involucrar clases que llamen a métodos en otras clases que se refieren a las clases originales. Y puede que sólo suceda en ciertas circunstancias difíciles de duplicar y sólo porque has cambiado algo en otro lugar.

    Lecciones aprendidas

    1. Conozca las ubicaciones de los archivos de registro de errores, en caso de que se registre algo allí.
    2. Aquí es donde los depuradores de seguimiento de pila como Xdebug pueden resultar realmente útiles.
    3. De lo contrario, reserve suficiente tiempo para revisar el código línea por línea, comentando partes hasta que funcione.

    Tipo de variable incorrecto

    Este error ocurre a menudo con las bases de datos. Dadas las siguientes declaraciones SQL...

    CREATE TABLE products ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(60), category VARCHAR(10), price DECIMAL(6,2));INSERT INTO products VALUES (1, 'Great Expectations', 'book', 12.99);INSERT INTO products VALUES (2, 'Meagre Expectations', 'cd', 2.50);INSERT INTO products VALUES (3, 'Flared corduroys', 'retro clothing', 25);

    … ¿puedes adivinar qué se devuelve cuando ejecutas lo siguiente? Horoscopos y tarot de amor

     

    SELECT * FROM products WHERE category='retro clothing';

    La respuesta es nada, porque la columna de categoría tiene solo 10 caracteres, por lo que la categoría del último producto se corta en retro clot. Los productos editados recientemente o los nuevos elementos del menú que desaparecen repentinamente pueden crear mucha confusión. Pero solucionar este problema suele ser muy fácil:

    ALTER TABLE products MODIFY category VARCHAR(30);UPDATE products SET category='retro clothing' WHERE category='retro clot';

    Cometí un error más grave con el primer sitio web importante de comercio electrónico en el que trabajé. Al final del proceso de pedido, el sitio web pediría al cliente los datos de su tarjeta de crédito y luego llamaría a un programa Java, que enviaría una solicitud al sistema ePDQ de Barclays para aceptar el pago. La cantidad se envió como cantidad de peniques. Al no estar muy familiarizado con Java, basé el código en un ejemplo que encontré, que representaba el total como un número entero corto:

    short total;

    El programa Java fue llamado en la línea de comando. Si no devolvió nada, entonces la transacción se consideró exitosa, se enviaron correos electrónicos y se cumplió el pedido. Si hubo un error al procesar la tarjeta, el programa devolvió algo como "Tarjeta no autorizada" o "La tarjeta falló en las comprobaciones de fraude".

    Los enteros cortos pueden almacenar un valor entre -32768 y +32767. Esto me pareció suficiente. Pero omití que esto era en peniques, no en libras, por lo que el total más alto posible fue en realidad £327,67. Y la realmente mala noticia fue que si la cantidad era mayor que eso, entonces el programa Java simplemente fallaba y no devolvía nada, lo que parecía exactamente un pedido exitoso y se procesaba normalmente.

    Fueron necesarios algunos meses y varias transacciones importantes impagas antes de que el departamento de contabilidad o un cliente atento y honesto detectaran el error. Creo que al final recuperaron todos los pagos.

    Lecciones aprendidas

    1. Al asignar un tipo a una columna o variable de una base de datos, sea generoso y flexible, e intente planificar con antelación.
    2. Asegúrese de que un programa que tenga éxito responda de manera diferente a un programa que falle.

    Errores 1p

    Entre mis errores favoritos están aquellos que provocan una discrepancia de tan solo 1 penique (o céntimo, öre u otra denominación). Me gustan porque suelen ser muy sutiles y difíciles de rastrear y, a menudo, se reducen a un error de redondeo. Tengo que convertirme en detective matemático, un trabajo que haría fácilmente si hubiera suficiente trabajo disponible.

    Para un sitio web hace unos años, necesitaba crear una función rápida de JavaScript para generar una cantidad monetaria. Usé esto:

    script type="text/javascript"function GetMoney (amount) {return Math.round (amount * 100) / 100;}/script

    Sin embargo, rápidamente se descubrió que cantidades como 1,20 se mostraban como 1,2, lo que parece poco profesional. Entonces, lo cambié a esto:

    script type="text/javascript"function GetMoney (amount) { var pounds = Math.floor (amount); var pence = Math.round (amount * 100) % 100; return pounds + '.' + (pence 10 ? '0' : ’) + pence;}/script

    La principal diferencia es el 0 extra en la última línea. Pero ahora que los peniques se calculan por separado, %se necesita el operador de módulo para obtener el resto cuando la cantidad se divide por 100. Intente detectar las circunstancias poco probables en las que este código causaría un error.

     

    Sucedió en un sitio web que vendía cuentas. Desde entonces aprendí que las cuentas se pueden vender en una amplia gama de cantidades y configuraciones, incluidas mezclas personalizadas que contienen cantidades fraccionarias. Una vez, un cliente compró 1,01 de un artículo que costaba £4,95 y terminó pagando sólo £4,00. Esto se debe a que la cantidad se aprobó como 4,9995. Los peniques redondeados eran 100 y % 100quedaban 0 peniques, por lo que las libras se redujeron a 4.

    Esto sigue siendo sólo un error de redondeo, un superconjunto de errores 1p. Hice un cambio rápido para solucionarlo:

    script type="text/javascript"function GetMoney (amount) { var pounds = Math.floor (amount); var pence = Math.floor (amount * 100) % 100; return pounds + '.' + (pence 10 ? '0' : ’) + pence;}/script

    Sin embargo, esta no fue una gran solución, porque redondeó £4,9995 a £4,99, lo que lo desincronizó con los cálculos correspondientes del lado del servidor. Pero lo que es aún más dramático, cuando alguien pidió 0,7 de algo que costaba £1,00, ¡terminó mostrando 69 peniques en lugar de 70 peniques! Esto se debe a que los números de punto flotante como 0,7 se representan en binario como un número más parecido a 0,69999999999999999 (como se describe en un artículo reciente de Smashing Magazine ), que luego se reduciría a 69 en lugar de redondearse a 70.

    Este es un verdadero error de 1p. Para solucionar este problema, agregué otro redondeo al principio:

    script type="text/javascript"function GetMoney (amount) { var pence = Math.round (100 * amount); var pounds = Math.floor (pence / 100); pence %= 100; return pound + '.' + (pence 10 ? '0' : ’) + pence;}/script

    Ahora tenía cuatro líneas de código bastante complicadas para hacer una cosa muy simple. Hoy, mientras escribía este artículo, descubrí una función de Javascript incorporada para manejar todo esto por mí:

    script type="text/javascript"function GetMoney (amount) {return amount.toFixed (2);}alert (GetMoney (4.9995) + ' ' + GetMoney (0.1 * 0.7));/script

    Descuentos con PayPal

    PayPal es un error de 1p esperando a ocurrir. Muchos sitios web ofrecen códigos de cupón que otorgan un porcentaje de descuento en cada pedido, que se calcula al final del pedido. Si pidió dos artículos que cuestan 95 peniques, el subtotal sería de £ 1,90 y recibiría un descuento de 19 peniques, para un total de £ 1,71.

    Sin embargo, PayPal no admite este tipo de descuento. Si quieres que PayPal muestre los artículos de tu cesta de la compra, tienes que pasar cada uno por separado con precio y cantidad:

    input name="item_name_1" type="hidden" value="My Difficult Product" /input name="amount_1" type="hidden" value="0.99" /input name="quantity_1" type="hidden" value="1" /

    Por lo tanto, debes descontar cada artículo por separado. 10 % de descuento de 95 peniques deja 85,5 peniques. PayPal no acepta cantidades fraccionarias, por lo que debe redondear a 86p, para un total de £1,72 en PayPal, o redondear a la baja a 85p, para un total de £1,70.

     

    Para resolver esto, también tuve que hacer que el sitio web descontara cada artículo individualmente. En lugar de simplemente hacer el 10% × £1,90, acumula el descuento artículo por artículo, utilizando una cantidad entera de peniques cada vez. Suponiendo que $itemses una matriz PHP de objetos de elementos de pedido:

    $discount = 0; $discountpercent = 10;foreach ($items as $item) { $mydiscount = floor ($item-price * $discountpercent) / 100; $item-priceforpaypal = $item-price - $mydiscount; $discount += $mydiscount * $item-quantity;}

    Lecciones aprendidas

    1. No reinventes la rueda, ni siquiera las ruedas muy pequeñas que parecen fáciles desde fuera.
    2. Si obtiene una discrepancia de 1p, verifique dónde y cómo se redondean los números.
    3. Evite representar precios utilizando flotadores cuando sea posible. En su lugar, almacene los peniques o centavos como números enteros; y en bases de datos, utilice un tipo de punto fijo como DECIMAL.

    Horario de verano

    No llamaría “errores” a los dos últimos errores de esta lista. Requieren un conjunto muy específico de circunstancias bastante raras, por lo que son más "descuidos" por parte del programador. Los descuidos son como los actos de terrorismo que quedan excluidos de las pólizas de seguro del hogar. Van más allá de lo que un programador podría esperar razonablemente pensar de antemano.

    ¿Puedes adivinar qué hay de malo en la siguiente línea de código aparentemente inofensiva, que selecciona pedidos que se completaron hace más de una semana?

    mysql_query ("SELECT * FROM orders WHERE completeddate '" . date ('Y-m-d H:i:s', (time() - 7 * 86400 + 600)) . "'")

    Utilicé una línea similar en un sistema para un pedido repetido semanal. Buscó pedidos que se completaron la semana pasada, los duplicó y los procesó para la semana actual. 86.400 es el número de segundos que tiene un día, al igual que time() - 7 * 86400hace exactamente una semana, y +600le da un margen de maniobra de 10 minutos.

    Este era un método de bajo presupuesto para implementar pedidos repetidos. Si tuviera más tiempo, habría creado una mesa separada y/o una cesta de compras para diferenciar entre artículos repetidos y no repetidos. Dio la casualidad de que este código funcionó bien durante varios meses y luego falló misteriosamente a finales de marzo.

    Llevó años recuperarse del descuido y procesar esas órdenes manualmente. Y aún más para encontrar el motivo, sobre todo porque tuve que engañar a todo el sitio web haciéndoles creer que era una fecha diferente.

    Prácticamente he revelado el truco en el título de la sección: olvidé tener en cuenta el horario de verano, cuando una semana es menos de 7*86400 seconds.

    Compare las siguientes tres formas de obtener la fecha de hace exactamente una semana. El último es el más elegante. Lo descubrí hace poco:

    $time = strtotime ('28 March 2011 00:01');echo date ('Y-m-d H:i:s', ($time - 7 * 86400)) . 'br/';echo date ('Y-m-d H:i:s', mktime (date ('H', $time), date ('i', $time), 0, date ('n', $time), date ('j', $time) - 7, date ('Y', $time)));echo date ('Y-m-d H:i:s', (strtotime ('-1 week', $time))) . 'br/';

    Lecciones aprendidas

    Es difícil extraer lecciones generales de un error como este, pero aquí hay una lección específica:

     

    1. En sitios web que repiten cosas, recuerde tener en cuenta las zonas horarias y el horario de verano.
    2. Considere almacenar todas las horas y fechas en UTC (Tiempo Universal Coordinado).
    3. Tampoco reinventes la rueda del tiempo: strtotimees una función poderosa.

    La próxima vez que haga un sitio web para pedidos repetidos, no cometeré ese error.

    Error de spam

    Mi error favorito de todos los tiempos es un descuido aún más sutil. ¿Puedes detectar qué tienen de inusual estas direcciones de correo electrónico inventadas?

    Hace unos años, los spammers comenzaron a apuntar a formularios de contacto en sitios web, inyectando encabezados y obligando a los formularios a enviar millones de mensajes a direcciones recopiladas y luego solo al destinatario habitual del formulario.

    Esto requirió un filtrado antispam directamente en la página web que procesó el formulario. Cuando me pidieron que hiciera esto por primera vez, combiné algunos scripts antispam que encontré en Internet. Los spammers ahora suelen incluir bloques de letras aleatorias en sus mensajes para intentar engañar a los filtros de spam. Entonces, una técnica antispam es buscar estas letras aleatorias buscando ciertas consonantes en una fila.

    Leí en alguna parte que las palabras con más de seis consonantes seguidas son extremadamente raras en los idiomas con alfabeto latino. La mayor cantidad de consonantes seguidas en inglés son seis: en “latchstring”. Otros idiomas como el polaco tienen muchos más diptongos que el inglés (dz, sz, cz), así que usé siete para estar seguro. El código PHP usa una expresión regular y se parece a esto:

    foreach ($_POST as $key=$val) { if (preg_match ('/[bcdfghjklmnpqrstvwxyz]{7,}/i', $val)) die ("h1Spam Detected/h1pToo many consonants in $val/p");}

    Tuve que volver a visitar el script cuando bloqueó a alguien con una dirección de correo electrónico como las anteriores:

    Basándome en una pequeña muestra de 10.000, descubrí que aproximadamente el 0,2% de todas las direcciones de correo electrónico se filtrarían como spam, de acuerdo con la regla anterior. Una dirección de correo electrónico válida tenía nueve consonantes seguidas. Aumentar el número de consonantes permitidas de siete a diez disminuye significativamente la utilidad del guión, por lo que consideré la letra “y” como una vocal.

    Esto funcionó bien, hasta que un cliente de Cwmtwrch, cerca de Swansea, intentó realizar un pedido. Según mi muestra, sólo 1 de cada 5000 clientes tiene un nombre, correo electrónico o dirección como este. Pequeño pero importante, especialmente si eres uno de ellos. Entonces, también permití “w” como vocal. Puede verificar esto en su propia base de datos de clientes con una consulta MySQL como la siguiente:

    SELECT CONCAT_WS(' ',firstname,lastname,email,city,address1,address2) AS thefieldsFROM visitors HAVING LENGTH(thefields)20 AND thefields RLIKE '[bcdfghjklmnpqrstvwxz]{7,}'

    Lecciones aprendidas

    Me enteré de que mi script antispam bloqueaba a clientes potenciales sólo cuando mi cliente me envió sus quejas. Cuando recibí el primero (una dirección de correo electrónico que contenía un par de “y” para las vocales), me quedé asombrado. Parecía muy improbable. Un par de semanas más tarde, cuando los compradores de un pequeño pueblo galés misteriosamente todavía no podían hacer un pedido, casi no lo creí. Parece que si un fragmento de código tiene un agujero, alguien caerá en él en algún lugar. Entonces, aprendí a hacer lo siguiente:

    1. Tome en serio todos los informes de errores y quejas. Es posible que descubran algo sorprendente como esto.
    2. Anota los errores realmente improbables. Impresionarás a otros programadores… o a mí, al menos.

    Más específicamente, es útil registrar todo lo que procesa un filtro de spam, porque luego puede intentar detectar cualquier falso positivo o falso negativo y utilizarlo para mejorar el filtro.

    Conclusión

    Los errores de programación se presentan en muchas formas y tamaños. Este artículo abarca desde los errores más obvios hasta los descuidos extremadamente sutiles. Y parece que todos apoyan la Ley de Murphy : si algo puede salir mal, saldrá mal.

    Sin embargo, por cada error encontrado, reportado y solucionado, probablemente algunos más no lo sean. O no se encuentran (porque son tan increíblemente sutiles que el conjunto de circunstancias que los causarían nunca ha sucedido) o no se informan (porque la mayoría de los usuarios no se molestan en informar errores, razón por la cual cualquier error informa que entran deben tomarse en serio) o no se reparan (porque hacerlo llevaría demasiado tiempo o sería demasiado costoso).

    También es más probable que se encuentren errores en sitios web populares, principalmente porque mucha más gente está poniendo a funcionar esos sitios web, pero en parte porque corregir un error podría causar otro en otro lugar.

    Por lo tanto, las mejores lecciones son planificar con anticipación y depurar cuidadosamente.

    Lecturas adicionales sobre SmashingMag:

    • ¿Cuál es el peor error de programación que has cometido?
    • Errores que cometen los desarrolladores al aprender a diseñar
    • Pautas de administración de servidores y back-end

    (kw, señor)Explora más en

    • Codificación
    • PHP
    • javascript





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    6 errores de programación favoritos

    6 errores de programación favoritos

    Implemente rápidamente. Implementar inteligentemente Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX Índice

    programar

    es

    https://aprendeprogramando.es/static/images/programar-6-errores-de-programacion-favoritos-775-0.jpg

    2024-05-20

     

    6 errores de programación favoritos
    6 errores de programación favoritos

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20