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

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.

— Эван Плейс
источник

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
источник