Nhận xét có cần thiết cho ngôn ngữ lập trình không?

Question

Sau một số suy nghĩ ngu ngốc về ngôn ngữ Klingon, xuất phát từ post Tôi bắt đầu một dự án sở thích ngớ ngẩn, tạo ra một ngôn ngữ lập trình Klingon biên dịch thành mã byte Lua. Trong giai đoạn thiết kế ngôn ngữ ban đầu tôi nhìn lên thông tin về Klingon programmers, và phát hiện ra về nguyên tắc lập trình này Klingon:

Một TRUE Klingon chiến binh không nhận xét mã của mình!

Vì vậy, tôi quyết định ngôn ngữ của tôi sẽ không hỗ trợ cho ý kiến ​​, như bất kỳ Klingon tốt sẽ không bao giờ sử dụng chúng.

Bây giờ nhiều cách Klingon không có vẻ hợp lý đối với chúng tôi Lập trình viên con người, tuy nhiên, khi thiết kế và thực hiện ngôn ngữ sở thích, tôi nhận ra rằng quy tắc Klingon về bình luận này thực sự rất hợp lý. .

Xóa khả năng nhận xét từ ngôn ngữ lập trình có nghĩa là tôi CÓ để viết mã biết chữ, không có ngoại lệ.

Vì vậy, tôi tự hỏi liệu có bất kỳ ngôn ngữ nào ở đó không hỗ trợ nhận xét?

Có bất kỳ đối số thực sự tốt nào để không xóa nhận xét khỏi một ngôn ngữ không?

Chỉnh sửa: Bất kỳ ví dụ tốt về nhận xét nào được yêu cầu?

---

PS> Ngôn ngữ Sở thích của tôi ở trên là một phần ngớ ngẩn anyways, do đó, không tập trung quá nhiều vào việc thực hiện của tôi, càng nhiều càng tốt các khái niệm về ý kiến ​​cần thiết nói chung

Answer 1

Tôi không chắc chắn tôi đồng ý với "Có" trong tuyên bố "Xóa khả năng nhận xét từ ngôn ngữ lập trình có nghĩa là tôi phải viết mã biết chữ, không có ngoại lệ", vì không phải là tất cả các mã được ghi lại . Tôi đoán là hầu hết mọi người sẽ viết mã không đọc được.

Hơn nữa, cá nhân tôi không tin vào thực tế của chương trình tự giải thích hoặc API trong thế giới thực tế.

Kinh nghiệm của tôi từ phân tích thủ công tài liệu của toàn bộ API cho luận án của tôi cho thấy rằng tất cả các bạn thường xuyên phải mang theo nhiều thông tin hơn bạn có thể truyền đạt trong chữ ký. Nếu bạn loại bỏ nhận xét giao diện khỏi ngôn ngữ của mình, các lựa chọn thay thế là gì? Không có tài liệu nào không phải là một lựa chọn. Tài liệu bên ngoài ít có khả năng được đọc.

Đối với tài liệu nội bộ, tôi có thể thấy quan điểm của bạn trong việc muốn giảm tài liệu để thuyết phục mọi người viết tốt hơn. Tuy nhiên, nhận xét phục vụ nhiều mục đích cộng tác và phối hợp và có nghĩa là nâng cao nhận thức về mọi thứ. Bằng cách trục xuất những chi tiết này đến các địa điểm mở rộng, bạn đang giảm cơ hội họ đến với nhận thức của người đọc trong tương lai, trừ khi công cụ của bạn là tuyệt vời.

Answer 2

Bạn có thể nghĩ rằng các nhà phát triển viết trong ngôn ngữ của bạn sẽ nỗ lực hơn để viết mã rõ ràng nhưng trên thực tế, bạn sẽ có trên bạn để thiết kế một ngôn ngữ là do đó nghĩa là không cần phải nhận xét. Địa ngục, thậm chí không phải tiếng Anh là như vậy (chúng tôi vẫn còn ngoặc đơn!). Nếu ngôn ngữ của bạn không được thiết kế như vậy, nó có thể rất hữu ích như Brainfuck và thích sự nổi tiếng và tôn trọng của Brainfuck.

Tôi có nên thêm liên kết hoặc liên kết được coi là nhận xét không?

Bên cạnh đó, mọi người sẽ tìm cách thêm nhận xét nếu cần bằng các chuỗi cao và lạm dụng các tên biến (không làm gì khác ngoài các nhận xét). Bạn đã đọc Godel Escher Bach chưa?

Answer 3

Tôi nghĩ câu hỏi có thể trở thành ngôn ngữ khép kín mà không có nhận xét? Ví dụ: nếu nó biên dịch xuống các tệp DLL được sử dụng trong mã khác, thì làm cách nào để biết bất kỳ điều gì vượt quá chữ ký hàm về những gì nó yêu cầu, thay đổi và trả về? Tôi sẽ không muốn có tên hàm là hàng chục ký tự để cố gắng thể hiện những gì có thể dễ dàng thực hiện với các bình luận ở trên hàm có thể được sử dụng làm tài liệu trong một cái gì đó giống như Trình duyệt đối tượng trong Visual Studio chẳng hạn.

Answer 4

Ngôn ngữ cần nhận xét.Ít nhất 95% ý kiến ​​có thể được thay thế bằng mã rõ ràng hơn nhưng vẫn có các giả định bạn cần để ghi lại và bạn hoàn toàn cần phải ghi lại nếu có một số vấn đề bên ngoài mà bạn đang làm việc xung quanh.

Tôi không bao giờ viết nhận xét mà không xem xét trước nếu tôi có thể thay đổi mã để loại bỏ nhu cầu nhưng đôi khi bạn không thể.

Answer 5

Bình luận chung là một mụn cóc cho thấy thiết kế kém, đặc biệt là những bình luận rambling dài, nơi rõ ràng nhà phát triển không có manh mối họ đang làm gì và cố gắng bù đắp bằng cách viết bình luận.

Nơi bình luận có ích:

• Rời một số vé bên cạnh một sửa chữa để các lập trình viên tương lai có thể hiểu được yêu cầu kinh doanh
• Giải thích một đặc biệt khó khăn Hack
• Bình luận trên logic kinh doanh cho một mảnh mã
• Mô tả nội dung trong tài liệu API để bên thứ ba có thể sử dụng API của bạn

Trong mọi trường hợp, các lập trình viên nên nỗ lực viết mã mô tả và KHÔNG viết các chú thích mô tả mã viết kém. Điều đó đang được nói rằng tôi nghĩ rằng có rất nhiều lý do hợp lệ mà ngôn ngữ nên và phải hỗ trợ ý kiến.

Answer 6

Mã của bạn có hai khán giả riêng biệt:

• Trình biên dịch
• Con người như chúng tôi

Nếu bạn chọn để loại bỏ ý kiến ​​hoàn toàn, giả định bạn đang dùng là bạn sẽ được chỉ phục vụ cho trình biên dịch và không có gì khác.

Tất nhiên bạn, là Klingon, có thể không cần nhận xét vì bạn không phải là con người. Có lẽ bạn có thể chứng minh rõ ràng cho chúng tôi khả năng của bạn bằng cách nói chuyện với IL thay vào đó?

Answer 7

Không nhận xét BẠN đang làm gì, nhưng TẠI SAO bạn đang làm điều đó.

WHAT được xử lý bằng mã sạch, dễ đọc và đơn giản với lựa chọn tên biến thích hợp để hỗ trợ. Nhận xét hiển thị cấu trúc cấp cao hơn cho mã không thể (hoặc khó) hiển thị bằng chính mã.

Answer 8

Mặc dù con người cần có khả năng nhận xét mã, nhưng ngôn ngữ không hỗ trợ trực tiếp nhận xét: đối với hầu hết các ngôn ngữ, sẽ không quan trọng để viết một tập lệnh xóa một nhận xét dòng (ví dụ: tất cả các dòng bắt đầu bằng '#' hoặc một số ký tự khác) sau đó chạy trình biên dịch.

Thực ra, tôi ngạc nhiên và thất vọng khi biết rằng ngay cả ngôn ngữ lập trình bí truyền yêu thích của tôi cũng hỗ trợ nhận xét: Brainf**k và Whitespace. Những ngôn ngữ này có nghĩa là khó đọc, vì vậy có vẻ như chúng không hỗ trợ nhận xét. (Trái ngược với ngôn ngữ bí truyền yêu thích khác của tôi: LOLCode, có nghĩa là tự ghi lại tài liệu, trong ngôn ngữ lolcats)

Tôi không đồng ý với những người trả lời khác về điểm này: Tôi nói, đúng với tầm nhìn của bạn về ngôn ngữ lập trình Klingon và không hỗ trợ nhận xét!

Answer 9

Sẽ là một ý tưởng tồi khi xóa toàn bộ cơ sở nhận xét. Chắc chắn các nhà phát triển phải học cách viết mã với các nhận xét tối thiểu tức là viết mã tự viết nhưng có rất nhiều trường hợp phải giải thích tại sao một cái gì đó đang được thực hiện theo cách của nó. Hãy xem xét các trường hợp sau:

• một nhà phát triển mới có thể bắt đầu duy trì mã và các dev ban đầu đã để lại/ra của dự án
• một sự thay đổi trong đặc tả hoặc yêu cầu thị trường dẫn đến một cái gì đó là truy cập trực quan
• thông báo ngay sao chép đặc biệt là nếu mã nguồn mở (một số libs mã nguồn mở yêu cầu bạn phải làm điều này)

đây cũng là kinh nghiệm của tôi rằng các lập trình viên mới có xu hướng bình luận hơn và khi họ phát triển chuyên môn mã của họ có xu hướng trở nên tự chủ tài liệu và súc tích . Nói chung, ý kiến ​​nên nói về TẠI SAO và KHÔNG LÀM THẾ NÀO VÀ GÌ.

Answer 10

Tất nhiên !!

Lý do chính là nhà phát triển mới làm quen. Không phải ai cũng biết cách viết mã biết chữ. Trên thực tế có hàng triệu người ra khỏi đó không nhận được một NullPointerException khi họ nhìn thấy một.

Chúng ta đều bắt đầu tại một số điểm.

Nhưng nếu bạn chỉ nhắm mục tiêu đến các nhà phát triển "chuyên gia", thì tại sao lại quan tâm đến ngôn ngữ ngay từ đầu. Bạn phải là using butterflies !!! Đó là những gì nhà phát triển thực sự sử dụng!

Nhận xét là phải, cố gắng làm cho khó hơn nếu bạn muốn (như sử dụng # // ##/chuỗi để tạo nhận xét hoặc điều gì đó tương tự) nhưng không bỏ qua.

:)

Answer 11

KHÔNG - không có ngôn ngữ lập trình đơn nào yêu cầu nhận xét.

Ngôn ngữ dành cho máy tính. Các bình luận dành cho con người. Bạn có thể viết một chương trình với 0% ý kiến. Nó sẽ thực thi, đúng hay sai. Bạn không thể viết một chương trình với 100% ý kiến. Nó sẽ không biên dịch - không có chính(), vv - hoặc, đối với các ngôn ngữ kịch bản, làm chính xác không có gì.

Và bên cạnh đó, real programmers don't comment their code. Giống như Klingons.

Answer 12

Điểm chống lại nhận xét là chúng có xu hướng thường bị lỗi thời với mã. Bất cứ lúc nào bạn thêm một dự phòng, bạn đang mạo hiểm loại không thống nhất này. Có một số nghiên cứu thú vị mà tôi đã thấy khi một nhóm sử dụng NLP để phân tích các nhận xét khóa trong một số hệ thống lớn và sau đó so sánh chúng với kết quả phân tích tĩnh và có thể sửa một vài lỗi theo cách đó.

Answer 13

Rất tiếc, không thể nhanh chóng nhận xét một dòng (hoặc dòng) trong khi thử nghiệm âm thanh gây phiền nhiễu cho tôi, đặc biệt là khi tập lệnh.

Answer 14

Nhận xét cần thiết cho ngôn ngữ lập trình phải không?

No. Trong lược đồ lớn của mọi thứ, trình biên dịch không quan tâm đến nhận xét và chỉ muốn mã xay xuống mẫu số chung thấp hơn.

Có ích cho ngôn ngữ lập trình để cung cấp cấu trúc nhận xét không?

Có. Bình luận rất hữu ích cho một lập trình viên và không chỉ giả mạo như họ biết những gì họ đang làm, mà còn trong việc gỡ rối và làm tài liệu hữu ích.

Answer 15

Trong khi tôi đồng ý với câu trả lời của Uri, tôi cũng đã tạo một ngôn ngữ không có nhận xét. (ichbins.) Ngôn ngữ đơn giản nhất có thể trong khi vẫn có thể thể hiện trình biên dịch riêng của mình một cách sạch sẽ; vì bạn có thể làm điều đó mà không có ý kiến, họ đã bị bỏ tù.

Tôi đang làm việc và thực hiện một sửa đổi có hỗ trợ bình luận, nhưng hơi khác: phong cách lập trình biết chữ với mã lồng trong văn bản thay vì nhận xét được nhúng trong mã. Nó cũng có thể nhận được ví dụ/trường hợp kiểm tra sau này như là một tính năng ngôn ngữ hạng nhất.

Chúc may mắn với cuộc tấn công Klingon. :-)

Answer 16

Lập trình không biết chữ là nhiều nhận xét vì nó là mã? Chắc chắn, phần lớn những gì tôi đã thấy về lập trình biết chữ có nhiều lời giải thích như mã, nếu không có nhiều bình luận hơn.

Answer 17

Tôi đồng ý với bạn rằng mã được viết độc đáo không cần bất kỳ nhận xét nào vì "Mã chỉ là tài liệu tốt cho lập trình viên. Tuy nhiên, đây là điều kiện rất lý tưởng, không phải ai cũng viết mã tốt mọi lúc. tốt trong ý kiến ​​tương lai được yêu cầu

Answer 18

tôi không thể cho bạn biết cách biết ơn tôi cho Javadoc -... đó là thực sự đơn giản để thiết lập trong phạm vi bình luận vì vậy, đó là ít nhất một cảm giác trong đó ý kiến ​​rất hữu ích

Answer 19

Tôi đã từng viết một ứng dụng VB (một trò chơi hội đồng ngớ ngẩn lấy cảm hứng từ Độc quyền) mà không có bất kỳ ý kiến ​​nào của. tắt giáo viên của tôi, người đã nói với chúng tôi nhận xét là "bất cứ điều gì chúng tôi tìm thấy có liên quan, vì vậy chúng tôi có thể nhớ sau này".

Answer 20

Không, tất nhiên ngôn ngữ không phải có nhận xét. Nhưng một chương trình (hữu ích) không cần phải có ý kiến ​​... Tôi không đồng ý với ý kiến ​​của bạn rằng mã chữ không có ý kiến. Một số mã rất tốt là dễ hiểu với các bình luận, nhưng chỉ với những khó khăn mà không có.

Answer 21

Mặc dù tất cả mã nguồn đều có bản quyền theo mặc định. Nó thường là tốt đẹp để:

1. nhắc nhở người đọc mã nguồn mà nó phụ thuộc vào bản quyền

2. nói với mọi người những gì các điều khoản cấp phép được cho rằng tập tin mã nguồn

3. nói với họ cho dù họ có đang xem xét bí mật thương mại được bảo vệ hay không

Thật không may, nếu không có ý kiến, rất khó để làm điều này.

Answer 22

Bạn không cần một xác nhận duy nhất trong mã của bạn bởi vì, ở chế độ phát hành, tất cả đều biến mất. Nhưng khi C++ không có xác nhận được xây dựng trong, ai đó đã viết macro khẳng định để thay thế nó.

Tất nhiên bạn không cần nhận xét, dù nhiều hơn hoặc ít hơn cùng một lý do. Nhưng nếu bạn thiết kế một ngôn ngữ không có nhận xét, mọi người sẽ bắt đầu làm những việc như:

HelperFunctionDoesNothing("This is a comment! Blah Blah Blah..."); 

Answer 23

Tôi rất tò mò. Làm thế nào để bạn ngăn chặn một người nào đó tuyên bố một chuỗi tĩnh có chứa một bình luận và sau đó bỏ qua biến cho phần còn lại của func/method/procedure/battle/anything?

var useless_comment = "Can we destroy our enemies?" 
if (phasers on full) return Qapla' 

Answer 24

Tôi nghĩ rằng các nhận xét là bắt buộc trong nhiều trường hợp.

Ví dụ: suy nghĩ về thuật toán. Giả sử có một hàm được viết bằng C giải quyết Traveling Salesperson Problem, có rất nhiều kỹ thuật có thể được sử dụng để giải quyết vấn đề này. Và các mã thường khó hiểu bởi bản chất của nó.

Không mô tả rõ ràng các thông số và thuật toán được sử dụng, bằng cách sử dụng nhận xét, hầu như không thể sử dụng lại đoạn mã này.

Answer 25

Tôi là người duy nhất nhận xét một vài dòng mã cho một số mục đích?

Answer 26

Mã hoàn hảo cần không có nhận xét. Nó phải đơn giản và dễ hiểu bởi những người mới hoàn thành.

Answer 27

Bất kỳ mã nào cần nhận xét, tôi cố gắng giải thích lý do và hoạt động của mọi chức năng tôi viết trong 1 hoặc 2 dòng.

Mã giải thích chính nó chỉ tồn tại trong một thế giới hoàn hảo, luôn có một số hack lạ hoặc một lý do để làm một cái gì đó nhanh chóng-n-bẩn thay vì cách propper. Điều tốt nhất cần nhớ là để bình luận TẠI SAO mã làm những gì nó làm, mã tốt giải thích GÌ nó làm 99% thời gian.

Viết một cái gì đó đơn giản, giống như một đoạn mã có thể giải quyết một câu đố Sudoku (3 hợp lý đơn giản trong khi vòng) và thử đọc 3 tháng sau đó. Bạn sẽ vô tình tìm thấy một cái gì đó mà không phải là chính xác rõ ràng.

Answer 28

Chúng ta có thể sống mà không có bình luận về mã không? Chắc chắn, nhưng điều đó sẽ không làm cho sống dễ dàng hơn.

Answer 29

Mã được viết một lần nhưng đọc nhiều lần trong suốt thời gian tồn tại; do đó, nó trả tiền để tối ưu hóa để dễ đọc. Việc đặt tên rõ ràng và nhất quán của mọi thứ từ hằng số đến các lớp là cần thiết, nhưng có thể hoặc có thể không đủ để đạt được mục tiêu này. Nếu không, điền vào các khoảng trống với các ý kiến, và duy trì chúng như bạn làm mã.

Answer 30

Nhận xét rất hữu ích vì họ trấn an người đọc mã của bạn - có thể là "tương lai bạn" - bạn đã nghĩ về phúc lợi của mình.

Answer 31

Sẽ khó khăn hơn bạn nghĩ để tạo một ngôn ngữ không thể nhận xét.

if (false) { 
    print("This is a comment. Chew on that, Klingons!") 
}