Là cỗ xe trở về được coi là lỗi thời


26

Tôi đã viết một thư viện mã nguồn mở để phân tích dữ liệu có cấu trúc nhưng cố tình bỏ qua phát hiện trả lại vận chuyển vì tôi không thấy điểm này. Nó thêm sự phức tạp và chi phí bổ sung cho ít / không có lợi ích.

Thật ngạc nhiên, một người dùng đã gửi một lỗi trong đó trình phân tích cú pháp không hoạt động và tôi đã phát hiện ra nguyên nhân của vấn đề là dữ liệu đã sử dụng các kết thúc dòng CR trái ngược với LF hoặc CRLF.

Không phải OSX đã sử dụng các kết thúc dòng kiểu LF kể từ khi chuyển sang nền tảng unix?

Tôi biết có những ứng dụng như Notepad ++ nơi kết thúc dòng có thể được thay đổi để sử dụng CR một cách rõ ràng nhưng tôi không hiểu tại sao mọi người muốn.

Có an toàn để loại trừ hỗ trợ cho tỷ lệ phần trăm không đáng kể về mặt thống kê của người dùng quyết định (vì bất kỳ lý do gì) cho các kết thúc dòng kiểu Mac OS cũ không?

Cập nhật:

Để làm rõ, việc hỗ trợ các kết thúc dòng Windows (ví dụ CRLF) không yêu cầu nhận dạng mã thông báo CR. Đối với mục đích hiệu quả, lexer phù hợp trên cơ sở mỗi char. Bằng cách âm thầm bỏ qua các ký tự CR, mã thông báo CRLF đơn giản hóa thành LF. Do đó, bản thân mã thông báo CRLF có thể được coi là lỗi thời nhưng không phải là câu hỏi này.

HĐH cuối cùng cung cấp hỗ trợ toàn hệ thống cho các kết thúc dòng kiểu CR là Mac OS 9 . Trớ trêu thay, ứng dụng duy nhất vẫn sử dụng nó làm mặc định trong OSX là Microsoft Excel.


21
"Nó bổ sung thêm độ phức tạp và chi phí chung": Tôi nghĩ rằng độ phức tạp và chi phí bổ sung thực sự rất nhỏ.
Giorgio

11
@EvanPlaice sẽ không gây đau đầu và mất nhiều thời gian hơn để lười biếng chỉ cần cắm vào hỗ trợ CR mà bạn cố tình bỏ đi?
Pieter B

11
"Về mặt kinh doanh, chi phí cơ hội quá cao. Nói một cách đơn giản, tôi thà tìm lý do để biện minh cho sự lười biếng của mình hơn là lãng phí thời gian để hỗ trợ trường hợp cạnh cho một nền tảng chết.": Về mặt kinh doanh, sẽ mất ít thời gian hơn để triển khai hỗ trợ cho CR hơn là gửi câu hỏi tại đây để điều tra mức độ liên quan của tính năng này.
Giorgio

4
Quán tính văn hóa @EvanPlaice là lý do hoàn toàn chính đáng.
Pieter B

5
@EvanPlaice: Viết câu hỏi này đã khiến bạn tốn nhiều thời gian hơn là chỉ đơn giản là hỗ trợ cho các CRdòng mới vào cơ sở mã của bạn. (... và nếu bạn tin chắc rằng đây không phải là trường hợp, thiết kế trình phân tích cú pháp của bạn phải khá sôi nổi)
ZJR

Câu trả lời:


37

Có một thực tiễn tốt khi bạn "tự do trong những gì bạn chấp nhận và bảo thủ trong những gì bạn gửi" .

Nói cách khác, nếu có cơ hội (dù nhỏ đến đâu) sẽ có người cho bạn một dòng cr kết thúc (và mong đợi nó hoạt động chính xác), bạn sẽ cần phải hỗ trợ nó.

TBH, tôi không thể thấy việc thêm hỗ trợ CR sẽ mất bao lâu.

Khi bạn thấy một người crtrong lexer nhìn trộm nhân vật tiếp theo và nếu đó là một nl, hãy nuốt dòng mới và phát ra mã thông báo dòng mới, nếu nhân vật tiếp theo không nlchỉ phát ra mã thông báo dòng mới và tiếp tục.


23
@ZJR: luật bưu chính là nguy hiểm: hãy thật cẩn thận khi sử dụng nguyên tắc mạnh mẽ, bởi vì nó thường xuyên gây tác dụng ngược. Rối loạn phân tích cú pháp html mà chúng ta vẫn đang ở có thể được quy cho suy nghĩ đó. Khi một chương trình chấp nhận đầu vào không đúng định dạng, kết quả của nó sẽ sớm được mong đợi và phụ thuộc vào hành vi, và bất kỳ thay đổi nào sau đó đối xử với đầu vào không đúng định dạng, hoặc hoàn toàn không chính xác, thường được coi là khiếm khuyết.
whatsisname

4
@whatsisname: Tôi không đồng ý. Tôi nghĩ phần mềm chất lượng sản xuất nên mạnh mẽ. Tuy nhiên, các công cụ phát triển nên không khuyến khích mạnh mẽ dựa vào độ mạnh như vậy và chỉ tạo ra đầu ra hợp lệ. Các html lộn xộn được gây ra bởi gần hai thập kỷ của công cụ kém, không phải do sự khoan dung của trình duyệt.
back2dos

2
@ back2dos: _ _ vậy? công cụ kém là do sự khoan dung của trình duyệt.
amara

4
công cụ kém là kết quả của cuộc chiến trình duyệt
ratchet freak

2
@Dibbeke: Xử lý đầu vào không đúng định dạng chỉ ánh xạ một không gian đầu vào lớn hơn vào không gian trạng thái tồn tại và do đó không có tác dụng gì với nó - miễn là phần mềm của bạn có sự phân tách đáng lo ngại.
back2dos

21

Số CR không bị lỗi thời (được định nghĩa là "không còn được sản xuất hoặc sử dụng"). Chính bạn đã cung cấp bằng chứng về điều đó. Nó có lẽ không phổ biến , nhưng không lỗi thời .

Đối với "có an toàn để loại trừ hỗ trợ" cho CR không? Như bạn nói, đó không phải là vấn đề mất doanh số và bạn không thể hỗ trợ mọi kết hợp ký tự và định dạng tệp kỳ lạ trên thế giới và chỉ bạn mới biết phần mềm và cơ sở người dùng của mình. Vì vậy, tôi sẽ nói rằng sẽ an toàn nếu loại trừ nó nếu bạn tin rằng gánh nặng hỗ trợ của việc không thêm nó (như mouviciel giải thích) không vượt quá gánh nặng thời gian của việc thêm nó. Nhưng không biết nhiều về sản phẩm và cơ sở người dùng, tôi không chắc làm thế nào để cụ thể hơn nữa.


13
+1 - IMO, OP đang cố gắn nhãn CR là "lỗi thời" để anh ta có lý do để không hỗ trợ nó.
Stephen C

1
@StephenC Tôi không cố gắng che giấu sự thật đó. Nó không giống như tôi thực sự cần một cái cớ, tôi là tác giả và do đó có tiếng nói cuối cùng. Vấn đề là, nó đặt ra một câu hỏi thú vị.
Evan Plaice

18

Về sự lười biếng: bạn phải cân bằng:

  • nỗ lực thay đổi mã để CR được xử lý một cách an toàn (và sau đó quên nó đi).

  • Nỗ lực giải thích cho người dùng lý do tại sao các tệp mà họ hài lòng trong nhiều thập kỷ đột nhiên làm hỏng ứng dụng của bạn, trong việc tìm ra cách giải quyết mà họ có thể sử dụng mà không ảnh hưởng đến doanh số của bạn và yêu cầu tranh luận và trả lời các bình luận ngay tại đây.

Tùy thuộc vào bạn để quyết định con đường nào là lười nhất.


Điểm tốt, hỗ trợ chắc chắn đi kèm với một chi phí thời gian. Trong trường hợp cụ thể này, 'doanh số' không phải là một vấn đề (tức là nó là nguồn mở) nhưng đáng để xem xét bức tranh lớn hơn. Tương tự, tôi cũng có thể đưa ra một ngoại lệ trong mã khi gặp CR chỉ ra một ký tự không hợp lệ / không được hỗ trợ.
Evan Plaice

7
@Evan: Tất nhiên đó là nguồn mở. Nếu không, ông chủ của bạn sẽ nói với bạn "Tôi không nói xấu rằng 'không ai' sử dụng CR nữa! Khách hàng đang phàn nàn. CỐ ĐỊNH!" : P Đây là điều quan trọng về OSS khiến tôi bực mình: sự thiếu quan tâm đến các trường hợp thực tế mà người dùng đã phàn nàn. Cho dù bạn nghĩ rằng nó đã lỗi thời hay không, ai đó vẫn đang sử dụng nó.
cHao

1
bởi vì đó là nguồn mở, bạn có thể viết thư ngỏ cho tất cả người dùng rằng bạn sẽ chấp nhận bất kỳ bản vá nào để sửa nó.
rwong

1
@EvanPlaice: Rằng "sự chú ý là ... tiền tệ" hoạt động theo cả hai cách. Nếu bạn muốn mọi người sử dụng ứng dụng của bạn, nó phải hoạt động và nó phải giải quyết vấn đề của họ. Một ứng dụng bị hỏng không tránh khỏi những lời chỉ trích chỉ vì nó miễn phí. Tôi không nói rằng bạn cần phải làm mọi thứ mà người dùng yêu cầu; bạn nên loại bỏ các yêu cầu thái quá. Nhưng nếu bạn không giải quyết được vấn đề của người dùng thực, cuối cùng bạn sẽ mất người dùng.
cHao

1
@EvanPlaice: Và nhân tiện, khi tôi có nghĩa là "phàn nàn", tôi có nghĩa là "nộp báo cáo lỗi nêu rõ những gì bị hỏng và làm thế nào", chứ không phải "rên rỉ ngẫu nhiên về mức độ xấu của phần mềm".
cHao

8

Có an toàn để loại trừ hỗ trợ cho tỷ lệ phần trăm không đáng kể về mặt thống kê của người dùng quyết định (vì bất kỳ lý do gì) cho các kết thúc dòng kiểu Mac OS cũ không?

Có thể không có quá nhiều người dùng sẽ phát hiện ra nó, nhưng có một con voi trong phòng: kết thúc dòng Windows ( CRLF). Nếu bạn ủng hộ những điều đó (tôi thường làm, mặc dù tôi chỉ sử dụng Windows cho các trò chơi), việc hỗ trợ phần thứ ba của tam giác Bermuda lịch sử này là chuyện nhỏ.

Nếu bạn không hỗ trợ một cái gì đó như thế này, ít nhất bạn nên đề cập đến nó trong tài liệu (kiểu "Đây không phải là lỗi") cách thay đổi tệp để làm việc với công cụ của bạn theo cách đơn giản nhất có thể ( dos2unixví dụ).


2
+1 để đề cập đến Windows bằng cách sử dụng CRLF- đó là dòng mặc định kết thúc trên HĐH đó. Và không có cách nào để đảm bảo nguồn của tệp .csv, vì vậy nó có thể dễ dàng được tạo trên hệ thống Windows.

1
Đề cập đến CRLF trong Windows là không phù hợp bởi vì nếu bạn đang xem LF là điểm dừng thì bạn sẽ tự động nhận CRLF làm phần thưởng. OP biết điều này như bạn có thể thấy trong văn bản bài đăng của mình.
davidethell

@davidethell Yep, đó là cách nó được thực hiện. Hiện tại, CR chars đang âm thầm bỏ qua. Voi bất chấp.
Evan Plaice

6

Có nhiều thiết bị nối tiếp dựa vào CRkết thúc luồng dữ liệu trước khi ETXđược gửi. Đó là một quy ước sẽ không bao giờ biến mất.


3

Tôi sẽ coi yêu cầu là bất kỳ yêu cầu tính năng nào mà bạn cần cân nhắc chi phí với lợi ích.

Nếu chính xác một người đã yêu cầu hỗ trợ CR, có thể điều đó là không cần thiết. Xem chương sách dưới đây từ 37 tín hiệu nơi họ nói rằng bạn chỉ nên lo lắng về các yêu cầu tính năng rất phổ biến.

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


1
Cuối cùng, một điểm phản biện tốt. Nếu tôi có thể chọn hai câu trả lời tôi cũng sẽ chọn câu trả lời này.
Evan Plaice

1

Các MS OS từ MSDOS trở đi sử dụng kết hợp CR + LF làm dấu tách dòng (tôi nghĩ phần lớn là do máy in ma trận cần chúng).

Vì vậy, yeah, đó là một người ồn ào, nhưng bạn vẫn cần hỗ trợ cho những thứ chết tiệt.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.