Điểm bổ sung hỗ trợ định danh Unicode cho các triển khai ngôn ngữ khác nhau là gì?

Cá nhân tôi thấy mã đọc đầy đủ các định danh Unicode khó hiểu. Theo tôi, nó cũng ngăn chặn mã dễ dàng được duy trì. Chưa kể tất cả những nỗ lực cần thiết cho các tác giả của các dịch giả khác nhau để thực hiện hỗ trợ đó. Tôi cũng liên tục nhận thấy sự thiếu (hoặc sự hiện diện) của hỗ trợ định danh Unicode trong danh sách (các) lợi thế của việc triển khai ngôn ngữ khác nhau (như nó thực sự quan trọng). Tôi không hiểu điều đó: tại sao rất nhiều sự chú ý?

Khi bạn nghĩ unicode, bạn nghĩ các ký tự tiếng Trung hoặc tiếng Nga, khiến bạn nghĩ về một số mã nguồn được viết bằng tiếng Nga mà bạn đã thấy trên internet và không thể sử dụng được (trừ khi bạn biết tiếng Nga).

Nhưng nếu unicode có thể được sử dụng sai cách, điều đó không có nghĩa là nó xấu trong mã nguồn.

Khi viết mã cho một trường cụ thể, với unicode, bạn có thể rút ngắn mã của mình và làm cho nó dễ đọc hơn . Thay vì:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

bạn có thể viết:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

có thể không dễ đọc đối với một nhà phát triển trung bình, nhưng vẫn dễ đọc đối với một người sử dụng các ký hiệu toán học hàng ngày .

Hoặc, khi thực hiện một ứng dụng liên quan đến chụp ảnh DSLR, thay vì:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

bạn có thể thay thế khẩu độ bằng ký hiệu của nó, bằng văn bản gần hơn với ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

Điều này có thể bất tiện : khi nhập mã C # chung, tôi thích viết hơn:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

thay vì:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

bởi vì trong trường hợp đầu tiên, IntelliSense giúp tôi viết toàn bộ mã gần như không cần gõ và đặc biệt là không sử dụng chuột, trong trường hợp thứ hai, tôi không biết tìm những ký hiệu đó ở đâu và sẽ buộc phải dựa vào chuột để đi và tìm kiếm chúng trong danh sách tự động hoàn thành.

Điều này đang được nói, nó vẫn hữu ích trong một số trường hợp. currentLens.GetMaximumƒ();ví dụ trước của tôi có thể dựa vào IntelliSense và dễ gõ như vậy GetMaximumAperture, ngắn hơn và dễ đọc hơn. Ngoài ra, đối với các tên miền cụ thể có nhiều ký hiệu, phím tắt có thể giúp nhập các ký hiệu nhanh hơn các ký tự tương đương trong mã nguồn.

Nhân tiện, tương tự, áp dụng cho ý kiến. Không ai muốn đọc mã đầy đủ các bình luận bằng tiếng Trung (trừ khi bạn biết rõ tiếng Trung Quốc). Nhưng trong một số ngôn ngữ lập trình, các ký hiệu unicode vẫn có thể hữu ích. Một ví dụ là chú thích¹.

^{Tôi chắc chắn sẽ không thích chú thích trong mã C # khi có một bộ quy tắc nghiêm ngặt về cách viết bình luận. Mặt khác, trong PHP, nếu có nhiều điều cần giải thích, nhưng những điều đó không quan trọng lắm, tại sao không đặt chúng ở dưới cùng của tệp và tạo một chú thích trong PHPDoc của phương thức?}

Tôi sẽ nói:

1. để giảm bớt những người không chuyên và người mới học lập trình (ví dụ như ở trường) và không biết tiếng Anh. Họ không viết mã sản xuất nào. Tôi đã thấy nhiều lần mã như:

   double upsos, baros;
   cin >> upsos >> baros;
   

   Chỉ cần để anh chàng nghèo viết nó bằng ngôn ngữ của mình:

   double ύψος, βάρος;
   cin >> ύψος >> βάρος;
   

2. Bạn không thích nó à?

   class ☎ {
   public:
       ☎(const char*);
       void 📞();
       void 🎧(👨);
   };
   
   ☎ ☏("031415926");
   ☏.🎧(👨("Bob"));
   ofstream f;
   f.💾();
   

Tất nhiên, mọi trình biên dịch hiện đại phải xử lý mã nguồn Unicode ngày nay. Ví dụ, hằng chuỗi có thể cần chứa các ký tự Unicode. Nhưng một khi điều này đạt được, tại sao không cho phép định danh unicode cũng? Sẽ không có vấn đề gì trừ khi mã trình biên dịch của bạn phụ thuộc vào các ký tự là mã 7 bit.

Nhưng OP là đúng khi nói: Có thể một người Ấn Độ nói tiếng Hindi phải duy trì mã với các định danh tiếng Nga và các bình luận tiếng Ả Rập. Thật là một cơn ác mộng đối với người Trung Quốc nghèo, những người được cho là phải kiểm tra chất lượng và những người không thể đọc bất kỳ bảng chữ cái nào trong 3 bảng chữ cái trên!

Do đó, giờ đây là một nhiệm vụ tổ chức để đảm bảo các định danh và nhận xét chương trình được viết bằng ngôn ngữ chung. Tôi không thể giúp nó nhưng tôi nghĩ rằng đây sẽ là tiếng Anh trong một thời gian tới.

Tôi nghĩ rằng sẽ rất có ý nghĩa khi cho phép các ký tự unicode trong chuỗi và nhận xét. Và nếu lexer & trình phân tích cú pháp phải hỗ trợ unicode cho điều đó, thì trình soạn thảo trình biên dịch có thể được hỗ trợ ký tự unicode trong các định danh miễn phí, do đó có vẻ như giới hạn tùy ý chỉ cho phép các ký tự ASCII trong mã định danh.

Theo tôi thấy, điều này hoàn toàn là vì lý do tiếp thị . Và ngoài ra có thể làm cho cuộc sống của chúng ta khó khăn hơn.

Các đối số tiếp thị

Bạn biết danh sách các tính năng điên rồ này mà hầu hết các ngôn ngữ tự hào? Nói chung, nó khá vô dụng, bởi vì nó khác xa với ngôn ngữ mà nó không cung cấp nhiều thông tin cụ thể, nhưng nó cho phép người ta nhanh chóng ăn mặc bàn có dấu và chữ thập và kết luận chính xác rằng vì X có nhiều dấu tích hơn Y nên nó phải để tốt hơn.

Vâng, hỗ trợ Unicode cho các định danh là một trong những dòng đó. Không quan trọng là so với hỗ trợ Lambda, hỗ trợ lập trình chung, v.v ... có thể không nhiều, mọi người vẽ các bảng không quan tâm đến chất lượng của từng dòng, chỉ về số lượng của chúng.

Và do đó, họ có thể tự hào: "Ah, với Y, bạn không có hỗ trợ Unicode cho số nhận dạng của mình! Trong X chúng tôi làm, vì vậy đối với sinh viên thì dễ dàng hơn nhiều!"

Sai lầm của khả năng tiếp cận

Thật không may, các đối số của khả năng tiếp cận là sai lầm.

Ồ, tôi hiểu rằng việc có thể viết "résultatDuJetDeDé" thay vì "diceThrowResult" (vâng tôi là người Pháp) có vẻ như là một chiến thắng trong ngắn hạn ... tuy nhiên có những hạn chế!

Lập trình là về giao tiếp

Chương trình của bạn không chỉ có ý nghĩa đối với trình biên dịch (có thể quan tâm ít hơn đến các định danh bạn sử dụng), nó cũng có nghĩa là cho các nghiên cứu sinh của bạn. Họ cần có khả năng đọc nó, và hiểu nó.

• đọc nó ngụ ý có thể hình dung các ký tự bạn đã sử dụng, Unicode không được hỗ trợ tốt bởi tất cả các phông chữ
• hiểu nó có nghĩa là dựa vào các định danh - trừ khi bạn bổ sung chúng bằng các bình luận dài dòng, nhưng điều đó vi phạm quy tắc DRY.

Tất nhiên, bạn cùng lớp của bạn có thể nói cùng một ngôn ngữ bạn làm (không rõ ràng, tôi đã có các lớp lập trình với người Đức, Tây Ban Nha, Libanes và Chineses), và giáo viên của bạn cũng vậy ... nhưng giả sử rằng bằng cách nào đó bạn đang làm việc ở nhà và đột nhiên cần sự giúp đỡ: Internet rất tuyệt, bạn có thể nói chuyện với hàng ngàn hàng ngàn người biết giải pháp, họ sẽ chỉ trả lời nếu họ hiểu câu hỏi của bạn. Và bạn cần phải hiểu câu trả lời của họ là tốt.

Lập trình đòi hỏi sự hiểu biết

Khả năng truy cập và khởi tạo yêu cầu bạn dựa vào các thư viện để thực hiện công việc nặng nề cho bạn: bạn không muốn phát minh lại một lớp IO để đọc từ / ghi vào bảng điều khiển trong bài tập đầu tiên.

• Những ngôn ngữ đó là những thư viện được viết?
• Những ngôn ngữ này là những thư viện tài liệu?

Nếu bạn trả lời tiếng Ả Rập Morrocan, tôi sẽ ngạc nhiên.

Trừ khi bạn chỉ dựa vào các bài giảng mà bạn hỗ trợ, và những tài liệu trình bày toàn diện về mọi tính năng thư viện bạn sẽ cần sử dụng (và thậm chí có thể là các thư viện dịch), thì bạn sẽ phải học một chút ngôn ngữ tiếng Anh. Nhưng sau đó, có lẽ bạn đã làm rất lâu trước khi bạn bắt đầu khóa học lập trình này.

Tiếng Anh là...

... ngôn ngữ chung của các lập trình viên (và hầu hết các nhà khoa học).

Càng sớm thừa nhận nó, và đi cùng với nó hơn là chiến đấu chống lại nó, thì càng sớm có thể thực sự học hỏi và tiến bộ.

Một số người chắc chắn sẽ chống lại điều này, và bảo vệ chính xác quyền nói ngôn ngữ mà họ lựa chọn (ngôn ngữ mẹ đẻ của họ), tuy nhiên, như Babel đã chứng minh, càng sử dụng nhiều ngôn ngữ, giao tiếp càng khó khăn hơn.

Vẫn...

Đúng, như đã được tranh luận nhiều lần, một số hỗ trợ Unicode (chủ yếu là các ký hiệu) có thể giúp dễ dàng hiểu được cho những người phải dịch các công thức toán học hoặc vật lý, ví dụ, thành mã. Có một nhược điểm là một số biểu tượng bị quá tải, nhưng nó vẫn có thể giúp ích.

Vậy tại sao ?

Vâng, như đã nói, nó không thực sự về sự tiện lợi của người dùng, cũng như về tuyên bố tiếp thị. Điều này cũng dễ dàng vì trình phân tích cú pháp đã nhận biết Unicode cho các chuỗi và nhận xét, vì vậy hầu hết đều thực hiện bước nhảy.

Và có thể có một lợi ích cho người dùng nhất định.

Nhưng cá nhân tôi sẽ chỉ đối phó với mã được viết bằng định danh tiếng Anh. Tôi không quan tâm nếu bạn cần sự giúp đỡ của tôi với đoạn mã của bạn hoặc nếu thư viện của bạn tuyệt vời và tôi có thể kiếm được nhiều tiền bằng cách sử dụng nó: nếu tôi không thể hiểu nó, tôi sẽ phải bỏ qua nó.

Làm thế nào bạn sẽ nhập định danh ASCII trên bàn phím Trung Quốc? Một vài từ khóa ngôn ngữ là một chuyện, và phải thực hiện toàn bộ mã của bạn theo cách đó là một điều khác.

Các lập trình viên nên có quyền và khả năng gọi các biến của họ bất cứ điều gì họ muốn. Không phải việc của bạn là ngôn ngữ đó.

Nếu bạn cảm thấy bối rối khi đọc mã với các mã định danh có ký hiệu từ ngôn ngữ của người khác, thì tôi chắc chắn rằng bạn hiểu chính xác họ cảm thấy bối rối như thế nào khi họ phải sử dụng mã định danh có ký hiệu từ ngôn ngữ của bạn .

Theo PEP 3131 - Hỗ trợ Số nhận dạng không ASCII ngày 2007, phần đầu tiên của Cơ sở lý luận:

Mã Python được viết bởi nhiều người trên thế giới không quen thuộc với ngôn ngữ tiếng Anh, hoặc thậm chí quen thuộc với hệ thống chữ viết Latinh. Các nhà phát triển như vậy thường mong muốn xác định các lớp và hàm với tên bằng ngôn ngữ mẹ đẻ của họ, thay vì phải đưa ra một bản dịch tiếng Anh (thường không chính xác) về khái niệm mà họ muốn đặt tên. Bằng cách sử dụng mã định danh trong ngôn ngữ mẹ đẻ của họ, độ rõ của mã và khả năng duy trì mã giữa các người nói ngôn ngữ đó sẽ được cải thiện.

Tôi chưa điều tra các ngôn ngữ khác, nhưng đó là một trong những lý do họ thêm hỗ trợ.

Nó thực sự sẽ làm cho cuộc sống dễ dàng hơn (đối với một số người trong chúng ta, dù sao) nếu trình biên dịch không hỗ trợ Unicode. Định danh từ phải sang trái là khủng khiếp. Bảng chữ cái La Mã kết hợp và số nhận dạng Unicode từ phải sang trái thậm chí còn tệ hơn.

Điều tệ hại về việc không hỗ trợ là các trình hướng dẫn GUI nhất định lấy văn bản bạn đặt cho một mục và tự động sử dụng văn bản đó làm định danh của mục đó. Vậy chính xác họ sẽ làm gì với văn bản Unicode trên các mục đó? Không có câu trả lời dễ dàng, tôi sợ.

Nhận xét Unicode từ phải sang trái cũng có thể buồn cười. Ví dụ, trong VS 2010, các nhận xét XML hiển thị (chính xác) dưới dạng RTL trong mã ... nhưng khi bạn sử dụng Intellisense để lấy mã định danh ở nơi khác trong mã, chú giải công cụ sẽ hiển thị (không chính xác) LTR. Tốt hơn, có lẽ, nếu không có hỗ trợ ở nơi đầu tiên? Một lần nữa, không phải là một cuộc gọi dễ dàng.