經過對克林貢語言的一些愚蠢的思考後，來自這個post我開始了一個愚蠢的愛好項目，創建一個編譯爲Lua字節碼的克林貢編程語言。在最初的語言設計階段我擡起頭來有關Klingon programmers，並發現了這個克林貢語的編程規則：編程語言需要註釋嗎？
一個真正的克林貢勇士不評論他的代碼！
所以，我決定我的語言將不支持評論，因爲任何好的克林貢語永遠不會使用它們。
現在很多克林貢的方式對我們來說似乎並不合理人類程序員，但是在涉足我的愛好語言的設計和實現時，我開始意識到這個克林貢關於評論的規則的確非常合理，如果不是很好。
刪除從一種編程語言評論的能力意味着我HAVE寫識字碼，沒有例外。
所以它讓我想知道是否有任何語言不支持評論？
是否有任何非常好的論點不從語言中刪除評論？
編輯：任何需要評論的好例子？
PS>我的愛好之上的語言是部分傻反正，所以不要過於注重我的實現，儘可能的在一般
我不確定我是否同意這個陳述中的「有」：「從編程語言中刪除評論的能力意味着我必須編寫識字代碼，沒有例外」，因爲它不像所有的代碼都被記錄。我的猜測是，大多數人會寫不可讀的代碼。
更重要的是，我個人並不相信實際世界中的自解釋程序或API的真實性。
我從手工分析論文的整個API文檔的經驗表明，你經常需要攜帶更多的信息，而不是單單在簽名中傳達的信息。如果您從您的語言中刪除界面評論，還有什麼選擇？沒有文件不是一個選項。外部文檔不太可能被讀取。至於內部文檔，我可以看到你想減少文檔以說服人們寫得更好的觀點。然而，評論服務於許多協作和協調目的，旨在提高對事物的認識。通過將這些細節消除到外部位置，您將減少未來讀者意識到的機會，除非您的工具很棒。
+1因爲不得不外部化文檔依賴性是支持評論的重要一點。 – 2008-12-24 05:24:27
謝謝。這通常是一個問題：如果人們不知道它們存在，人們就不會去尋找。我的很多研究都集中在人們是否調查方法文檔的問題上，看他們是否傳達了任何重要的東西 - 它們不是，這會導致嚴重的問題。 – Uri 2008-12-24 05:37:20
需要註釋的概念，你可能會認爲開發商編寫您的語言將會額外付出努力去編寫明確的代碼，但實際上您的您設計的語言是所以表示它不需要評論。地獄，甚至連英文都不是這樣（我們仍然括號！）。如果你的語言設計得不那麼完美，它可能會像Brainfuck一樣可用，並享受Brainfuck的知名度和尊重。
我應該添加鏈接還是鏈接被認爲是評論性的？
此外，如果需要通過劫持字符串和濫用變量名稱（除了代表註釋以外別無他用），人們將找到添加註釋的方法。你有沒有讀過Godel Escher Bach？
好的可敬性並不是這裏的主要問題，但除此之外，我想不出任何需要表達性的語言特徵，你有沒有什麼好的例子？ – 2008-12-24 05:14:00
AFAIK，所有語言解析器都忽略註釋，因爲它們用於自然語言編寫，這些語言具有表達性，但是由於編寫確定性解析器而過於依賴上下文。 – 2008-12-24 05:19:25
還沒有讀過GED，但看起來像一個很好的閱讀。要訂購:) – 2008-12-24 06:58:12
我認爲這個問題可能會變得沒有意見的語言是獨立的嗎？例如，如果它編譯成在其他代碼中使用的DLL，那麼除了函數簽名之外，如何知道它需要什麼，更改和返回的內容？我不希望函數名稱爲數十個字符，以試圖表達可能非常容易完成的註釋，該註釋可用作Visual Studio中的對象瀏覽器等文檔中的函數。
語言需要註釋。至少有95％的評論可以用更清晰的代碼替代，但仍然有假設需要記錄，並且如果存在某些外部問題，您絕對需要記錄這些假設。
我從來沒有寫第一個評論，如果我可以改變代碼來消除它的需要，但有時你不能。
一般來說，評論是一種瑕疵，表明設計不佳，特別是漫長的漫長評論，其中明確的開發人員不知道他們在做什麼，並試圖通過寫評論來彌補。
鄰居那裏的意見是有用的：
在任何情況下，程序員都應該努力編寫描述性的代碼，而不是編寫描述寫得不好的代碼的註釋。這就是說，我認爲語言應該並且必須支持評論有很多有效的理由。
+1爲真實的例子，特別是票（和TODO有關） – 2008-12-24 05:29:29
門票和TODO可以納入語言。事實上，這將是非常棒的。 – 2008-12-24 05:48:11
您的權利Marxidad，TODO和門票可以類似於Deprecatation完成，偉大的想法將將其納入我的設計 – 2008-12-24 05:54:45
你的代碼中有兩種不同的受衆：
如果選擇完全刪除評論，你正在服用的假設是，你會只適用於編譯器，並沒有別的。
當然，作爲克林貢，你可能不需要評論，因爲你不是人。也許你可以用IL來說明我們的能力嗎？
對於人類觀衆+1 +1 – 2008-12-24 05:27:50
不要評論你在做什麼，但爲什麼你這樣做。
什麼是由乾淨，可讀和簡單的代碼照顧妥當的變量名稱選擇來支持它。註釋顯示代碼本身不能（或難以顯示）的代碼的更高級別的結構。
儘管人們需要能夠評論代碼，但語言並不一定需要直接支持評論：對於大多數語言來說，編寫一個刪除一行註釋的腳本將是微不足道的（例如，所有以'＃'或其他字符開頭的行）然後運行編譯器。
其實，雖然我很驚訝，也很失望，得知即使我最喜歡的深奧編程語言也支持評論：Brainf**k和Whitespace。這些語言的目的是難以閱讀，所以它們似乎不應該支持評論。 （相對於我的其他最喜歡的深奧語言：LOLCode，這意味着要自我記錄，用lolcats-speech）
我會在這一點上對其他回答者持不同意見：我說，要忠於你對一種克林貢編程語言，並且不支持評論！
完全刪除評論工具將是一個壞主意。當然，開發人員必須學會用最少的註釋來編寫代碼，即編寫自我記錄的代碼，但在很多情況下，必須解釋爲什麼要按照原樣進行操作。考慮以下情況：
這也是我的經驗，新的程序員往往多加評論，併爲他們開發的專業知識他們的代碼會變得自我記錄和簡潔。一般來說評論應該是關於爲什麼而不是如何或什麼。
當然!!
主要原因是新手開發者。並不是每個人都知道如何編寫識字代碼。實際上有數百萬人在看到一個沒有得到NullPointerException異常。
我們都在某個時候開始。
但是，如果您只針對「專家」開發人員，那麼爲什麼還要首先在語言中煩惱。你應該是using butterflies !!!這就是真正的開發人員使用！
評論是必須的，如果你想（如使用＃// ##/sequence創建註釋或類似的東西）但不要忽略它，儘量讓它更難。
:)
不 - 沒有一種編程語言需要註釋。
該語言適用於計算機。評論是針對人類的。你可以寫一個有0％評論的程序。它會執行，無論是對還是錯。您無法撰寫100％評論的程序。它不是編譯 - 不是main（）等 - 或者對於腳本語言，什麼都不做。
另外，還有real programmers don't comment their code。就像克林貢一樣。
反對意見的一點是，他們傾向於經常與代碼過時。無論何時添加冗餘，您都會冒這種不一致的風險。
實際上，當一個小組使用NLP分析某些大型系統中的鎖定註釋，然後將它們與靜態分析的結果進行比較並能夠修復一些錯誤時，我已經看到了一些有趣的研究。
呃，在測試過程中無法快速地註釋掉一行（或多行）聽起來令人厭煩，尤其是在腳本編寫時。
是否需要編程語言的註釋？
不可以。在事物的宏觀方案中，編譯器不會在乎某個註釋，只是希望代碼研究到一個較低的公分母。
編程語言提供註釋構造有用嗎？
是的。評論對於程序員來說非常有用，而不僅僅是假裝他們知道他們在做什麼，而且在調試和有用的文檔編制方面也是如此。
雖然我同意Uri的迴應，但我也沒有提出任何意見。 （ichbins）。語言應儘可能簡單，同時仍能夠清晰地表達自己的編譯器;因爲你可以在沒有評論的情況下做到這一點，他們被拋棄了。
我正在開發一個支持評論的修訂版本，但有點不同：文字編程風格，代碼中嵌入代碼而不是嵌入代碼中的註釋。它也可能在稍後作爲一流的語言功能獲得示例/測試用例。
祝你好運克林貢黑客。 :-)
是不是文字編程儘可能多的評論，因爲它是代碼？當然，我所見過的文學編程的很多內容都與代碼一樣多，但如果沒有更多的評論。
我同意你的觀點，很好的書面代碼並不需要任何評論，因爲「代碼只是程序員可用的良好文檔，但這是非常理想的條件，並非所有人都能一次寫好代碼 因此，在未來的評論好需要
我不能告訴你我是多麼感激的Javadoc - 。這是非常簡單的註釋中設立所以這是至少一個意義上的意見是有用的
我曾經寫過一個VB應用程序（一個愚蠢的棋盤遊戲，受到大富翁的啓發），沒有任何評論。但我只是爲了pis我的老師告訴我們評論的是「我們發現相關的，所以我們可以記住它」。
不，當然一種語言不必評論。但一個（有用的）程序必須有評論......我不同意你的觀點，即識字代碼缺乏評論。一些非常好的代碼很容易理解評論，但只有在沒有評論的情況下才能理解。
儘管所有源代碼默認都受版權保護。它往往是不錯的：
提醒人閱讀源代碼，這是受版權保護
告訴人們的許可條款是什麼，該源代碼文件
告訴他們不管他們是否正在尋找受保護的商業機密
不幸的是，沒有評論，很難做到這一點。
您不需要需要您的代碼中有一個斷言，因爲在發佈模式下，它們全都不見了。但是，當C++沒有內置斷言時，有人編寫assert宏來替換它。
當然，您不需要需要註釋，或多或少有相同的原因。但是，如果你設計的語言沒有評論，人們會開始做這樣的事情：
HelperFunctionDoesNothing("This is a comment! Blah Blah Blah...");
我很好奇。你如何阻止某人聲明一個包含註釋的靜態字符串，然後忽略其餘func/method/procedure/battle /什麼的變量？
var useless_comment = "Can we destroy our enemies?"
if (phasers on full) return Qapla'
我覺得在很多情況下都需要註釋。
例如，算法的思考。假設有一個用C編寫的函數來解決Traveling Salesperson Problem，有很多技術可以用來解決這個問題。這些代碼的性質通常是神祕的。
沒有明確描述參數和使用的算法，通過使用註釋，幾乎不可能重用這段代碼。
我是唯一一個註釋掉幾行代碼出於多種目的嗎？
完美的代碼需要零評論。它應該是簡單的，完全新手可以理解。
任何代碼都需要註釋，我試着解釋我在1或2行寫入的每個函數的原因和工作原理。
解釋自身的代碼只存在於完美的世界中，總會有一些奇怪的黑客或者做一些事情的原因，而不是普通的方式。 要記住的最好的事情是評論爲什麼代碼做它做的事情，好的代碼解釋了它在99％的時間內做了什麼。
寫一些簡單的東西，比如一段可以解決數獨謎題的代碼（3個合理簡單的while循環），並嘗試在3個月後閱讀。你會立即發現一些不完全清楚的東西。
我們可以沒有對代碼的評論生活嗎？當然，但這不會讓生活更輕鬆。
代碼只寫一次，但在其生命週期內讀取多次;因此它爲優化可讀性而付出代價。從常量到類別的所有內容的清晰和一致的命名是必要的，但可能或可能不足以實現此目標。如果沒有，請填寫留言和留言，並按照代碼進行維護。
評論非常有用，因爲他們可以保證閱讀您的代碼的人 - 可能是您的「未來」 - 您已經考慮過她的福利。
這將比你想象的更難做一個評論是不可能的語言。
if (false) {
print("This is a comment. Chew on that, Klingons!")
}
有時我的英語需要評論。我想我不是克林貢。 – 2008-12-24 05:51:43
這應該是關閉的 – Foredecker 2008-12-24 06:08:03
你爲什麼說它應該關閉？似乎完全是與我有關的程序設計，似乎不太可能是現有問題的重複。 – 2008-12-24 06:28:52