Il carattere di ritorno a capo è considerato obsoleto

26

Ho scritto una libreria open source che analizza i dati strutturati ma intenzionalmente ha escluso il rilevamento del ritorno a capo perché non vedo il punto. Aggiunge ulteriore complessità e costi generali per un beneficio scarso / nullo.

Con mia sorpresa, un utente ha inviato un bug in cui il parser non funzionava e ho scoperto che la causa del problema era che i dati utilizzavano terminazioni di riga CR anziché LF o CRLF.

OSX non utilizza i terminali di linea in stile LF da quando è passato a una piattaforma basata su unix?

So che ci sono applicazioni come Notepad ++ in cui i finali di linea possono essere modificati per usare esplicitamente CR ma non vedo perché qualcuno vorrebbe.

È sicuro escludere il supporto per la percentuale statisticamente insignificante di utenti che decidono (per qualsiasi motivo) i vecchi terminali di linea in stile Mac OS?

Aggiornare:

Per chiarire, il supporto dei finali di linea di Windows (ad es. CRLF) non richiede il riconoscimento di token CR. Ai fini dell'efficienza, il lexer corrisponde in base al carattere. Ignorando silenziosamente i caratteri CR, il token CRLF si semplifica in LF. Come tale, il token CRLF stesso potrebbe essere considerato un anacronismo tutto suo, ma non è questo il problema.

L'ultimo sistema operativo che ha fornito supporto a livello di sistema per i finali di linea in stile CR è stato Mac OS 9 . Ironia della sorte, l'unica applicazione che la utilizza ancora come predefinita in OSX è Microsoft Excel.

— Evan Plaice
fonte

21

"Aggiunge ulteriore complessità e spese generali": penso che la complessità aggiuntiva e le spese generali siano davvero ridotte.

— Giorgio,

11

@EvanPlaice non darebbe meno mal di testa e più tempo per essere pigro semplicemente collegando il supporto CR che hai intenzionalmente lasciato fuori?

— Pieter B,

11

"In termini commerciali, il costo opportunità è troppo elevato. In termini semplici, preferirei trovare motivi per giustificare la mia pigrizia piuttosto che perdere tempo aggiungendo il supporto di caso per una piattaforma morta.": In termini commerciali ci sarebbe voluto meno tempo per implementare il supporto per CR piuttosto che pubblicare una domanda qui per indagare la pertinenza di questa funzionalità.

— Giorgio,

4

L'inerzia culturale di @EvanPlaice è una ragione perfettamente valida.

— Pieter B,

5

@EvanPlaice: scrivere questa domanda ti costa già più tempo che spalare il supporto per le CRnuove righe nella tua base di codice. (... e se credi fermamente che non sia così, il design del tuo parser deve essere piuttosto frenetico)

— ZJR

37

Esiste una buona pratica in cui sei "liberale in ciò che accetti e conservatore in ciò che invii" .

In altre parole, se c'è una possibilità (per quanto piccola sia) che qualcuno ti dia un finale cr line (e si aspetti che funzioni correttamente), dovrai supportarlo.

TBH, non vedo come l'aggiunta del supporto CR richiederebbe così tanto tempo.

Quando vedi a crnel lexer sbirciare il personaggio successivo e se è a nl, ingoia la nuova riga ed emette un token newline, se il personaggio successivo non è nlsemplicemente emette un token newline e continua.

— maniaco del cricchetto
fonte

23

@ZJR: la legge sui postelli è pericolosa: fai molta attenzione quando usi il principio di robustezza, perché spesso fallisce. Il pasticcio di analisi html in cui ci troviamo ancora può essere attribuito a quella mentalità. Quando un programma accetta input non validi, il suo comportamento di conseguenza diventa presto previsto e dipende dal comportamento e eventuali modifiche successive che trattano l'input non valido in modo diverso, o per nulla, pur essendo tecnicamente corrette, sono spesso considerate difettose.

— whatsisname

4

@whatsisname: non sono d'accordo. Penso che il software di qualità della produzione dovrebbe essere robusto. Le toolchain di sviluppo dovrebbero tuttavia scoraggiare fortemente basandosi su tale solidità e produrre solo risultati validi. Il disordine html è causato da quasi due decenni di strumenti scadenti, non dalla clemenza dei browser.

— back2dos,

2

@ back2dos: _ _ così? il cattivo equipaggiamento è causato dalla clemenza dei browser.

— Amara,

4

il cattivo equipaggiamento è il risultato della guerra dei browser

— maniaco del cricchetto,

2

@Dibbeke: la gestione di input non validi si limita a mappare uno spazio di input più grande allo spazio di stato esistente e quindi non ha alcun effetto su di esso, a condizione che il software abbia una discreta separazione delle preoccupazioni.

— back2dos

21

No. CR non è obsoleto (definito come "non più prodotto o utilizzato"). Tu stesso ne hai fornito la prova. È forse raro , ma non obsoleto .

Per quanto riguarda "è sicuro escludere il supporto" per CR? Come dici tu, non si tratta di perdere vendite e non puoi supportare tutte le strane combinazioni di caratteri e formati di file nel mondo e solo tu conosci il tuo software e la tua base di utenti. Quindi direi che sarebbe sicuro escluderlo se sei convinto che l'onere del supporto di non aggiungerlo (come spiega mouviciel) non supera il peso del tempo di aggiungerlo. Ma senza sapere molto di più sul prodotto e sulla base di utenti non sono sicuro di come essere più specifico.

— HappyCat
fonte

13

+1 - IMO, l'OP sta cercando di etichettare CR come "obsoleto" in modo che abbia una scusa per non supportarlo.

— Stephen C,

1

@StephenC Non sto cercando di nascondere questo fatto. Non è che ho davvero bisogno di una scusa, sono l'autore e quindi ho l'ultima parola. Il punto è che solleva una domanda interessante.

— Evan Plaice,

18

A proposito di pigrizia: devi bilanciare:

sforzo nel modificare il codice in modo che CR sia gestito in modo sicuro (e poi dimenticatene).
lo sforzo di spiegare agli utenti perché i file di cui erano felici da decenni bloccano improvvisamente la tua app, nel trovare soluzioni alternative che possono usare senza compromettere le tue vendite e nel chiedere argomenti e rispondere ai commenti proprio qui.

Sta a te decidere quale sia il percorso più pigro.

— mouviciel
fonte

Aspetti positivi, il supporto ha sicuramente un costo in termini di tempo. In questo caso particolare, le "vendite" non sono un problema (ovvero sono open source), ma vale la pena considerare il quadro generale. Allo stesso modo, potrei anche lanciare un'eccezione nel codice quando viene rilevato un CR che indica un carattere non valido / non supportato.

— Evan Plaice,

7

@Evan: ovviamente è open source. Se non lo fosse, il tuo capo ti avrebbe detto "Non me ne frega niente che 'nessuno' usi più CR! I clienti si lamentano. FIX IT!" : P Questa è la cosa grandiosa di OSS che mi fa incazzare: la mancanza di attenzione ai casi reali di cui gli utenti si sono lamentati. Che tu pensi che sia obsoleto o meno, qualcuno lo sta ancora usando.

— cHao,

1

poiché è open source, puoi scrivere una lettera aperta a tutti gli utenti che accetterai qualsiasi patch per risolverlo.

— rwong

1

@EvanPlaice: Quella cosa "attenzione è ... valuta" funziona in entrambi i modi. Se vuoi che le persone utilizzino la tua app, deve funzionare e deve risolvere il loro problema. Un'app rotta non è immune alle critiche solo perché è gratuita. Non sto dicendo che devi fare tutto ciò che gli utenti chiedono; si dovrebbe respingere le richieste oltraggiose. Ma se non risolvi i problemi degli utenti reali, finisci per perdere utenti.

— cHao,

1

@EvanPlaice: E a proposito, quando intendo "lamentarsi", intendo "presentare una segnalazione di bug che delinea ciò che è rotto e come", non "piagnucolare casualmente su quanto è cattivo il software".

— cHao,

8

È sicuro escludere il supporto per la percentuale statisticamente insignificante di utenti che decidono (per qualsiasi motivo) i vecchi terminali di linea in stile Mac OS?

Forse non troppi utenti lo rileveranno, ma c'è un elefante nella stanza: terminazioni di linea di Windows ( CRLF). Se supporti quelli (generalmente lo faccio, anche se uso solo Windows per i giochi), dovrebbe essere banale supportare la terza parte di questo storico triangolo delle Bermuda.

Se non supporti qualcosa del genere, dovresti almeno menzionarlo nella documentazione (stile "Questo non è un bug") e come modificare i file per lavorare con il tuo strumento nel modo più semplice possibile ( dos2unixad esempio).

— l0b0
fonte

2

+1 per menzionare l'utilizzo di Windows CRLF: è la riga predefinita che termina su quel sistema operativo. E non c'è modo di garantire l'origine di un file .csv, quindi avrebbe potuto facilmente essere creato su un sistema Windows.

1

Menzionare CRLF in Windows non è rilevante perché se stai prendendo LF come punto di interruzione, otterrai automaticamente CRLF come bonus. L'OP lo sa come puoi vedere nel testo del suo post.

— davidethell,

@davidethell Sì, è così. Attualmente, i caratteri CR vengono ignorati silenziosamente. Nonostante gli elefanti.

— Evan Plaice,

6

Esistono molti dispositivi seriali che si basano sul CRfine del flusso di dati prima che ETXvenga inviato. È una convenzione che non andrà mai via.

— Brian
fonte

3

Tratterò la richiesta come qualsiasi richiesta di funzionalità in cui è necessario valutare i costi rispetto ai vantaggi.

Se esattamente una persona ha richiesto il supporto CR, forse non è necessario. Vedi il capitolo seguente del libro da 37 segnali in cui si dice che dovresti preoccuparti solo di richieste di funzionalità molto popolari.

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

— Aaron Kurtzhals
fonte

1

Finalmente un buon contrappunto. Se potessi selezionare due risposte, sceglierei anche questa.

— Evan Plaice,

1

I sistemi operativi MS da MSDOS in poi usano la combinazione CR + LF come separatore di linea (penso principalmente a causa delle stampanti a matrice che ne hanno bisogno).

Quindi sì, è un peccato, ma hai ancora bisogno di supporto per la dannata cosa.

— linkerro
fonte