Tại sao vẫn có trường hợp nhạy cảm trong một số ngôn ngữ lập trình?

Tôi không thấy bất kỳ việc sử dụng nào cho phân biệt chữ hoa chữ thường trong ngôn ngữ lập trình, ngoài mã ẩn.

Tại sao thực hiện điều này trong một ngôn ngữ lập trình?

Cập nhật:

Có vẻ như ai đó bạn biết đã tuyên bố về điều này .

Mặc dù trường hợp gấp lại khá đơn giản trong tiếng Anh, nhưng nó lại kém hơn nhiều so với một số ngôn ngữ khác. Nếu một lập trình viên người Đức sử dụng ßtên biến, bạn sẽ xem xét trường hợp tương đương nào? Chỉ cần FYI, "ß" chỉ được sử dụng trong trường hợp thấp hơn. OTOH, "ss" là tương đương - bạn có xem xét một trình biên dịch bắt buộc phải khớp chúng không? Khi bạn vào Unicode, bạn sẽ nhận được nhiều vấn đề thú vị hơn, chẳng hạn như các ký tự có dấu phụ được soạn sẵn so với các dấu phụ kết hợp riêng biệt. Sau đó, bạn nhận được một số tập lệnh tiếng Ả Rập, với ba hình thức riêng biệt của nhiều chữ cái, thay vì chỉ hai.

Trong thời kỳ đen tối, hầu hết các ngôn ngữ lập trình đều không phân biệt chữ hoa chữ thường. Ví dụ, Pascal bắt đầu trên các máy tính lớn Dữ liệu điều khiển, chỉ sử dụng sáu bit cho mỗi ký tự (tổng cộng 64 mã). Hầu hết các máy như vậy đã sử dụng bộ ký tự "Khoa học CDC", chỉ chứa các ký tự chữ hoa. Bạn có thể chuyển sang các bộ ký tự khác, nhưng hầu hết đều có chữ hoa hoặc chữ thường, nhưng không phải cả hai - nhưng sử dụng cùng một mã cho cả hai. Điều tương tự cũng đúng với các mã Baudot cổ đại và được coi là tiêu chuẩn như vậy trong những ngày đầu của COBOL, FORTRAN, BASIC, v.v. .

Theo thời gian, khó khăn thực sự của sự không nhạy cảm với trường hợp đã trở nên rõ ràng hơn và các nhà thiết kế ngôn ngữ đã quyết định chủ yếu ("nhận ra" có thể là một thuật ngữ chính xác hơn) rằng khi / nếu mọi người thực sự muốn không nhạy cảm với trường hợp, thì nó được xử lý tốt hơn bằng các công cụ phụ trợ hơn trong ngôn ngữ

Ít nhất là IMO, trình biên dịch nên lấy đầu vào chính xác như được trình bày, không quyết định rằng "bạn đã viết cái này, nhưng tôi sẽ cho rằng bạn thực sự có ý gì khác." Nếu bạn muốn bản dịch diễn ra, tốt hơn hết bạn nên thực hiện chúng một cách riêng biệt, với các công cụ được xây dựng để xử lý tốt điều đó.

Tại sao bất cứ ai cũng muốn trường hợp vô cảm? Trong kịch bản nào là hữu ích để có thể đề cập đến một biến duy nhất như VARIABLEở một nơi, Variableở một nơi khác và variableở một phần ba? Trường hợp vô cảm là bực tức. Tôi thà nhận được một lỗi trình biên dịch khi tôi vô tình gõ VAriablethay vì Variableđể các lỗi chính tả như thế rơi vào mã của tôi.

Tóm lại, nhiều ngôn ngữ lập trình có độ nhạy trường hợp không chỉ vì lý do lịch sử / quán tính mà vì sự vô cảm của trường hợp là một ý tưởng tồi.

Trong trường hợp Java độ nhạy KHÔNG được sử dụng để cung cấp nhiều tùy chọn hơn trong mã, mà là cho một ý nghĩa ngữ nghĩa rất rõ ràng và nhất quán. Các lớp họcLookLike This. đối tượngLookLike This. phương thứcLookLike This (). STATIC_VARIABLES_LOOK_LIKE_THIS. Các lớp học.WithInnerClassLookLike This. Nó KHÔNG cung cấp sự tự do lớn hơn: nó cho phép bạn đóng gói một số thông tin chính xác vào ngôn ngữ dài dòng quá mức.

Tôi nghĩ rằng trong các ngôn ngữ được gõ tĩnh rõ ràng với trình biên dịch mucho và hỗ trợ IDE, phân biệt chữ hoa chữ thường là một cách tuyệt vời để truyền đạt thông tin (ví dụ: Java). Với các ngôn ngữ như Ruby, tính không nhạy cảm của trường hợp có thể sẽ gây ra nhiều kết quả bất ngờ HƠN, mặc dù tôi sẵn sàng thử dùng Ruby không phân biệt chữ hoa chữ thường.

Tôi nghĩ rằng trường hợp nhạy cảm với một hệ thống nghiêm ngặt không làm xáo trộn mã nhưng thực sự làm cho nó rõ ràng hơn. Xem xét mã Java có thể:

      joe blah = new hUf();

Điều đó khá rõ ràng, nhưng về:

      hUf.WTF();

Trong Java, nó sẽ tự động biết đây là gì. Trong Java không phân biệt chữ hoa chữ thường, nó không rõ ràng, vì vậy bạn cần sử dụng một số cơ chế khác để phân biệt các lớp với các cá thể với các gói từ các phương thức. Và cơ chế đó có lẽ sẽ khiến bạn nôn mửa với sự xấu xí của nó :)

Tôi không nghĩ rằng nó đã được "thực hiện" nhiều đến mức "được phép". Độ nhạy trường hợp là trạng thái mặc định của so sánh chuỗi; kỹ sư trình biên dịch phải làm cho trường hợp ngôn ngữ trở nên không nhạy cảm, vì bạn cần thêm mã bổ sung để thực hiện so sánh không phân biệt chữ hoa chữ thường và giữ nguyên tên mã thông báo để báo cáo lỗi và cảnh báo chính xác.

Đó gần như chắc chắn là lý do tại sao nó kết thúc bằng C; họ muốn tạo ra một ngôn ngữ đơn giản, dễ thực hiện trình biên dịch, với chi phí khả dụng. Đối với lý do tại sao nó trong langauges hiện đại? Bởi vì nó ở C, tất nhiên, vì vậy nó phải là cách đúng đắn để làm điều đó! </ chế độ châm biếm>

Nếu không có gì khác, nó đơn giản hóa việc phân tích cú pháp và cho phép bạn kết hợp nhiều hơn cho tên biến / lớp.

Với phân tích cú pháp không phân biệt chữ hoa chữ thường, bạn sẽ bị hạn chế sử dụng các mã định danh duy nhất, vì 'myClass' và 'MyClass' sẽ giống nhau. Ngoài ra, bạn phải thêm các lớp phức tạp vào trình phân tích cú pháp để đảm bảo bạn có thể xác định định danh nào được sử dụng dựa trên ngữ cảnh.

Hãy xem xét một trường hợp như thế này:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Giả sử lớp XmlWriter cũng có một phương thức tĩnh gọi là "Viết". Bạn đang gọi nó trên ví dụ hoặc trên lớp, nếu không có phân biệt chữ hoa chữ thường được áp dụng ở đây?

Tôi thích trường hợp nhạy cảm nếu không vì lý do nào khác ngoài việc nó làm cho mã tự ghi lại nhiều hơn:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

Tôi thường lập trình bằng Python, nhưng trở lại trong những ngày C # của tôi, tôi thấy rất thuận tiện khi đặt tên các thể hiện của lớp giống như lớp, nhưng trường hợp thấp hơn (hoặc lạc đà) (như những người khác đã nói):

Thing thing = new Thing();

Sử dụng các ngôn ngữ không phân biệt chữ hoa chữ thường đòi hỏi một số quy ước khác cho điều này, nghĩa là, một số loại sigil như:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

Đó là một "điều xấu".

Tôi cũng thấy thuận tiện khi grep (phân biệt chữ hoa chữ thường) để tìm tham chiếu đến một lớp so với việc sử dụng một biến. Với một ngôn ngữ không phân biệt chữ hoa chữ thường, việc này sẽ ít dễ dàng hơn. Tương tự cho tìm kiếm và thay thế.

Cuối cùng, với tư cách là một lập trình viên, khi tôi thấy các từ với các trường hợp khác nhau, tôi nhận ra rằng chúng là những thứ khác nhau ... Tôi hiếm khi gặp lỗi trong đó các trường hợp biến đổi là sai, ngay cả trong các ngôn ngữ động, kịch bản mà trình biên dịch sẽ giúp.

Mọi người chú ý đến hình dạng của các từ trước khi họ thực sự đọc chúng. Độ nhạy trường hợp giữ hình dạng của một biểu tượng nhất quán trong suốt mã. Tôi cũng đồng ý với những điều nêu trên rằng các quy ước khác nhau biểu thị các loại biểu tượng khác nhau. Trường hợp nhạy cảm và vô cảm có thể bị lạm dụng. Lập trình viên xấu sẽ luôn tạo mã xấu ... họ sẽ tìm ra cách.

Lấy ngôn ngữ làm ví dụ. Tại sao chúng ta bắt đầu câu và đặt tên các thứ bằng chữ hoa ... Có phải đó cũng là do unix?

Tôi nghĩ đối với các làn đường được gõ tĩnh như C # và Java, nó thực sự không thêm bất kỳ giá trị nào. Bởi vì trong hầu hết các trường hợp, bạn đã có một IDE sẽ tự động sửa trường hợp không khớp cho bạn, vì vậy vào cuối ngày, nếu tôi gõ "VAriable" một cách tình cờ, IDE của tôi sẽ tự động sửa nó thành " Biến "cho tôi. Thêm vào đó là các MyClass myClass;quy ước về phong cách và bạn có thể thấy rằng phân biệt chữ hoa chữ thường không nhất thiết là một điều xấu.

Đối với các ngôn ngữ được gõ động, có thể có nhiều tranh luận hơn, vì IDE khó đoán hơn về tự động, nhưng trong trường hợp ngôn ngữ được gõ động, bạn đã lo lắng nhiều hơn (về lỗi chính tả) rằng sử dụng quy ước vỏ nhất quán sẽ không gây thêm gánh nặng.

Vì vậy, có, trong khi không có lý do thực sự ngôn ngữ không thể không phân biệt chữ hoa chữ thường, thì cũng không có lý do thực sự tại sao chúng phải là một trong hai.

Bài viết đó của Scott Hanselman về "SignOn" so với "Signon" là về so sánh chuỗi, và không liên quan gì đến ngôn ngữ lập trình. Tôi đồng ý rằng các chuỗi mà người dùng nhập vào phải luôn luôn so sánh không phân biệt chữ hoa chữ thường, nhưng tôi nghĩ đó là một trò chơi bóng khác với các định danh trong ngôn ngữ lập trình.

Khi một ngôn ngữ phân biệt chữ hoa chữ thường, tôi tận dụng nó để tái tạo cách sử dụng chữ hoa thông thường trong toán học và khoa học. Dưới đây là danh sách (không có nghĩa là toàn diện) của một số quy ước trường hợp:

• Trong lý thuyết xác suất, chữ fthường thường đại diện cho hàm mật độ xác suất (pdf), trong khi chữ hoa Fđại diện cho hàm phân phối tích lũy tương ứng (cdf).
• Cũng trong lý thuyết xác suất, các chữ cái viết hoa biểu thị các biến ngẫu nhiên Xvà các chữ cái viết thường tương ứng biểu thị việc thực hiện chúng x, như trong $ Pr [X = x] \ leq 0,05 $.
• Trong đại số tuyến tính, chữ thường viết thường được sử dụng để chỉ ma trận trong khi chữ thường viết thường được sử dụng để chỉ các số, ví dụ: $ A = [a_ {ij}] $.
• Ký hiệu đơn vị được viết bằng chữ in thường (ví dụ: m cho mét) ngoại trừ lít (L) và các đơn vị xuất phát từ tên của một người (W cho Watt, Pa cho Pascal, N cho Newton, v.v.).
• Ký hiệu của các tiền tố có nghĩa là một triệu hoặc nhiều hơn được viết hoa (M cho mega (triệu)) và những tiền tố dưới một triệu là chữ thường (m cho milli (phần nghìn)).

Tôi chỉ hình dung đó là do Unix và C - nhưng đó là vấn đề về con gà và quả trứng mà chỉ có geezers mới có thể trả lời đúng.

Tôi sử dụng lý do mà các chú gà trong "Chú thỏ Phục sinh đang đến thị trấn" đã sử dụng khi được hỏi liệu chúng có đến trước Trứng không. Bởi vì có gà trên thuyền Ark, gà đến trước. Do đó, vì GCC chạy trên Unix, Unix xuất hiện đầu tiên, do đó Unix quan tâm rất nhiều đến trường hợp, C và tất cả các biến thể và hậu duệ của nó, không có bất cứ điều gì áp đặt dấu ngoặc nhọn, quan tâm đến trường hợp.

Có lẽ có một liên kết giữa niềng răng xoăn và trường hợp nhạy cảm quá.

Ngoài các câu trả lời xuất sắc được đưa ra cho đến nay, tôi muốn chỉ ra rằng độ nhạy trường hợp cung cấp cho bạn thêm "không gian tên". Ví dụ, Perl có một số khối đặc biệt như BEGINvà ENDchạy ở các thời điểm khác với mã thông thường (BEGIN tại thời gian biên dịch, END sau khi chương trình bình thường kết thúc) và có những khối như tất cả làm cho chúng nổi bật và có nghĩa là chữ thường các biến thể không dành riêng từ.

Người ta có thể đi xa hơn và bảo lưu các tên viết hoa để sử dụng ngôn ngữ trong tương lai và không gây hại cho các lập trình viên bình thường, những người thường KHÔNG NÊN BẮT ĐẦU MÃ SỐ.

"Phân biệt chữ hoa chữ thường" luôn tốt hơn cho người kỹ thuật để giảm sự mơ hồ. Lấy tên tệp làm ví dụ. Xử lý tên tệp Windows gặp nhiều rắc rối hơn tên tệp Unix vì tên tệp trong Windows không phân biệt chữ hoa chữ thường trong khi tên tệp trong Unix phân biệt chữ hoa chữ thường.

Quay lại lập trình. Đối với tên lớp, tên phương thức, tên biến, hầu hết các ngôn ngữ không thực thi quy tắc kiểu đặt tên. Đôi khi vì mục đích đơn giản để thực hiện "phản chiếu", chúng ta chỉ cần sử dụng tên "Phân biệt chữ hoa chữ thường" để liên kết với nguồn dữ liệu khác mà không cần chuyển đổi hoặc xử lý vấn đề cùng tên nhưng trong trường hợp khác.

Tôi ngạc nhiên trước câu nói này. Bây giờ không ai muốn bạn sử dụng dấu gạch dưới hoặc m_tên trường trong C #, tôi đã sử dụng trường hợp lạc đà và nếu tên trường giống như tên thuộc tính công khai, thì tên thuộc tính công khai là trường hợp Pascal và trường sao lưu là trường hợp lạc đà, tôi nghĩ, "vậy thôi" - đó là điều mà cộng đồng lập trình nói chung dường như muốn. Nó đã không gây ra bất kỳ vấn đề cho đến nay.

Đặc biệt là một số lập trình viên đến từ những ngày đầu của BASIC, trong đó một tên biến chỉ có thể dài 2 ký tự.

Và vì vậy, khi nó có thể là bất kỳ số lượng nhân vật, họ trở nên rất hạnh phúc. Và cùng với trường hợp nhạy cảm - bởi vì họ không muốn quan tâm đến SomeNameviệc vô tình bằng SOMENAMEvà gây ra lỗi do những điều như thế này.