Tại sao hầu hết các ngôn ngữ lập trình không lồng ý kiến ​​khối?

Một số ít làm, nhưng không phải bất kỳ trong số những người nổi tiếng như tôi biết. Có điều gì xấu về ý kiến ​​lồng nhau?

Tôi dự định có các bình luận khối lồng trong ngôn ngữ (nhỏ) mà tôi đang làm việc, nhưng tôi muốn biết liệu đây có phải là một ý tưởng tồi hay không.

Một điều chưa ai đề cập đến, vì vậy tôi sẽ đề cập đến nó: Mong muốn lồng ý kiến ​​thường chỉ ra rằng lập trình viên đang làm sai.

Đầu tiên, chúng ta hãy đồng ý rằng lần duy nhất "lồng" hoặc "không lồng" được hiển thị cho lập trình viên là khi lập trình viên viết một cái gì đó có cấu trúc như thế này:

do_something();
/* comment /* nested comment */ more comment */
do_something_else();

Bây giờ, khi một điều như vậy xuất hiện trong thực tế? Chắc chắn lập trình viên sẽ không viết những bình luận lồng nhau mà theo nghĩa đen giống như đoạn trích trên! Không, trong thực tế khi chúng ta lồng ý kiến ​​(hoặc ước chúng ta có thể lồng chúng), đó là vì chúng ta muốn viết một cái gì đó như thế này:

do_something();  /* do a thing */
/* [ajo] 2017-12-03 this turned out to be unnecessary
do_something_else(); /* do another thing */
*/

Và đây là BAD. Đây không phải là một mô hình mà chúng tôi (như các nhà thiết kế ngôn ngữ) muốn khuyến khích! Cách chính xác để viết đoạn trích trên là:

do_something();  /* do a thing */

Mã "sai" đó, bắt đầu sai hoặc bất kể đó là gì, không thuộc về cơ sở mã. Nó thuộc về, tốt nhất, trong lịch sử kiểm soát nguồn. Lý tưởng nhất là bạn sẽ không bao giờ viết mã sai để bắt đầu, phải không? Và nếu mã sai đang phục vụ một mục đích ở đó, bằng cách cảnh báo các nhà bảo trì không khôi phục nó vì một lý do nào đó, thì đó có lẽ là một công việc cho một nhận xét mã được viết tốt và có chủ ý. Cố gắng diễn đạt "không làm X" bằng cách chỉ để lại một số mã cũ làm X, nhưng nhận xét, không phải là cách dễ đọc hoặc hiệu quả nhất để ngăn mọi người làm X.

Tất cả điều này rút ra một quy tắc đơn giản mà bạn có thể đã nghe trước đây: Đừng bình luận ra mã. (Đang tìm kiếm các cụm từ này sẽ bật lên một nhiều của ý kiến trong thỏa thuận .)

Trước khi bạn hỏi: có, các ngôn ngữ như C, C # và C ++ đã cung cấp cho lập trình viên một công cụ khác để "nhận xét" các khối mã lớn : #if 0. Nhưng đây chỉ là một ứng dụng cụ thể của bộ tiền xử lý C, đây là một công cụ lớn và hữu ích theo đúng nghĩa của nó. Nó thực sự sẽ vô cùng khó khăn và đặc biệt đối với một ngôn ngữ để hỗ trợ biên dịch có điều kiện #ifmà không hỗ trợ #if 0.

Vì vậy, chúng tôi đã thiết lập rằng các bình luận lồng nhau chỉ có liên quan khi lập trình viên đang bình luận ra mã; và chúng tôi đã thành lập (thông qua sự đồng thuận của rất nhiều lập trình viên có kinh nghiệm) rằng nhận xét mã là một điều xấu.

Để hoàn thành tam đoạn luận, chúng ta phải chấp nhận rằng các nhà thiết kế ngôn ngữ có mối quan tâm đến việc quảng bá những điều tốt và làm nản lòng những điều xấu (giả sử rằng tất cả những thứ khác đều bằng nhau).

Trong trường hợp các bình luận lồng nhau, tất cả các bình luận khác đều bằng nhau - bạn có thể bỏ qua các câu trả lời được bỏ phiếu thấp một cách an toàn cho rằng phân tích cú pháp lồng nhau /*sẽ gây khó khăn cho trình phân tích cú pháp. (Lồng nhau /*không khó hơn lồng nhau (, điều mà gần như mọi trình phân tích cú pháp trên thế giới đã cần xử lý.)

Vì vậy, tất cả những thứ khác đều bằng nhau, một nhà thiết kế ngôn ngữ có thể dễ dàng lồng các bình luận (nghĩa là để nhận ra mã), hay khó? Hãy nhớ lại rằng bình luận ra mã là một điều xấu.

QED

Chú thích. Lưu ý rằng nếu bạn không cho phép các bình luận lồng nhau, thì

hello /* foo*/bar.txt */ world

là một "bình luận" sai lệch - nó tương đương với

hello bar.txt */ world

(có khả năng là một lỗi cú pháp). Nhưng nếu bạn làm phép bình luận lồng nhau, sau đó

hello /* foo/*.txt */ world

là một "bình luận" sai lệch - nó tương đương với

hello

nhưng để bình luận mở hết cỡ đến cuối tập tin (một lần nữa gần như chắc chắn là lỗi cú pháp). Vì vậy, không có cách nào đặc biệt ít bị lỗi cú pháp không chủ ý. Sự khác biệt duy nhất là cách họ xử lý các phản hạt có chủ ý của mã nhận xét.

Bởi vì hầu hết các triển khai đang sử dụng các giai đoạn lexing và phân tích cú pháp riêng biệt, và để lexing chúng sử dụng các biểu thức chính quy cũ đơn giản. Nhận xét được coi là khoảng trắng - nghĩa là các mã thông báo bị bỏ qua và do đó nên được giải quyết hoàn toàn trong một lần vượt qua. Ưu điểm duy nhất của phương pháp này là phân tích tốc độ. Nhiều nhược điểm bao gồm các hạn chế nghiêm trọng về cú pháp (ví dụ: cần duy trì một bộ từ khóa cố định, không phụ thuộc vào ngữ cảnh).

Hoàn toàn có thể tạo ra một từ vựng có thể xử lý các bình luận lồng nhau. Khi nó ăn khoảng trắng, khi nó nhìn thấy /*nó có thể tăng bộ đếm độ sâu và giảm nó khi nhìn thấy */và dừng lại khi độ sâu bằng không. Điều đó nói rằng, tôi đã thực hiện nhiều trình phân tích cú pháp và không bao giờ tìm thấy lý do chính đáng để các bình luận lồng nhau.

Nếu các bình luận có thể lồng nhau, thì một nhược điểm là dễ khiến cho kết thúc của chúng không cân bằng và trừ khi bạn có một trình soạn thảo ưa thích, nó có thể ẩn mã vô hình mà bạn cho là có.

Mặt trái của những bình luận không làm tổ là một cái gì đó như thế này:

/*
some code
more code
blah blah blah
/**/

nơi bạn có thể dễ dàng nhận xét mã vào hoặc ra bằng cách xóa hoặc thêm dòng đầu tiên - chỉnh sửa 1 dòng. Tất nhiên, nếu bản thân mã đó chứa một nhận xét, điều này sẽ bị hỏng, trừ khi bạn cũng cho phép //nhận xét kiểu C ++ trong đó. Vì vậy, đó là những gì tôi có xu hướng làm.

Vì không ai khác đề cập đến nó, tôi sẽ liệt kê một vài ngôn ngữ hỗ trợ các bình luận lồng nhau: Rexx, Modula-2, Modula-3, Oberon. Mặc dù tất cả các khiếu nại ở đây về các vấn đề khó khăn và tốc độ, không ai trong số họ dường như có bất kỳ vấn đề lớn.

Một điểm hay của các nhận xét khối lồng nhau là bạn có thể nhận xét các phần lớn của mã một cách dễ dàng (tốt, hầu như, trừ khi bạn có chuỗi kết thúc nhận xét khối trong một chuỗi hằng).

Một phương pháp khác là thêm vào một loạt các dòng với trình tự bắt đầu nhận xét dòng nếu bạn có một trình soạn thảo hỗ trợ nó.

Haskell đã lồng các bình luận khối, nhưng hầu hết mọi người dường như không chú ý hoặc phàn nàn về nó. Tôi đoán điều này là do những người không mong đợi các bình luận lồng nhau có xu hướng tránh chúng vì đây sẽ là một lỗi từ vựng trong các ngôn ngữ khác.

Hỗ trợ các bình luận khối lồng nhau làm phức tạp trình phân tích cú pháp, đây là công việc nhiều hơn và nó có thể làm tăng thời gian biên dịch. Tôi đoán nó không phải là một tính năng rất cần thiết cho một ngôn ngữ, vì vậy tốt hơn là sử dụng thời gian và nỗ lực cho các cải tiến và tối ưu hóa khác.

Theo tôi sự đơn giản luôn là một điều tốt trong việc thiết kế bất cứ thứ gì. Hãy nhớ rằng việc thêm một tính năng sẽ dễ dàng hơn việc xóa nó. Khi bạn cho phép nhận xét lồng nhau và có các chương trình sử dụng nó, bạn sẽ không thể đưa chúng ra mà không phá vỡ tính tương thích.

Một lý do có thể xảy ra là các bình luận lồng nhau phải được xử lý bởi trình phân tích cú pháp, vì hương vị của các biểu thức chính quy thường được sử dụng trong các từ vựng không hỗ trợ đệ quy. Những cái đơn giản có thể được loại bỏ dưới dạng khoảng trắng bởi lexer, vì vậy chúng đơn giản hơn để thực hiện theo cách đó.

Ai biết? Tôi đoán bởi vì việc hỗ trợ các bình luận lồng nhau là công việc nhiều hơn - bạn sẽ phải duy trì một nhóm sắp xếp nào đó, và vì nó làm phức tạp ngữ pháp ngôn ngữ.

Bình luận lồng nhau có nghĩa là công việc thêm cho trình phân tích cú pháp. Thông thường khi bạn nhìn thấy bắt đầu một bình luận, bạn bỏ qua mọi thứ cho đến khi đánh dấu bình luận kết thúc. Để hỗ trợ các bình luận lồng nhau, bạn cũng phải phân tích văn bản trong các bình luận. Tuy nhiên, vấn đề lớn nhất là một lập trình viên phải cẩn thận để đóng tất cả các bình luận lồng nhau một cách chính xác nếu không sẽ dẫn đến lỗi biên dịch. Thực hiện đúng trình biên dịch là một việc có thể làm nhưng việc theo dõi các bình luận lồng nhau vì một lập trình viên khá dễ bị lỗi và khó chịu.