Чи вважається картка повернення каретки застарілою

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: _ _ так? поганий інструментарій спричинений поблажливістю браузерів.

— amara

4

поганий інструментарій є результатом війни в браузері

— храповик, який вирізав

2

@Dibbeke: Обробка неправильно введеного вводу просто відображає більший простір вводу у існуючий простір станів і, таким чином, не впливає на нього - за умови, що у вашому програмному забезпеченні є пристойне розділення проблем.

— back2dos

21

Ні. CR не є застарілим (визначається як "більше не виробляється та не використовується"). Ви самі представили докази цього. Це, мабуть, нечасто , але не застаріло .

Що стосується "чи безпечно виключити підтримку" для CR? Як ви кажете, справа не в втраті продажів, і ви не можете підтримувати кожну дивну комбінацію символів та формат файлів у світі, і ви знаєте лише своє програмне забезпечення та базу користувачів. Тому я б сказав, що це було б безпечно виключити, якщо ви переконаєтесь, що тягар підтримки не додавати його (як пояснює mouviciel) не перевищує часовий тягар його додавання. Але не знаючи більше про продукт та базу користувачів, я не знаю, як бути більш конкретним.

— HappyCat
джерело

13

+1 - ІМО, ОП намагається позначити CR як "застарілий", щоб він мав привід не підтримувати його.

— Стівен С

1

@StephenC Я не намагаюся приховати цей факт. Це не так, як мені справді потрібна виправдання, я автор, і, таким чином, я маю остаточне слово. Справа в тому, що це викликає цікаве питання.

— Еван Плейс

18

Про лінь: ви повинні збалансувати:

зусилля по зміні коду, щоб CR безпечно оброблявся (а потім забував про нього).
намагання пояснити користувачам, чому ті файли, якими вони були задоволені десятиліттями, раптово ставлять збій у вашій програмі, знаходячи обхідні шляхи, якими вони можуть користуватися, не ставлячи до уваги ваші продажі, а також просити аргументи та бажаючи коментарів тут.

Ви самі вирішите, який шлях найлініший.

— мувівієль
джерело

Хороші моменти, підтримка, безумовно, йде з витратами часу. У цьому конкретному випадку "продажі" не є проблемою (тобто це відкритий код), але варто розглянути більш широку картину. Так само я можу також викинути виняток у код, коли виникає CR, що вказує на недійсний / непідтримуваний символ.

— Еван Плейс

7

@Evan: Звичайно, це відкритий код. Якби не, ваш начальник сказав би вам: "Я не лаю, що" ніхто "більше не використовує CR! : P Це велика річ, що стосується OSS, яка мене здивує: відсутність уваги до реальних справ , на які скаржаться користувачі. Незалежно від того, чи вважаєте ви це застарілим чи ні, хтось все ще його використовує.

— cHao

1

оскільки це відкритий код, ви можете написати відкритий лист усім користувачам, що ви приймете будь-який патч для його виправлення.

— rwong

1

@EvanPlaice: Ця річ "увага - це валюта" працює обома способами. Якщо ви хочете, щоб люди користувалися вашим додатком, він повинен працювати, і він повинен вирішити їх проблему. Зламана програма не застрахована від критики лише тому, що вона безкоштовна. Я не кажу, що вам потрібно робити все, що вимагають користувачі; ви повинні відхилити шалені запити. Але якщо ви не вирішите справжніх проблем користувачів, ви втратите користувачів.

— cHao

1

@EvanPlaice: І до речі, коли я маю на увазі "скаржитися", я маю на увазі "подати звіт про помилку, в якому описується, що зламано і як", а не "скупотіти випадковим чином про те, наскільки шкідливе програмне забезпечення".

— cHao

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 OS від MSDOS далі використовують комбінацію CR + LF як роздільник ліній (я думаю, в основному через матричні принтери, які їм потрібні).

Так, так, це облом, але вам все одно потрібна підтримка проклятої речі.

— linkerro
джерело