Trường hợp từ khóa không nhạy cảm trong một ngôn ngữ [đóng]

Chúng tôi đang cố gắng viết một ngôn ngữ kịch bản tùy chỉnh. Đã có một gợi ý để làm cho ngôn ngữ tha thứ bằng cách cung cấp các từ khóa không phân biệt chữ hoa chữ thường .

Cá nhân tôi không thích ý tưởng này, nhưng có rất ít người trong nhóm của tôi nghiêng về phía nó, nói rằng nó sẽ làm cho người dùng cuối hài lòng! Ví dụ về các ngôn ngữ như FORTRAN, BASIC, SQL được đưa ra nói rằng đây là những trường hợp không nhạy cảm.

Đây có phải là một ý tưởng tốt?

Hãy tự hỏi ai là người dùng cuối. Nếu nó được viết bởi một người có kinh nghiệm lập trình bằng C hoặc Javscript hoặc kinh nghiệm CNTT trong Unix, thì độ nhạy trường hợp có lẽ là điều nên làm, bởi vì đó là điều người dùng mong đợi. Nhưng đối với hầu hết người dùng cuối, ngay cả người dùng có quyền lực, điều này sẽ gây nhầm lẫn.

VB / VBA / VBScript không phân biệt chữ hoa chữ thường và đây là một quyết định được đưa ra để cho phép những người không lập trình dễ dàng hiểu được ngôn ngữ. Các công thức Excel, không chính xác là các tập lệnh nhưng gần như nhiều người dùng nhận được, không phân biệt chữ hoa chữ thường. Trong hầu hết các văn bản, việc lựa chọn trường hợp có thể làm cho văn bản trông ít nhiều chuyên nghiệp và bóng bẩy hơn, nhưng trường hợp nó tự thay đổi ý nghĩa ngữ nghĩa của các từ. Đó là lý do tại sao tôi tin rằng những người không phải là nhà phát triển sẽ bị nhầm lẫn bởi một ngôn ngữ kịch bản phân biệt chữ hoa chữ thường.

Một lần nữa, đây không phải là một lựa chọn kỹ thuật. Đó là một lựa chọn quản lý sản phẩm phải được thực hiện bởi những người hiểu rõ đối tượng mục tiêu.

Bạn nên quyết định dựa trên trải nghiệm người dùng mà bạn muốn trình bày, chứ không phải việc thực hiện dễ hay khó.

Nếu nó sẽ giúp người dùng của bạn dễ dàng phân biệt chữ hoa chữ thường thì đó là điều bạn nên thực hiện.

Như một trường hợp trong điểm SQL là trường hợp không nhạy cảm. Điều này làm cho nó rất dễ sử dụng trong một thiết lập tương tác.

Một cách khác để xem xét điều này là sẽ có sự khác biệt giữa keywordvà Keywordtrong ngôn ngữ của bạn, và sự khác biệt này sẽ có ý nghĩa với người dùng? Đối với một ngôn ngữ kịch bản, tôi muốn nói câu trả lời là "không".

Ngôn ngữ lập trình nên phân biệt chữ hoa chữ thường, chữ hoa. Mọi người có thể điều chỉnh vấn đề này rất dễ dàng: họ chỉ cần nhớ làm việc chủ yếu ở dạng chữ thường và để ý các mã định danh hỗn hợp hoặc mũ toàn phần trong các API hiện có.

Nó từng có vẻ rõ ràng để làm cho ngôn ngữ không phân biệt chữ hoa chữ thường. Điều này là do chữ thường không có sẵn trên tất cả các hệ thống máy tính và các thiết bị I / O của chúng (bàn phím, máy in và thiết bị hiển thị). Việc triển khai ngôn ngữ lập trình phải chấp nhận các chương trình được viết bằng chữ in hoa, vì chỉ có thể hiển thị hoặc in. Và cho rằng họ phải là trường hợp nhạy cảm, bởi vì chấp nhận chữ hoa và là trường hợp nhạy cảm tại các phương tiện cùng một lúc để từ chối chữ thường. Chữ thường là thứ mà các lập trình viên muốn, nhưng không phải lúc nào cũng có. Không ai thực sự muốn làm việc với các chương trình hét trong trường hợp cao; nó chỉ là một giới hạn phần cứng.

Trong một thời gian, nó thậm chí còn phổ biến trong trường hợp gấp trong các thiết bị đầu cuối. Nếu một thiết bị đầu cuối chỉ có thể hiển thị chữ hoa, nhưng bạn phải đăng nhập vào hệ thống máy tính hỗ trợ chữ hoa và chữ thường, thì thiết bị đầu cuối sẽ gấp chữ thường thành chữ hoa. Nghĩ rằng điều này đã rất lâu rồi? "Giống như Apple II, Apple II Plus không có chức năng viết thường." (http: // en Tin nhắn được viết trong tất cả các mũ là phổ biến trên bảng tin trong những ngày đó. Chức năng này vẫn được tìm thấy trong các hệ điều hành giống Unix, như nhân Linux. Ví dụ, nhập stty olcucdấu nhắc shell của bạn.Kỷ luật dòng tty Unix có thể ánh xạ chữ thường thành chữ hoa trên đầu ra và nó có thể ánh xạ chữ hoa thành chữ thường ở đầu vào. Điều này cho phép bạn làm việc trong ngôn ngữ lập trình chữ thường, trên một thiết bị đầu cuối không có chữ thường.

Không phân biệt chữ hoa chữ thường là một khái niệm lỗi thời từ thời đại máy tính đã qua, không hoạt động tốt trong thế giới hiện đại của điện toán quốc tế. Bạn có mở rộng nó sang các ngôn ngữ khác không? Thế còn tiếng Pháp: bạn có coi và è là tương đương không? Hay tiếng Nhật? Bạn có coi hiragana và katakana chỉ là trường hợp, vì vậy ァ và ふ ぁ là cùng một định danh? Hỗ trợ cho sự điên rồ như vậy sẽ làm phức tạp đáng kể máy phân tích từ vựng của bạn, sẽ phải có các bản đồ tương đương trường hợp cho toàn bộ không gian Unicode.

Lưu ý rằng toán học là trường hợp nhạy cảm. Ví dụ, sigma chữ hoa có thể biểu thị tổng, trong khi sigma chữ thường biểu thị một cái gì đó khác, như độ lệch chuẩn. Điều này có thể xảy ra trong cùng một công thức mà không tạo ra bất kỳ khó khăn. (Ngôn ngữ lập trình có làm cho và σ tương đương không?)

Chính tả tiếng Anh là nhạy cảm. Ví dụ, nhiều danh từ thích hợp tương ứng với danh từ thông thường hoặc thậm chí các phần khác của lời nói. "May" là một động từ, nhưng "May" là một tháng, hoặc tên của một người phụ nữ. Hơn nữa, nếu một từ viết tắt hoặc viết tắt được viết bằng chữ thường, nó có thể gây nhầm lẫn. SAT là viết tắt của bài kiểm tra năng khiếu kinh viện, trong khi "sat" là phân từ quá khứ của "ngồi". Người thông minh chú ý đến chi tiết và viết hoa đúng cách.

Về cơ bản, bất kỳ ngôn ngữ lập trình mới nào được tạo ra từ năm 1985 không phân biệt chữ hoa chữ thường là CHO NHỮNG AI VẪN KHÔNG NÊN TRONG E-MAILS VÀ BÀI VIẾT KHÔNG CÓ MỘT THỨ HAI.

Điều gì xảy ra nếu ngôn ngữ của bạn từng được sử dụng làm mục tiêu tạo mã để dịch mã sang ngôn ngữ khác và ngôn ngữ khác có phân biệt chữ hoa chữ thường không? Bạn sẽ phải bằng cách nào đó biến đổi tất cả các tên để nắm bắt sự khác biệt. (Vì vậy, để khẳng định rằng đây không phải là một quyết định kỹ thuật và chỉ có vấn đề về sở thích cảm xúc của đối tượng mục tiêu, là vô lý.)

Xem xét các vấn đề gây phiền nhiễu do xử lý tình huống trong Windows, khi các tệp được nhập từ hệ điều hành khác. Đó là một vấn đề kỹ thuật. Các hệ thống tệp phân biệt chữ hoa chữ thường có vấn đề với dữ liệu nước ngoài mà các tệp không phân biệt chữ hoa chữ thường không có.

Lisp thông thường đã đạt được cách tiếp cận lý tưởng: tên biểu tượng là trường hợp nhạy cảm, nhưng khi đọc mã thông báo, chúng được gấp lại thành chữ hoa. Điều này có nghĩa rằng các thẻ foo, fOO, FOOvà Footất cả biểu thị cùng một biểu tượng: các biểu tượng có tên được lưu giữ như những chuỗi ký tự "FOO". Hơn nữa, hành vi này chỉ là cấu hình bảng đọc mặc định. Người đọc có thể gấp chữ cái viết hoa, viết thường, đảo ngược trường hợp hoặc bảo quản nó. Hai lựa chọn cuối cùng làm phát sinh một phương ngữ phân biệt chữ hoa chữ thường. Bằng cách này, người dùng có sự linh hoạt tối đa.

Yếu tố quyết định thực sự là tần suất bạn muốn có nhiều thứ có cùng tên. Tính không nhạy cảm của trường hợp hoạt động trong SQL vì không thường xuyên bạn muốn một cột có tên SELECT. Nó sẽ gây khó chịu trong Java bởi vì mọi dòng khác trông giống như Object object = new Object(), nơi bạn muốn cùng tên để tham chiếu đến một lớp, một cá thể và một hàm tạo.

Nói cách khác, phân biệt chữ hoa chữ thường chủ yếu hữu ích cho quá tải tên và quá tải chủ yếu hữu ích trong các dự án lớn, phức tạp. Để sử dụng không thường xuyên hơn, chẳng hạn như ngôn ngữ kịch bản, trường hợp không nhạy cảm có thể làm cho việc lập trình đơn giản hơn nhiều.

Tôi đã tạo một ngôn ngữ quy tắc một lần khi các định danh không chỉ không phân biệt chữ hoa chữ thường, chúng còn không phân biệt khoảng trắng. Tôi cũng cho phép tạo các bí danh đề cập đến cùng một định danh. Ví dụ: Lập trình viênStackExchange, trao đổi ngăn xếp lập trình viên và PSE đều được giải quyết theo cùng một biểu tượng chính xác và có thể được sử dụng thay thế cho nhau.

Đối với tên miền của tôi hoạt động rất tốt, bởi vì tên miền có rất nhiều cách cực kỳ nổi tiếng để đề cập đến điều tương tự, và việc đặt tên xung đột là rất hiếm. Không ai sẽ ngạc nhiên bằng cách gõ một truy vấn bằng một tên và có kết quả sử dụng tên khác. Có hỗ trợ ngôn ngữ làm cho việc dịch giữa tên miền và ngôn ngữ lập trình trở nên rất dễ dàng. Tuy nhiên, nó cũng làm cho một số nhiệm vụ khó khăn hơn, như tìm tất cả các tham chiếu đến một biến. Rất may, trong trường hợp của tôi, những tình huống đó hiếm khi xảy ra, hoặc khá dễ dàng để xây dựng công cụ hỗ trợ để giúp đỡ, nhưng bạn phải tính đến tình huống của riêng mình.

Giả sử ngôn ngữ tập lệnh của bạn sẽ phân biệt chữ hoa chữ thường - bạn sẽ tạo trình biên dịch hoặc trình kiểm tra cú pháp sẽ cho người dùng biết nếu anh ta mắc lỗi đánh máy bằng cách sử dụng sai trường hợp trong tên biến hoặc từ khóa? Nếu không, đó sẽ là một lập luận rất mạnh mẽ để làm cho trường hợp ngôn ngữ không nhạy cảm.

Bạn có thể khai báo các biến khi đang bay không? Nếu vậy tôi sẽ tranh luận chống lại trường hợp nhạy cảm, vì theo dõi một lỗi gây ra bởi

ATypo = 42; 

như trái ngược với

Atypo = 42; 

không cần thiết phải yêu cầu thời gian gỡ lỗi, khi có hai câu lệnh tương đương chỉ làm cho cuộc sống dễ dàng hơn.

Ví dụ về các ngôn ngữ như FORTRAN, BASIC, SQL được đưa ra nói rằng đây là những trường hợp không nhạy cảm.

Lý do tại sao FORTRAN và SQL (và COBOL) không phân biệt chữ hoa chữ thường là vì chúng ban đầu được thiết kế để sử dụng trên các máy mà bộ ký tự bình thường chỉ có chữ in hoa. Sự không nhạy cảm trong các ngôn ngữ đó (ít nhất) là một vật phẩm lịch sử hơn là một lựa chọn thiết kế ngôn ngữ.

Bây giờ bạn có thể lập luận rằng sự vô cảm của trường hợp dễ tha thứ hơn, nhưng mặt trái là độ nhạy của trường hợp đó dẫn đến mã dễ đọc hơn bởi vì nó không phải là tOe cOdEr tO uSe cOnSiStEnT cApItAlIzAtIoN.

Trường hợp nhạy cảm được coi là có hại.

Cuộc sống không phân biệt chữ hoa chữ thường và cả người dùng hay lập trình viên.

Ngôn ngữ phân biệt chữ hoa chữ thường là một tai nạn lịch sử, của các hệ thống bị hạn chế khiến việc so sánh không phân biệt chữ hoa chữ thường trở nên khó khăn. Điểm chấp này không còn tồn tại, vì vậy không có lý do gì để tạo ra một hệ thống máy tính phân biệt chữ hoa chữ thường nữa.

Tôi sẽ đi xa hơn để nói rằng trường hợp nhạy cảm là xấu , vì nó đặt sự tiện lợi của máy tính trước người dùng.

(Liên quan, tôi nhớ lại vài năm trước, một số thiên tài đã từ chối thanh toán hóa đơn thẻ tín dụng của anh ta vì tên của anh ta có trong tất cả các chữ hoa một yêu cầu thanh toán hợp lệ. Thẩm phán đối xử với lý lẽ như nó xứng đáng).

Từ kinh nghiệm cá nhân của tôi, tôi không thấy sự khác biệt lớn giữa các ngôn ngữ nhạy cảm và không nhạy cảm.

Điều quan trọng hơn là đặt tên và các quy ước cấu trúc mà một lập trình viên nên giữ trong mã của mình và không có trình biên dịch hoặc trình phân tích cú pháp nào kiểm tra nó cho anh ta. Nếu bạn tuân theo một số quy tắc, bạn sẽ dễ dàng biết được một tên thích hợp (bạn sẽ không nghĩ nếu bạn đặt tên một biến checkOut hoặc CheckOut) và mã của bạn có thể sẽ phân biệt chữ hoa chữ thường và dễ đọc hơn.

Không nên sử dụng CheckOut và checkOut và thanh toán và cHeCkOuT và KIỂM TRA theo cùng một nghĩa. Nó sẽ làm tổn thương tính dễ đọc và làm cho việc hiểu loại mã đó trở nên đau đớn hơn (nhưng có những điều tồi tệ hơn mà người ta có thể làm để phá hủy tính dễ đọc của mã).

Nếu bạn sử dụng một số loại quy tắc bạn sẽ thấy trong nháy mắt chẳng hạn:

CheckOut.getInstance () - đó là phương thức tĩnh của một lớp có tên là checkOut.calculate () - đó là phương thức của một đối tượng được giữ trong biến hoặc trường công khai gọi là _checkOut.calculate () - đó là phương thức của một đối tượng được giữ trong trường riêng - đó là trường / biến tĩnh hoặc hằng số cuối cùng

mà không kiểm tra một số tệp khác hoặc các phần của tệp. Nó làm cho việc đọc mã nhanh hơn.

Tôi thấy khá nhiều nhà phát triển sử dụng các quy tắc tương tự - trong các ngôn ngữ mà tôi thường sử dụng: Java, PHP, Action Script, JavaScript, C ++.

Trong một trường hợp hiếm hoi, người ta có thể tức giận vì sự vô cảm của trường hợp - ví dụ như khi muốn sử dụng CheckOut cho một tên lớp và checkOut cho một biến và không thể vì nó va chạm với nhau. Nhưng đó là vấn đề của một lập trình viên được sử dụng để phân biệt chữ hoa chữ thường và sử dụng nó trong các quy ước đặt tên của anh ta. Người ta có thể có các quy tắc với tiền tố tiêu chuẩn hoặc tiền tố trong một ngôn ngữ không phân biệt chữ hoa chữ thường (Tôi không lập trình trong VB nhưng tôi biết rằng nhiều lập trình viên VB có loại quy ước đặt tên này).

Nói một cách ngắn gọn: Tôi thấy tính nhạy cảm của trường hợp tốt hơn (chỉ dành cho các ngôn ngữ hướng đối tượng) bởi vì hầu hết các nhà phát triển sử dụng ngôn ngữ phân biệt chữ hoa chữ thường và hầu hết họ sử dụng các quy ước đặt tên dựa trên độ nhạy của trường hợp nên họ muốn ngôn ngữ nhạy cảm với trường hợp hơn có thể tuân theo các quy tắc của họ mà không cần một số sửa đổi. Nhưng đó là tranh luận tôn giáo - không phải là một mục tiêu (không dựa trên những nhược điểm thực sự hoặc mặt tốt của tính nhạy cảm trường hợp - bởi vì tôi không thấy bất kỳ điều gì khi nói đến một nhà phát triển giỏi, khi nói đến bAd DeVeLoPeR, người ta có thể tạo ra mã ác mộng ngay cả khi có trường hợp nhạy cảm vì vậy nó không phải là một sự khác biệt lớn).

Ngôn ngữ lập trình nên không phân biệt chữ hoa chữ thường.

Lý do chính khiến nhiều ngôn ngữ ngày nay rất nhạy cảm với trường hợp đơn giản là thiết kế ngôn ngữ hàng hóa: "C đã làm theo cách đó và C rất phổ biến, vì vậy nó phải đúng." Và cũng như rất nhiều thứ khác, C đã sai một cách sai lầm.

Đây thực sự là một phần của triết lý lái xe đằng sau C và UNIX: Nếu bạn có lựa chọn giữa một giải pháp tồi, dễ thực hiện và một giải pháp tốt khó thực hiện hơn, hãy chọn giải pháp tồi và đẩy gánh nặng làm việc xung quanh sự lộn xộn của bạn lên người dùng. Điều này nghe có vẻ giống như tiếng sủa, nhưng nó hoàn toàn đúng. Nó được gọi là "nguyên tắc tồi tệ hơn là tốt hơn" và nó chịu trách nhiệm trực tiếp cho thiệt hại trị giá hàng tỷ đô la trong vài thập kỷ qua do C và C ++ khiến việc viết phần mềm không ổn định và không an toàn trở nên quá dễ dàng.

Làm cho một trường hợp ngôn ngữ không nhạy cảm chắc chắn là dễ dàng hơn; bạn không cần bảng lexer, trình phân tích cú pháp và biểu tượng để thực hiện thêm công việc đảm bảo mọi thứ khớp với nhau trong trường hợp không nhạy cảm. Nhưng đó cũng là một ý tưởng tồi, vì hai lý do:

• Đầu tiên, đặc biệt là nếu bạn đang xây dựng một ngôn ngữ kịch bản, một lỗi đánh máy đơn giản mà bạn gọi một cái gì đó là "myObject" ở một nơi và "MyObject" ở một nơi khác, trong đó bạn rõ ràng đang đề cập đến cùng một đối tượng nhưng chỉ có một chút không phù hợp với chữ viết hoa , không biến thành một lỗi thời gian chạy. (Điều này nổi tiếng là một điểm đau lớn trong các ngôn ngữ kịch bản có lỗi này, chẳng hạn như Python.)
• Thứ hai, không có độ nhạy trường hợp có nghĩa là độ nhạy trường hợp không thể bị lạm dụng để có cùng một từ đề cập đến hai điều khác nhau trong cùng một phạm vi chỉ bằng cách thay đổi cách viết hoa. Nếu bạn đã từng phải làm việc với mã Windows trong môi trường C và gặp phải những tuyên bố xấu xí như thế HWND hwnd;, bạn sẽ biết chính xác những gì tôi đang nói. Những người viết như vậy oughtta bị lấy ra và bắn, và làm cho trường hợp ngôn ngữ không nhạy cảm ngăn chặn sự lạm dụng độ nhạy của trường hợp xâm nhập vào mã của bạn.

Vì vậy, làm cho nỗ lực thêm để làm cho nó đúng. Mã kết quả sẽ sạch hơn, dễ đọc hơn, ít lỗi hơn và giúp người dùng của bạn làm việc hiệu quả hơn và đó không phải là mục tiêu cuối cùng của bất kỳ ngôn ngữ lập trình nào?

Tôi không thể tin rằng ai đó đã nói "phân biệt chữ hoa chữ thường giúp đọc mã dễ dàng hơn".

Nó chắc chắn là không! Tôi đã nhìn qua vai của một đồng nghiệp về các biến được gọi là Công ty và công ty (Công ty biến công khai, công ty biến riêng tư phù hợp) và sự lựa chọn phông chữ và màu sắc của anh ta khiến cho việc phân biệt sự khác biệt giữa hai bên rất khó khăn - ngay cả khi ở cạnh nhau.

Câu lệnh đúng phải là "trường hợp hỗn hợp giúp đọc mã dễ dàng hơn". Đó là một sự thật rõ ràng hơn nhiều - ví dụ như các biến được gọi là CompanyName và CompanyAddress thay vì tên công ty. Nhưng không có ngôn ngữ nào tôi biết khiến bạn chỉ sử dụng tên biến chữ thường.

Quy ước điên rồ nhất mà tôi biết là "công khai chữ thường, chữ thường". Nó chỉ là yêu cầu rắc rối!

Tôi nhận lỗi là "tốt hơn là một cái gì đó thất bại ồn ào và càng sớm càng tốt chứ không phải lặng lẽ thất bại nhưng dường như thành công". Và không sớm hơn thời gian biên dịch.

Nếu bạn sử dụng nhầm biến chữ thường khi bạn định sử dụng chữ hoa, nó sẽ thường biên dịch nếu bạn đang tham chiếu nó trong cùng một lớp . Do đó, bạn có thể thành công trong cả thời gian biên dịch và chạy nhưng lại tinh tế làm sai, và có lẽ không phát hiện ra nó trong một thời gian dài. Khi bạn phát hiện ra rằng có điều gì đó sai

Tốt hơn nhiều để sử dụng một quy ước trong đó biến riêng tư có một hậu tố - ví dụ: biến công khai của Công ty, biến riêng của CompanyP. Không ai sẽ vô tình trộn lẫn cả hai, và họ xuất hiện cùng nhau trong intellisense.

Điều này trái ngược với một người phản đối phải ký hiệu Hungary, trong đó một biến riêng có tiền tố pCompany sẽ không xuất hiện ở một vị trí tốt trong intellisesne.

Quy ước này có tất cả các ưu điểm của quy ước chữ hoa / chữ thường đáng sợ và không có nhược điểm nào.

Việc mọi người cảm thấy cần phải thu hút sự nhạy cảm của trường hợp để phân biệt giữa các biến cho thấy cả sự thiếu trí tưởng tượng và thiếu ý thức chung, theo ý kiến ​​của tôi. Hay buồn thay, những con cừu con người thích thói quen tuân theo một quy ước bởi vì "đó là cách nó luôn luôn được thực hiện"

Làm cho những thứ bạn làm việc rõ ràng và rõ ràng khác biệt với nhau, ngay cả khi chúng có liên quan !!

Bạn không nên giới thiệu trường hợp vô cảm mà không có lý do chính đáng để làm như vậy. Ví dụ, xử lý các so sánh trường hợp với Unicode có thể là một bitch. Độ nhạy trường hợp (hoặc thiếu) của các ngôn ngữ cũ là không quan trọng, vì nhu cầu của chúng rất khác nhau.

Các lập trình viên trong thời đại này mong đợi trường hợp nhạy cảm.

Phân biệt chữ hoa chữ thường giúp mã dễ đọc hơn và lập trình dễ dàng hơn.

• Mọi người tìm thấy sử dụng đúng của trường hợp hỗn hợp dễ đọc hơn .

• Nó cho phép / khuyến khích CamelCase sao cho cùng một từ với các trường hợp khác nhau có thể đề cập đến những thứ liên quan: Car car; Do đó, biến có tên carđược tạo ra thuộc loại Car.

• ALL_CAPS_WITH_UNDERSCORES biểu thị các hằng số theo quy ước trong nhiều ngôn ngữ

• all_lower_with_underscores có thể được sử dụng cho các biến thành viên hoặc một cái gì đó khác.

• Tất cả các công cụ lập trình hiện đại (kiểm soát nguồn, trình soạn thảo, diff, grep, v.v.) được thiết kế cho độ nhạy trường hợp. Bạn sẽ mãi mãi gặp vấn đề với các công cụ lập trình được coi là điều hiển nhiên nếu bạn tạo ra một ngôn ngữ không nhạy cảm.

• Nếu ngôn ngữ sẽ được diễn giải, có thể có một hình phạt hiệu suất đối với trường hợp phân tích cú pháp không nhạy cảm của mã.

• Còn những nhân vật không phải người Anh thì sao? Bây giờ bạn có quyết định không bao giờ hỗ trợ Coplic, Trung Quốc và Hindi không? Tôi thực sự khuyên bạn nên đặt ngôn ngữ của mình mặc định mọi thứ thành UTF-8 và hỗ trợ một số ngôn ngữ có ký tự không có chữ hoa hoặc chữ thường. Bạn sẽ không sử dụng các ký tự này trong từ khóa của mình, nhưng khi bạn bắt đầu tắt phân biệt chữ hoa chữ thường trong các công cụ khác nhau (để tìm những thứ trong tệp), bạn sẽ gặp một số trải nghiệm siêu thực và có thể khó chịu.

Lợi ích là gì? 3 ngôn ngữ bạn đề cập là từ những năm 1970 trở về trước. Không có ngôn ngữ hiện đại làm điều này.

Mặt khác, bất cứ điều gì thực sự khiến người dùng cuối hài lòng đều mang lại một chút ánh sáng vào thế giới. Nếu nó thực sự sẽ ảnh hưởng đến hạnh phúc của người dùng, thì bạn phải làm điều đó.

Nếu bạn muốn làm cho nó thực sự đơn giản cho người dùng cuối, bạn có thể làm tốt hơn so với độ nhạy / không nhạy cảm của trường hợp - hãy xem Scratch ! Một vài con mèo hoạt hình ít hơn và màu sắc thân thiện với doanh nghiệp hơn và bạn có ngôn ngữ thân thiện nhất mà tôi từng thấy - và bạn không phải viết bất cứ điều gì! Chỉ là một ý nghĩ.