O char de retorno de carro é considerado obsoleto

26

Eu escrevi uma biblioteca de código-fonte aberto que analisa dados estruturados, mas intencionalmente exclui a detecção de retorno de carro porque não vejo o ponto. Ele adiciona complexidade e custos adicionais para pouco ou nenhum benefício.

Para minha surpresa, um usuário enviou um bug em que o analisador não estava funcionando e eu descobri que a causa do problema era que os dados usavam finais de linha CR em oposição a LF ou CRLF.

O OSX não usa terminações de linha no estilo LF desde a mudança para uma plataforma baseada em unix?

Eu sei que existem aplicativos como o Notepad ++, onde as terminações de linha podem ser alteradas para usar o CR explicitamente, mas não vejo por que alguém iria querer.

É seguro excluir o suporte para a porcentagem estatisticamente insignificante de usuários que decidem (por qualquer motivo) os finais de linha antigos no estilo Mac OS?

Atualizar:

Para esclarecer, o suporte às terminações de linha do Windows (ou seja, CRLF) não requer reconhecimento de token CR. Para fins de eficiência, o lexer corresponde por char. Ignorando silenciosamente os caracteres CR, o token CRLF simplifica para LF. Dessa forma, o próprio token CRLF pode ser considerado um anacronismo por si só, mas não é disso que se trata esta pergunta.

O último sistema operacional que forneceu suporte em todo o sistema para terminações de linhas no estilo CR foi o Mac OS 9 . Ironicamente, o único aplicativo que ainda o usa como padrão no OSX é o Microsoft Excel.

— Evan Plaice
fonte

21

"Acrescenta complexidade e sobrecarga adicionais": acho que a complexidade e sobrecarga adicionais são realmente pequenas.

— Giorgio

11

@EvanPlaice não daria menos dores de cabeça e mais tempo para ficar com preguiça de apenas conectar o suporte de CR que você intencionalmente deixou de fora?

— Pieter B

11

"Em termos de negócios, o custo de oportunidade é muito alto. Em termos simples, prefiro encontrar razões para justificar minha preguiça do que perder tempo adicionando suporte básico a uma plataforma morta".: Em termos de negócios, levaria menos tempo para implemente o suporte ao CR do que postar uma pergunta aqui para investigar a relevância desse recurso.

— Giorgio

4

A inércia cultural do @EvanPlaice é uma boa razão.

— Pieter B

5

@EvanPlaice: Escrever esta pergunta já lhe custa mais tempo do que simplesmente colocar o suporte a CRnovas linhas em sua base de código. (... e se você acredita firmemente este não é o caso, o design do seu analisador deve ser bastante agitado)

— ZJR

37

Há uma boa prática em que você é "liberal no que aceita e conservador no que envia" .

Em outras palavras, se houver uma chance (por menor que seja) de alguém lhe dar um final de linha cr (e esperar que funcione corretamente), você precisará apoiá-lo.

TBH, não vejo como a adição de suporte a CR levaria tanto tempo.

Quando você crvir um lexer, espreitar o próximo caractere e, se for um nl, engula a nova linha e emita um token de nova linha, se o próximo caractere não for nlapenas emitir um token de nova linha e continuar.

— catraca arrepiante
fonte

23

@ZJR: a lei dos postels é perigosa: tenha muito cuidado ao empregar o princípio da robustez, porque frequentemente sai pela culatra. A bagunça de análise de html em que ainda estamos pode ser atribuída a essa mentalidade. Quando um programa aceita entrada malformada, seu comportamento logo se torna esperado e depende do comportamento, e quaisquer alterações posteriores que tratem a entrada malformada de maneira diferente, ou mesmo nenhuma, embora tecnicamente correta, são consideradas defeituosas.

— Whatsisname

4

@whatsisname: eu discordo. Eu acho que o software de qualidade da produção deve ser robusto. No entanto, as cadeias de ferramentas de desenvolvimento devem desencorajar fortemente a confiança em tal robustez e produzir apenas resultados válidos. A bagunça que o html está é causada por quase duas décadas de ferramentas ruins, não pela indulgência dos navegadores.

— back2dos

2

@ back2dos: _ _ então? as ferramentas precárias são causadas pela indulgência dos navegadores.

— Amara

4

o mau ferramental é o resultado da guerra dos navegadores

— catraca anormal

2

@Dibbeke: O manuseio de entrada malformada apenas mapeia um espaço de entrada maior para o espaço de estado existente e, portanto, não tem efeito - desde que o seu software tenha uma separação decente de preocupações.

— precisa saber é

21

Não. O CR não é obsoleto (definido como "não é mais produzido ou usado"). Você mesmo forneceu evidências disso. Talvez seja incomum , mas não obsoleto .

Quanto a "é seguro excluir suporte" para CR? Como você diz, não se trata de perder vendas, e você não pode suportar todas as combinações estranhas de caracteres e formatos de arquivo do mundo, e somente você conhece seu software e sua base de usuários. Então, eu diria que seria seguro excluí-lo se você estiver convencido de que a carga de suporte de não adicioná-la (como o mouviciel explica) não supera a carga de tempo de adicioná-lo. Mas, sem saber muito mais sobre o produto e a base de usuários, não sei como ser mais específico.

— Gato feliz
fonte

13

+1 - OMI, o OP está tentando rotular o CR como "obsoleto" para que ele tenha uma desculpa para não apoiá-lo.

— Stephen C

1

@StephenC Não estou tentando esconder esse fato. Não é que eu realmente precise de uma desculpa, sou o autor e, portanto, tenho a palavra final. O ponto é que isso levanta uma questão interessante.

— Evan Plaice

18

Sobre preguiça: você precisa equilibrar:

esforço na alteração do código para que o CR seja tratado com segurança (e depois esqueça).
esforço para explicar aos usuários por que os arquivos com os quais eles ficaram satisfeitos por décadas repentinamente travam seu aplicativo, encontrando soluções alternativas que eles podem usar sem comprometer suas vendas e solicitando argumentos e respondendo aos comentários aqui.

Cabe a você decidir qual caminho é o mais preguiçoso.

— mouviciel
fonte

Bons pontos, o suporte definitivamente vem com um custo de tempo. Nesse caso em particular, 'vendas' não é um problema (ou seja, é de código aberto), mas vale a pena considerar o quadro geral. Da mesma forma, eu também poderia lançar uma exceção no código quando um CR fosse encontrado, indicando um caractere inválido / não suportado.

— Evan Solha

7

@Evan: Claro que é de código aberto. Se não fosse, seu chefe teria dito a você "Eu não dou a mínima para que 'ninguém' use CR mais! Os clientes estão reclamando. CORRETAMENTE!" : P Essa é a grande coisa do OSS que me irrita: a falta de atenção aos casos reais dos quais os usuários se queixaram. Se você acha que é obsoleto ou não, alguém ainda o está usando.

— Chao

1

por ser de código aberto, você pode escrever uma carta aberta a todos os usuários que aceitará qualquer patch para corrigi-lo.

— rwong

1

@EvanPlaice: Essa coisa de "atenção é ... moeda" funciona nos dois sentidos. Se você deseja que as pessoas usem seu aplicativo, ele deve funcionar e resolver o problema deles. Um aplicativo quebrado não é imune a críticas apenas porque é gratuito. Não estou dizendo que você precisa fazer tudo o que os usuários pedem; você deve rejeitar pedidos ultrajantes. Mas se você não resolver os problemas dos usuários reais, você acaba perdendo os usuários.

— cHao 13/12/12

1

@EvanPlaice: E, a propósito, quando eu quero dizer "reclamar", quero dizer "arquivar um relatório de bug descrevendo o que está quebrado e como", não "reclamar aleatoriamente sobre o quão ruim é o software".

— cHao 14/12/12

8

É seguro excluir o suporte para a porcentagem estatisticamente insignificante de usuários que decidem (por qualquer motivo) os finais de linha antigos no estilo Mac OS?

Talvez não sejam detectados muitos usuários, mas há um elefante na sala: finais de linha do Windows ( CRLF). Se você os apoia (geralmente, embora apenas use o Windows para jogos), deve ser trivial apoiar a terceira parte desse histórico triângulo das Bermudas.

Se você não suporta algo como isso, pelo menos mencione-o na documentação (estilo "Isso não é um bug") e como alterar os arquivos para trabalhar com sua ferramenta da maneira mais simples possível ( dos2unixpor exemplo).

— l0b0
fonte

2

+1 por mencionar o uso do Windows CRLF- é a linha padrão que termina nesse SO. E não há como garantir a origem de um arquivo .csv, portanto ele poderia ter sido criado com facilidade em um sistema Windows.

1

Mencionar o CRLF no Windows não é relevante, porque se você estiver capturando o LF como o ponto de interrupção, receberá automaticamente o CRLF como um bônus. O OP sabe disso, como você pode ver no texto do post dele.

— davidethell

@davidethell Sim, é assim que é feito. Atualmente, os caracteres CR são ignorados silenciosamente. Não obstante os elefantes.

— Evan Solha

6

Existem muitos dispositivos seriais que dependem CRdo fluxo de dados antes do ETXenvio. É uma convenção que nunca irá embora.

— Brian
fonte

3

Eu trataria a solicitação como qualquer solicitação de recurso em que você precise pesar os custos e os benefícios.

Se exatamente uma pessoa solicitou suporte de RC, talvez não seja necessário. Veja o capítulo abaixo do livro, com 37 sinais, onde eles dizem que você deve se preocupar apenas com solicitações de recursos muito populares.

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

— Aaron Kurtzhals
fonte

1

Finalmente, um bom contraponto. Se eu pudesse selecionar duas respostas, também escolheria essa.

— Evan Solha

1

Os sistemas operacionais MS a partir de MSDOS usam a combinação CR + LF como um separador de linhas (acho que principalmente por causa das impressoras matriciais que precisam delas).

Então, sim, é uma chatice, mas você ainda precisa de apoio para a maldita coisa.

— linkerro
fonte