Является ли символ возврата каретки устаревшим

26

Я написал библиотеку с открытым исходным кодом, которая анализирует структурированные данные, но намеренно исключил обнаружение возврата каретки, потому что не вижу смысла. Это добавляет дополнительную сложность и накладные расходы для небольшой выгоды.

К моему удивлению, пользователь представил ошибку, из-за которой анализатор не работал, и я обнаружил, что причиной проблемы было то, что данные использовали окончания строки CR, а не LF или CRLF.

Разве OSX не использовала окончания LF в стиле после перехода на Unix-платформу?

Я знаю, что есть приложения, такие как Notepad ++, в которых окончания строк могут быть изменены для явного использования CR, но я не понимаю, почему кто-то захочет.

Безопасно ли исключать поддержку статистически незначительного процента пользователей, которые решают (по какой-либо причине) использовать линейные окончания старого стиля Mac OS?

Обновить:

Для пояснения, поддержка окончания строки Windows (например, CRLF) не требует распознавания маркера CR. В целях эффективности лексер сопоставляется отдельно для каждого символа. Незаметно игнорируя символы CR, токен CRLF упрощается до LF. Таким образом, сам по себе токен CRLF можно считать анахронизмом, но вопрос не в этом.

Последней ОС, которая обеспечивала общесистемную поддержку концов строк в стиле CR, была Mac OS 9 . По иронии судьбы, единственное приложение, которое по-прежнему использует его по умолчанию в OSX, - это Microsoft Excel.

mac osx character-encoding software-obsolescence Эван Плейс
источник
21
«Это добавляет дополнительную сложность и накладные расходы»: я думаю, что дополнительная сложность и накладные расходы действительно малы.
Джорджио
11
@EvanPlaice разве это не даст меньше головной боли и больше времени, чтобы быть ленивым, чтобы просто включить поддержку CR, которую вы намеренно упустили?
Питер Б
11
«С точки зрения бизнеса альтернативные издержки слишком высоки. Проще говоря, я бы скорее нашел причины, чтобы оправдать свою лень, чем тратить время на добавление поддержки« мертвых платформ »в крайнем случае». С точки зрения бизнеса это заняло бы меньше времени реализовать поддержку CR, чем разместить здесь вопрос, чтобы исследовать актуальность этой функции.
Джорджио
4
@EvanPlaice культурная инерция - совершенно веская причина.
Питер Б
5
@EvanPlaice: написание этого вопроса уже стоило вам больше времени, чем просто добавление поддержки CRновых строк в вашу кодовую базу. (... и если вы твердо уверены, что это не так, дизайн вашего парсера должен быть довольно беспокойным)
ZJR

Ответы:

37

Существует хорошая практика, когда вы «либеральны в том, что вы принимаете, и консервативны в том, что вы посылаете» .

Другими словами, если есть вероятность (какой бы маленькой она ни была), что кто-то даст вам окончание строки cr (и ожидает, что она будет работать правильно), вам нужно будет ее поддержать.

TBH, я не вижу, как добавление поддержки CR займет столько времени.

Когда вы видите crв лексере заглядывание следующего символа и, если это так nl, проглотите символ новой строки и испустите токен новой строки, если следующий символ не nlпросто испускает токен новой строки и продолжайте.

чокнутый урод
источник
23
@ZJR: закон посылок опасен: будьте очень осторожны при использовании принципа надежности, потому что он часто имеет неприятные последствия. Беспорядок в разборе html, в котором мы все еще находимся, можно отнести к этому мышлению. Когда программа принимает некорректный ввод, ее поведение в результате вскоре становится ожидаемым и зависит от поведения, и любые последующие изменения, которые по-разному относятся к искаженному вводу или вообще не учитываются, хотя и являются технически правильными, часто считаются дефектными.
whatsisname
4
@whatsisname: я не согласен. Я считаю, что качественное программное обеспечение должно быть надежным. Тем не менее, инструментальные средства разработки не должны полагаться на такую ​​надежность и давать только достоверные результаты. Беспорядок в html вызван почти двумя десятилетиями плохого инструментария, а не снисходительностью браузеров.
back2dos
2
@ back2dos: _ _ так? плохое оснащение вызвано снисходительностью браузеров.
Амара
4
плохой инструментарий является результатом войны браузеров
трещотка урод
2
@Dibbeke: Обработка искаженного ввода просто отображает большее пространство ввода в существующее пространство состояний и, следовательно, не влияет на него - при условии, что ваше программное обеспечение имеет приличное разделение проблем.
back2dos
21

Нет. CR не устарел (определяется как «больше не производится или не используется»). Вы сами предоставили доказательства этого. Это, возможно, необычно , но не устарело .

Что касается " безопасно ли исключать поддержку" для ЧР? Как вы говорите, это не означает потери продаж, и вы не можете поддерживать каждую странную комбинацию символов и формат файла в мире, и только вы знаете свое программное обеспечение и базу пользователей. Поэтому я бы сказал, что было бы безопасно исключить его, если вы уверены, что бремя поддержки его не добавления (как объясняет mouviciel) не перевешивает временное бремя его добавления. Но, не зная намного больше о продукте и пользовательской базе, я не уверен, как быть более конкретным.

HappyCat
источник
13
+1 - IMO, ОП пытается пометить CR как «устаревший», чтобы у него был повод не поддерживать его.
Стивен С
1
@StephenC Я не пытаюсь скрыть этот факт. Не то чтобы я действительно нуждался в оправдании, я - автор и, таким образом, имею последнее слово. Дело в том, что возникает интересный вопрос.
Эван Плейс
18

Про лень: надо балансировать

  • усилия по изменению кода так, чтобы CR был безопасно обработан (а затем забудьте об этом).

  • попытка объяснить пользователям, почему файлы, которыми они были довольны в течение десятилетий, внезапно приводит к сбою в вашем приложении, найти обходные пути, которые они могут использовать, не ставя под угрозу ваши продажи, и попросить аргументы и дать комментарии прямо здесь.

Вам решать, какой путь самый ленивый.

mouviciel
источник
Хорошие моменты, поддержка определенно идет со временем. В данном конкретном случае «продажи» не являются проблемой (то есть с открытым исходным кодом), но стоит рассмотреть более широкую картину. Кроме того, я мог бы также выдать исключение в коде, когда встречается CR, указывающий на недопустимый / неподдерживаемый символ.
Эван Плейс
7
@Evan: Конечно, это с открытым исходным кодом. Если бы это было не так, ваш начальник сказал бы вам: «Мне все равно, что« никто »больше не использует CR! Клиенты жалуются. ИСПРАВИТЬ ЭТО!» : P Это большая вещь в OSS, которая меня бесит: отсутствие внимания к реальным случаям, на которые пользователи жаловались. Считаете ли вы это устаревшим или нет, кто-то все еще использует его.
cHao
1
Поскольку это открытый исходный код, вы можете написать открытое письмо всем пользователям, что вы примете любой патч, чтобы исправить это.
rwong
1
@EvanPlaice: эта вещь «внимание - валюта» работает в обоих направлениях. Если вы хотите, чтобы люди использовали ваше приложение, оно должно работать, и оно должно решить их проблему. Разбитое приложение не защищено от критики только потому, что оно бесплатное. Я не говорю, что вам нужно делать все, о чем просят пользователи; Вы должны отклонить возмутительные запросы. Но если вы не решите проблемы реальных пользователей, вы в конечном итоге теряете пользователей.
cHao
1
@EvanPlaice: И, кстати, когда я имею в виду «жаловаться», я имею в виду «подать отчет об ошибке, описывающий, что сломано и как», а не «жаловаться случайным образом о том, насколько плохое программное обеспечение».
Чао
8

Безопасно ли исключать поддержку статистически незначительного процента пользователей, которые решают (по какой-либо причине) использовать линейные окончания старого стиля Mac OS?

Возможно, не слишком много пользователей обнаружат это, но в комнате есть слон: окончания строки Windows ( CRLF). Если вы поддерживаете их (как правило, да, хотя я использую только Windows для игр), поддержка третьей части этого исторического Бермудского треугольника должна быть тривиальной.

Если вы не поддерживаете что-то подобное, вы должны хотя бы упомянуть об этом в документации (стиль «Это не ошибка») и о том, как изменить файлы для работы с вашим инструментом самым простым способом ( dos2unixнапример).

l0b0
источник
2
+1 за упоминание использования Windows CRLF- это строка по умолчанию, заканчивающаяся в этой ОС. И нет никакого способа гарантировать источник файла .csv, поэтому его легко можно было бы создать в системе Windows.
1
Упоминание CRLF в Windows не имеет значения, потому что если вы ловите LF в качестве точки останова, вы автоматически получаете CRLF в качестве бонуса. ОП знает об этом, как вы можете видеть в тексте его поста.
davidethell
@ davidethell Да, вот как это делается. В настоящее время символы CR молча игнорируются. Слоны, несмотря на.
Эван Плейс
6

Есть много последовательных устройств, которые полагаются CRкак конец потока данных перед ETXотправкой. Это соглашение, которое никогда не исчезнет.

Брайан
источник
3

Я бы обработал запрос как любой запрос на добавление функциональных возможностей, если вам необходимо сопоставить затраты с выгодами.

Если ровно один человек обратился за поддержкой CR, возможно, в этом нет необходимости. См. Главу из 37 сигналов ниже, где говорится, что вам следует беспокоиться только об очень популярных запросах функций.

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

Аарон Куртжалс
источник
1
Наконец, хороший контрапункт. Если бы я мог выбрать два ответа, я бы тоже выбрал этот.
Эван Плейс
1

ОС MS от MSDOS и далее используют комбинацию CR + LF в качестве разделителя строк (я думаю, в основном из-за матричных принтеров, которые в них нуждаются).

Так что да, это облом, но вам все еще нужна поддержка для проклятого.

linkerro
источник