¿Se considera obsoleto el carácter de retorno de carro?

26

Escribí una biblioteca de código abierto que analiza datos estructurados pero intencionalmente omitió la detección de retorno de carro porque no veo el punto. Agrega complejidad adicional y gastos generales para poco o ningún beneficio.

Para mi sorpresa, un usuario envió un error donde el analizador no funcionaba y descubrí que la causa del problema era que los datos usaban terminaciones de línea CR en lugar de LF o CRLF.

¿No ha estado OSX usando terminaciones de línea de estilo LF desde que se cambió a una plataforma basada en Unix?

Sé que hay aplicaciones como Notepad ++ donde las terminaciones de línea se pueden cambiar para usar CR explícitamente, pero no veo por qué alguien querría hacerlo.

¿Es seguro excluir el soporte para el porcentaje estadísticamente insignificante de usuarios que deciden (por cualquier razón) las antiguas terminaciones de estilo de Mac OS?

Actualizar:

Para aclarar, admitir los finales de línea de Windows (es decir, CRLF) no requiere el reconocimiento de token CR. Para fines de eficiencia, el lexer coincide por cada carácter. Al ignorar silenciosamente los caracteres CR, el token CRLF se simplifica a LF. Como tal, el token CRLF en sí mismo podría considerarse un anacronismo en sí mismo, pero de eso no se trata esta pregunta.

El último sistema operativo que proporcionó soporte en todo el sistema para las terminaciones de línea de estilo CR fue Mac OS 9 . Irónicamente, la única aplicación que todavía lo usa como predeterminada en OSX es Microsoft Excel.

— Evan Plaice
fuente

21

"Agrega complejidad y sobrecarga adicionales": creo que la complejidad y sobrecarga adicionales son realmente pequeñas.

— Giorgio

11

@EvanPlaice, ¿no le daría menos dolores de cabeza y más tiempo para ser perezoso solo para conectar el soporte de CR que intencionalmente dejó de lado?

— Pieter B

11

"En términos comerciales, el costo de oportunidad es demasiado alto. En términos simples, prefiero encontrar razones para justificar mi pereza que perder el tiempo agregando soporte de casos extremos para una plataforma muerta". implementar el soporte para CR que publicar una pregunta aquí para investigar la relevancia de esta función.

— Giorgio

44

La inercia cultural de @EvanPlaice es una buena razón.

— Pieter B

55

@EvanPlaice: Escribir esta pregunta ya le cuesta más tiempo que simplemente palear en apoyo de CRnuevas líneas en su base de código. (... y si cree firmemente que este no es el caso, el diseño de su analizador debe ser bastante agitado)

— ZJR

37

Hay una buena práctica en la que eres "liberal en lo que aceptas y conservador en lo que envías" .

En otras palabras, si existe la posibilidad (por pequeña que sea) de que alguien le dé un final de línea cruzada (y espere que funcione correctamente), deberá apoyarlo.

TBH, no puedo ver cómo agregar el soporte CR tomaría tanto tiempo.

Cuando vea a cren el lexer, eche un vistazo al siguiente personaje y, si es un nl, trague la nueva línea y emita un token de nueva línea, si el siguiente personaje no es nlsimplemente emita un token de nueva línea y continúe.

— monstruo de trinquete
fuente

23

@ZJR: la ley de postels es peligrosa: tenga mucho cuidado al emplear el principio de robustez, porque con frecuencia fracasa. El desorden de análisis html en el que todavía estamos puede atribuirse a esa mentalidad. Cuando un programa acepta una entrada con formato incorrecto, su comportamiento como resultado pronto se espera y depende del comportamiento, y cualquier cambio posterior que trate la entrada con formato incorrecto de manera diferente, o no lo haga , mientras sea técnicamente correcto, a menudo se considera defectuoso.

— whatsisname

44

@whatsisname: no estoy de acuerdo. Creo que el software de calidad de producción debería ser robusto. Sin embargo, las cadenas de herramientas de desarrollo deberían desalentar fuertemente confiar en tal robustez y solo producir resultados válidos. El desastre en el que se encuentra el html es causado por casi dos décadas de herramientas deficientes, no por la indulgencia de los navegadores.

— back2dos

2

@ back2dos: _ _ ¿y? Las herramientas pobres son causadas por la indulgencia de los navegadores.

— amara

44

las herramientas pobres son el resultado de la guerra del navegador

— freak de trinquete

2

@Dibbeke: el manejo de entradas con formato incorrecto simplemente asigna un espacio de entrada más grande al espacio de estado existente y, por lo tanto, no tiene ningún efecto sobre él, siempre que su software tenga una separación decente de preocupaciones.

— back2dos

21

No. CR no está obsoleto (definido como "ya no se produce ni se usa"). Usted mismo ha proporcionado evidencia de eso. Quizás sea poco común , pero no obsoleto .

En cuanto a "¿es seguro excluir el soporte" para CR? Como usted dice, no se trata de perder ventas, y no puede soportar todas las combinaciones de caracteres extraños y formatos de archivo en el mundo, y solo usted conoce su software y base de usuarios. Entonces diría que sería seguro excluirlo si está convencido de que la carga de soporte de no agregarlo (como explica Mouviciel) no supera la carga de tiempo de agregarlo. Pero sin saber mucho más sobre el producto y la base de usuarios, no estoy seguro de cómo ser más específico.

— Gato feliz
fuente

13

+1 - OMI, el OP está tratando de etiquetar a CR como "obsoleto" para que tenga una excusa para no apoyarlo.

— Stephen C

1

@StephenC No estoy tratando de ocultar ese hecho. No es que realmente necesite una excusa, soy el autor y, por lo tanto, tengo la última palabra. El punto es que plantea una pregunta interesante.

— Evan Plaice

18

Sobre la pereza: tienes que equilibrar:

esfuerzo en cambiar el código para que CR se maneje de forma segura (y luego olvidarse de él).
esfuerzo para explicar a los usuarios por qué los archivos con los que estuvieron contentos durante décadas de repente bloquean su aplicación, encontrar soluciones que puedan usar sin comprometer sus ventas y pedir argumentos y responder comentarios aquí.

Depende de usted decidir qué camino es el más flojo.

— Mouviciel
fuente

Buenos puntos, el soporte definitivamente viene con un costo de tiempo. Para este caso particular, 'ventas' no es un problema (es decir, es de código abierto), pero vale la pena considerar el panorama general. Del mismo modo, también podría lanzar una excepción en el código cuando se encuentra un CR que indica un carácter no válido / no compatible.

— Evan Plaice

77

@Evan: Por supuesto que es de código abierto. Si no fuera así, su jefe le habría dicho "¡Me importa una mierda que 'nadie' use CR nunca más! Los clientes se están quejando. ¡ARREGLELO!" : P Esto es lo importante de OSS que me molesta: la falta de atención a los casos reales de los que los usuarios se han quejado. Ya sea que piense que es obsoleto o no, alguien todavía lo está usando.

— cHao

1

Debido a que es de código abierto, puede escribir una carta abierta a todos los usuarios para aceptar cualquier parche para solucionarlo.

— rwong

1

@EvanPlaice: Esa cosa de "atención es ... moneda" funciona en ambos sentidos. Si quieres que la gente use tu aplicación, tiene que funcionar y tiene que resolver su problema. Una aplicación rota no es inmune a las críticas solo porque es gratis. No digo que debas hacer todo lo que los usuarios piden; se debe desestimar las peticiones extravagantes. Pero si no resuelve los problemas de los usuarios reales, terminará perdiendo usuarios.

— cHao

1

@EvanPlaice: Y por cierto, cuando me refiero a "quejarse", me refiero a "presentar un informe de error que describa lo que está roto y cómo", no "quejarse al azar sobre lo malo que es el software".

— cHao

8

¿Es seguro excluir el soporte para el porcentaje estadísticamente insignificante de usuarios que deciden (por cualquier razón) las antiguas terminaciones de estilo de Mac OS?

Tal vez no muchos usuarios lo detecten, pero hay un elefante en la sala: finales de línea de Windows ( CRLF). Si los admite (generalmente lo hago, aunque solo uso Windows para juegos), debería ser trivial admitir la tercera parte de este histórico triángulo de las Bermudas.

Si no admite algo como esto, al menos debería mencionarlo en la documentación (estilo "Esto no es un error") y cómo cambiar los archivos para que funcionen con su herramienta de la manera más simple posible ( dos2unixpor ejemplo).

— l0b0
fuente

2

+1 por mencionar el uso de Windows CRLF: es la línea predeterminada que termina en ese sistema operativo. Y no hay forma de garantizar el origen de un archivo .csv, por lo que fácilmente podría haberse creado en un sistema Windows.

1

Mencionar CRLF en Windows no es relevante porque si está tomando LF como punto de quiebre, automáticamente obtendrá CRLF como un bono. El OP sabe esto como puedes ver en el texto de su publicación.

— davidethell

@davidethell Sí, así es como se hace. Actualmente, los caracteres CR se ignoran silenciosamente. A pesar de los elefantes.

— Evan Plaice

6

Hay muchos dispositivos en serie que se basan en el CRfinal del flujo de datos antes de que ETXse envíe. Es una convención que nunca desaparecerá.

— Brian
fuente

3

Consideraría la solicitud como una solicitud de función en la que necesita comparar los costos con los beneficios.

Si exactamente una persona ha solicitado soporte CR, tal vez no sea necesario. Vea el capítulo del libro a continuación de 37 señales donde dicen que solo debe preocuparse por solicitudes de funciones muy populares.

http://gettingreal.37signals.com/ch05_Forget_Feature_Requests.php

— Aaron Kurtzhals
fuente

1

Finalmente, un buen contrapunto. Si pudiera seleccionar dos respuestas, también elegiría esta.

— Evan Plaice

1

Los MS OS de MSDOS en adelante usan la combinación CR + LF como un separador de línea (creo que principalmente debido a las impresoras matriciales que los necesitan).

Así que sí, es un fastidio, pero aún necesitas apoyo para la maldita cosa.

— linkerro
fuente