在某些情況下，最好使用實碼，而最好使用偽代碼。您不應該依賴簡單的固定規則，而應根據對情況的適當判斷。

需要考慮的一些事情：

編程語言來來往往。在60年代，Fortran被認為是一種非常好的可讀性編程語言，比Assembly更容易閱讀。但是，如果您使用Fortran代碼示例而非peudocode撰寫了一篇文章，那麼現在對我們來說將更難閱讀。現在，Python對我們來說看起來不錯，但是將來看起來仍然很好嗎？如果我向您提供了一段包含以下代碼的Python代碼：

  a = 3/2  

的值是什麼一個？是1還是1.5？因為Python 2和3處理整數除法的方式不同。現在，我或多或少地使用了Python 3進行本機編程，因此實際上我必須查找Python 2和3中的除法運算中的哪些是不同的，哪些沒有。只是為了向您展示，在紙張中使用真實代碼可能會降低紙張的保質期。

偽代碼可讓您將內容抽像出來 / p>

 沒有達到停止標準DO（東西） 

然後在您的論文的後面，您可以為算法考慮不同的可能停止標準。您也可以使用實際的Python代碼來執行此操作，但結果基本上是您在扭曲Python代碼以執行偽代碼本質上的功能。

您可以在偽代碼中相當標準化地只需使用LaTeX的各種算法排版選項即可。

您可以在偽代碼中使用數學符號。使用數學集符號比依賴所有讀者更為通用了解Python設置操作。考慮：

  a = set（[1、2、3]）b = set（[1、2]）c = 1，如果b.issubset（a）否則為0  

與

  A←{1，2，3} B←{1，2} C = 1，如果B⊆A 0否則 

不熟悉Python的人第一個例子會令人疑惑：[1、2、3]是...還是列表？好吧，列表[1、2、3]與列表[1、2]不同，因此集合A和集合B包含不同的元素，因此B不能是A的子集。

算法與實現假設在2019年，您將使用一些最新的庫在Python 3中編寫一個有趣的算法。在2025年，我針對Go中的相同問題提出了另一種算法，希望通過比較性能來證明您的算法更好。為了獲得公平的比較，我將不得不在Go中實現我的算法，或者在Python中實現您的算法。假設那時沒有人將Python用於高性能的東西了，因為Go可以做得更好。 （可能不知道，我不知道。）現在，我必須研究您使用的已有七年曆史的庫，以確切地找到所使用的功能以及與它們等效的Go功能。那很難。因此，很可能我對您的算法執行的Go實現不會那麼好。大驚喜！我的算法基準測試比您更好！

現在，如果您使用了算法的與實現無關的描述，那麼對於您的出版物來說可能會更好。

因此使用真實代碼的兩個主要弊端是：它限制了出版物的保質期，並且受眾較少。

那麼應該何時使用真實代碼？

• 當您的論文的主題不是算法，而是實現或編程語言時。也許您正試圖證明Python是解決問題X的一種非常好的語言，因為有了Y和Z庫，您將獲得一種簡單而有效的實現。

• 絕對建議您也將您的真實代碼作為附錄發布，或者更好的是，在人們可以下載您的代碼並提出改進建議的存儲庫中發布。一個非平凡的算法可能太大了，無法通過手動打字或什至從紙張上粘貼粘貼來進行複制。一旦開始使用新的深度學習算法之類的東西，您可能正在查看多個文件甚至嵌套的程序包。

在研究中，我經常編寫算法，其中可能包含如下語句：

• 以相對準確度 A 的顯性子空間>Ɛ。
• 找到該方程式/不等式系統的非負解。
• 將這些特徵值按模數從大到小排序，丟棄小的特徵值並重新排列特徵向量

對於使用數值線性代數的任何人，無論他們喜歡哪種編程語言，這些指令都非常簡單明了。我認為沒有理由在本文中使用特定的編程語言，並且沒有限制讀者人數的風險。我相信自然語言的閱讀和理解速度更快。特別是，它使我可以清楚地談論每個步驟的目的，而不是如何實現。通常有不止一種方法，例如“求解線性系統”，使用偽代碼可以區分“以某種方式求解”和“使用此特定算法求解”。因此，我使用偽代碼使我可以更好地表達這種細微差別。

我總是在開放存儲庫中的論文旁邊提供實際代碼，讀者可以克隆和瀏覽它們，從而省去了重新輸入代碼的麻煩pdf /印刷版代碼中的代碼。

偽代碼永遠存在；真實的語言一直在變化。

如果您在兩天內用Python在Python中發布了算法的論文，那麼很有可能您編寫的“可執行”代碼會如果人們在最新版本下運行它將無法正常運行，即使在不太戲劇性的情況下，新庫和算法的進步也可能會使讀者對您的過時選擇感到困惑。想像一下40年前的論文是否使用了當今的語言。您了解一些Fortran或Pascal代碼的微妙之處嗎？然後，程序員就您對Python的可理解性提出了相同的主張。

因此偽代碼更好，因為在一百年內同樣可以清晰地表達關鍵思想。

偽代碼比真實語言更好地表達了代碼的意圖

為了編寫工作代碼，我幾乎必須總是執行一些步驟才能使程序正常工作不需要進行設置，格式化或進行任何其他操作，這些步驟可以用偽代碼忽略或簡化以傳達重要信息。

此外，在真實語言中，我必須決定數據的存儲方式，採用哪種算法進行排序等，這些都是本文討論的算法附帶的。通過在算法描述中包括這些偶然的選擇，您可以指導實施者做出可能不是最佳的選擇，或者是因為現在可以使用更好的選擇，或者因為您做出的選擇不適合其目標環境。

您聽到的論點可能都是正確的。我曾經是許多計算機科學文章的審稿人和作者，我想以自己的方式和自己的方式回答這個問題。

偽代碼較短。給定像Clojure或Python這樣的現代語言，實際代碼通常不會更長。即使是這樣，（電子）紙也很便宜。

偽代碼很短而且很容易理解。與整個代碼相比，偽代碼有助於非常清晰地解碼想法。我不會花幾個小時來理解您的代碼。例如，要根據第三列對CSV文件進行排序，您可能已經寫了3行，我並不在乎。我只需要了解該文件必須進行排序即可。其次，如果我不喜歡編寫代碼的語言該怎麼辦。這種審查和興趣可能會有很大的偏差。

並非所有人都可以使用Python進行編碼。的確，但編寫得當的Python代碼並不比偽代碼難讀。另外，Python是標準化的，而不是某人的個人偽代碼。

這只是Python社區適合所有人的主張。許多其他語言也是如此：Matlab腳本，R腳本，Java腳本；有些人（例如我自己）也喜歡UNIX Shell腳本。

在CS中，我們專注於算法，而不是實現。是的，但也顯示了實現並不能脫離這一重點。

我同意這一點。但是，查看整個代碼沒有任何意義。閱讀第一點。

相對於另一種語言，它偏愛一種語言。是的，但這是我作為作者所擁有的權利，不是嗎？

您應該了解您是在為“除您之外的世界”撰寫論文。因此，您不在目標讀者群中。您應該寫一些讀者不會討厭的東西。

看起來很業餘。這是主觀的。

確實。

判決： 您始終可以在論文中提供完整的代碼（如在附錄或補充材料中）。但是，您必須在主要論文中給出算法/偽代碼。

我現在喜歡當前的三個最佳答案（@ObscureOwl和@DmitrySavostyanov和@JackAidley）。但是我覺得沒有一個選項無法代表。

您可以同時提供偽代碼和實代碼。

• 最有可能是真實代碼，代碼太長而無法在論文中在線提供。
• 因此您將在論文中提供偽代碼。
• 然後將真實代碼作為附錄或補充-download或URL。

同時提供這兩個功能可為您提供AND和AND的所有好處。

• 您將擁有偽代碼的所有好處。
• 您擁有實代碼的所有優點。
• 因此，您的讀者可以通過閱讀偽代碼和理解意圖來更輕鬆地理解您的論文，然後，如果他們非常認真，他們可以
• 該代碼更容易理解，因為它們已經具有解釋底層實現的偽代碼。

最後提供了兩者都確保長期的理解（偽代碼不會過時）和短期/中期的研究成果

• 更多的短期採用/使用/複製意味著更長期的對他人的影響和更多的長期使用。

示例1

https://academia.stackexchange.com/a/140990/349是一個很好的示例，其中的偽代碼是更具可讀性/可理解性/意圖-很明顯...在代碼中實現此操作將花費很多代碼行，並且可能很快變得醜陋並佔用紙張過多的空間...因此您肯定希望使用偽代碼，代碼...但是如果您是認真的並且想使用本文...擁有真實代碼將為我節省很多時間...在某些情況下，可以節省許多小時/幾週/幾天/幾月的重新創建偽代碼。 / p>

示例＃2

這是另一個例子。 http://www.fftw.org/fftw-paper-ieee.pdf FFTW算法用於計算傅立葉變換。本文討論了算法，但實現也非常重要。因此，本文主要提供了偽代碼和少量代碼。而且，如果您需要來源，可以作為補充下載獲得。

根據我作為作者和讀者的經驗，在可能的情況下，最好使用真實代碼而不是偽代碼。當我使用真實代碼而不是偽代碼時，從來沒有出現審閱者投訴。

此外，真實代碼的優勢不僅在於讀者可以自己運行它，而且還因為 author 可以運行它，並確保它們的演示文稿中沒有錯誤。

但是，要使真正的可執行代碼作為一種算法很好地呈現，通常仍然很困難：

p>

• 正確的可執行代碼不一定可理解。需要仔細清理，註釋和安排。
• 如果本文包含分析，則代碼變量需要與分析變量匹配，這對於更複雜的數學符號（“ x_hat_sub_i_prime”）可能會產生問題/ li>
• 行長通常需要短得多才能適合紙質列，這會增加重新格式化的格式，並且常常很醜陋。
• 通常有“無趣的”但必要的代碼部分，例如打包
• 代碼經常與依賴項，環境和上下文糾纏在一起。
• 某些語言似乎天生就是“羅word的”，很難用這些語言編寫緊湊的清單

考慮到所有這些，我認為許多作者可能會發現，將一些虛假的偽代碼組合在一起比較容易，而不是試圖使真實代碼既可呈現又可正確。

偽代碼使您可以專注於算法的重要部分並總結其餘部分。

實際代碼通常從加載一些庫開始，讀取一些數據，然後按照所需的方式對其進行格式化/重新排列，而在偽代碼中則不需要。

您的算法可能包含多個單獨的步驟，其中一些步驟是標準的，易於理解且令人厭煩的，其他步驟則是本文的關鍵創新。在偽代碼中，無聊的位只是描述需要發生的事情的一線。多汁的位會根據需要進行詳細說明。在真實代碼中，某些標準細節將比實際重要的部分更長。

因此，總而言之，在偽代碼中，讀者可以輕鬆地看到代碼中重要部分的位置，而在真實代碼中，這是更難（不是不可能，只是更難）。

我想說這是更常規的做法，因為這似乎與字段密切相關。在“組合”離散算法論文中，我幾乎從未見過真正的代碼。好吧，一個明顯的例外是Don Knuth的TAoCP，但不是每個人都是Don Knuth，對嗎？ 。許多研究實際上都是依賴於語言的，因此不足為奇，但是即使是與語言無關的工作（例如，純功能數據結構）也通常使用諸如標準ML或Haskell之類的真實功能編程語言來呈現。有時這確實會造成一些混亂，但是由於函數式編程作為一個領域（儘管可以說仍然大部分是TCS的一部分）是完全面向實現和編程的，所以大多數人實際上是想看真正的程序。 p>

因此，IMO這實際上比任何事情都更加慣例，這實際上取決於領域。大多數組合主義者都在很大程度上關注算法本身以及算法的複雜性，但是功能程序員（或者也許是“邏輯學家”）非常在意算法是否可以正確，優雅地實現，因此存在差異。

不必有明確的區別。

偽代碼最重要的部分是，應該清晰易讀。因此，您不想處理不屬於實際算法的結構，也不想處理語法結構，這些結構在編程語言中很有用，但在您不了解編程語言時不容易理解。

這是偽代碼還是真實代碼？

 如果a == b：a = a％b  

這是有效的python代碼。但這也是一些可讀的偽代碼。

那該怎麼辦？

 在範圍（10）中的i：print（i） 

我會說這不是（好的）偽代碼，因為 for 的構造並不明顯。

您也許可以為我獲取 部分，但是 range（10）的作用是什麼？即使 range（0，10）也不是很清楚，因為 10 不在範圍之內並不明顯。
此外，您需要保持請記住，數學和計算機科學通常在以0或1開頭的索引上有所不同。

所以我想說這要清楚得多，但是沒有有效的代碼：

  for i = 0 .. 9：print（i） 

還有其他表達for循環意圖的方法，這些方法相似且清晰易讀。在這裡，您可以嘗試使用C語法 for（int i = 0; i < 10; i ++），甚至可以省略 int 。

  int i = 0; i：= i + 1返回i;  

而是使用

  //輸入：// i：應該增加的整數//算法：o：= i + 1 //輸出：// o：增加1的整數 

請注意，我避免重複使用 i 來存儲結果，而是使用了僅用於存儲輸出的變量 o 。這也可以省略 return 語句，因此讀者無需考慮返回的內容以及返回的位置與算法無關。

與開頭的示例形成對比，我使用了：= 進行賦值，從而更加明顯地表明這是一種賦值運算，沒有數學方程式。您對乾淨的偽代碼有很多看法。如果不確定，您可能希望緊貼LaTeX中的不同偽代碼包，並以類似於其文檔中示例的方式使用它們。

曾經有一段時間偽代碼是明確的選擇，因為編程語言是如此粗糙。 60年代和70年代，但要晚一些-安全地假設一種語言是普遍使用的語言需要時間，而那時，不使用偽代碼只是覺得很奇怪。我記得偽代碼包括“空中”結構，例如：“ foreach”，for循環，完全循環（與帶有反向GOTO的IF相對），2D數組（如果帶有else的函數，帶有參數的函數，變量）名稱超過2個字母，即工作字符串庫。從本質上講，偽代碼是一種更好的高級語言。

一些學者編寫的代碼不那麼多，並且可能擁有與我相同的記憶，其中“將這種偽代碼轉換為FORTRAN程序”不是一個好主意。 -瑣碎的任務。就我而言，我記得在2010年左右（老習慣）寫出偽代碼，意識到使用99％的代碼可以使用C ++，而偽代碼已不再是一回事。您只是在用自己喜歡的編程語言進行思考和編寫，這裡到那裡都有一些快捷方式。

是否發布可運行代碼而不是偽代碼？

我不知道，但這可能取決於相應領域的特定亞文化。

在計算機科學中，使用偽代碼而不是真實代碼來描述算法是更好的選擇嗎？

是（請參閱歐文的答案），有時仍然可以（請參閱下面的注意事項）。

如果是這樣，為什麼？

[...]

那麼偽的參數是什麼？代碼嗎？

許多其他答案都已經說明：除了天真的可運行代碼外，偽代碼旨在易於 易於閱讀和理解，而又不會對讀者造成不重要的影響（針對呈現的方面）詳細信息。 而且通常可以成功實現這些目標。

正如您自己所言，可運行代碼也有其好處。因此，讓我迴避這個問題，聲稱

只需付出一些努力，您就可以同時受益於

（並且無需實際提供偽代碼和 separate 可運行代碼，如 syn1kk建議。）

論文中的理想代碼（如果可行，在其他地方）是 pseudo -pseudo code：該代碼具有偽代碼的所有積極特性，但恰好是可運行的（並且實際上可以執行看上去應有的功能）。

我堅信所有編寫得很好的可運行代碼代碼與偽代碼沒有區別：如果有人能說某些（實際上可運行的）代碼不是偽代碼，因為它不像偽代碼那樣易讀易懂，那麼該可運行代碼的結構就不好

如何獲取偽偽代碼

如何實現與偽代碼一樣易於閱讀的可運行代碼？

要考慮多個方面，實現所有這些方面可能並不總是容易或可行的，有時甚至是不可能的。 （這可能是使用實際的非可運行偽代碼而不是可運行偽偽代碼的正當理由。）

選擇正確的語言

哪種語言最合適取決於幾種事情：

• 問題領域
• 您的解決方案
• 您的聽眾
• 語言為（重新）提供的可能性構建代碼

請注意，對於這些組合的一些，不編程語言可能（甚至有時甚至是不存在）允許您編寫足夠好的代碼。出於明顯的實際原因，您還必須考慮各種語言的命令（應用技巧）。

使代碼非常簡潔：重構，重構，重構

如果有實現細節使您正在描述的算法的核心思想模糊不清，請提取它們（例如提取為常量，變量，方法或函數），以便您可以通過以下方式替換它們的“方式”（其實現）：他們的“什麼”（新提取的代碼名稱）。如果合適，請選擇不在書面代碼摘錄中顯示提取的實現或分配。在命名提取的內容時要格外小心，以使它們的目的（不一定是它們的實現）從它們的名稱和調用簽名來看非常清楚。

另一方面，如果算法之間過於分散為了易於理解代碼的不同部分，您可能不得不選擇內聯代碼。

所有這些都旨在將每個代碼單元（例如函數）的抽像水平設為單一級別，或者至少將正確的抽象級別呈現為最佳，以最好地展示和解釋該算法。儘管只能謹慎地使用一些與之相關的單一責任原則：過度應用該原則（或將“單一責任”解釋得過於狹窄）可能會分散並混淆您的算法。請注意，在這方面，論文中要呈現的代碼的正確平衡與（待維護的）軟件產品中代碼的正確平衡很可能會有所不同。

進行了充分的優化編譯器或解釋器，這些重構都不會對性能產生不利影響。但是，當重點是提出一種算法而不是在生產系統中實現該算法時，無論如何這都不應該太在意。

使您的代碼易於理解

對偽偽代碼的正確解釋不應依賴於了解所選的編程語言或其版本，變體或方言。因此，請警惕您使用的語言功能。

許多編程語言（聽眾都知道）共有的每種語言功能，並且所選語言具有與許多其他編程語言相似的語法，除非所選的編程語言對其具有不尋常且非顯而易見的語義，否則它也是偽代碼方言的特徵，因此可以在偽偽代碼中使用。如果其語義從語法和關鍵字及其與自然語言的關係足夠明顯，那麼即使是不太常見或特定於語言的功能，也可以使用語法不太常見的功能。

最好省略非顯而易見的語言功能，但可以與代碼註釋或論文的散文中的解釋結合使用。 （就像適用於所選偽代碼方言的非顯而易見特徵一樣。）

針對特定語言的習慣用法也是如此：避免或解釋它們，如果您不得不期望它們對聽眾不明顯。

替代方法：使偽代碼可運行

以上兩節假定您從可運行的代碼開始。當然，您也可以從偽代碼開始，然後將其修改為可以使用合適的編程語言實際運行（並希望做看起來似乎可以做的事情）。但是請注意，您最終可能會以這種方式獲得針對目標語言的非常慣用的代碼，而這可能並不是您想要的。當然，重構通常可以解決該問題。

解釋您的代碼

就像您必須解釋（在散文，代碼註釋或標註中）代碼的某些方面（如果是）

偽偽代碼的優點

• 像偽代碼一樣可讀易懂

  li>

• 如果指定了使用的語言（包括版本，變體或方言，如果適用）：
  • 它是可運行且可用的
  • 它可通過手動和自動方式進行測試測試
  • 它是可配置的

其中一些優點使您作為作者受益，例如，您可以確保提出的算法實際上是正確的。其他使您可能希望評估您的算法的聽眾受益

這些好處是否值得實現偽偽代碼所需的大量工作，而僅僅是偽代碼，或者編寫得不夠好的可運行性代碼，由您決定。

哦，別忘了道德上的好處：由於“熟練”，無論“看起來是否業餘”，您都可以確信它不是和艱苦的工作。

在60年代後期，CACM要求文章中的算法應使用Algol編寫。當人們發現人們正在提交使用其他語言開發的算法並且未在Algol中進行測試時，他們放棄了該要求（因為他們碰巧沒有在其站點上安裝Algol編譯器。）這種行為的結果是，幾乎沒有已發布的算法是可編譯的，並且其中許多包含由於作者對Algol語義的誤解而導致的實質性錯誤。

我認為CACM編輯器在設置要求時就意識到了編譯器的情況，但希望存在一個明確的定義。

無論如何，該示例顯示：*即使有描述它的大型標准文檔，偽代碼也很難編寫*質量控制更易於使用可執行代碼。

我這樣說並不是無視任何人的意思，但是許多學者並不熱衷於程序員-他們不喜歡編程，也不關心細節。編程不是他們簽約的目的，也不是他們工作的重點。他們可能將代碼視為“必要的邪惡”，而不是其貢獻或欣賞其設計。該代碼被認為是不重要且低級的。當然，這都是主觀的：我可能只佔少數，但是我個人發現Java代碼比UML圖更易於理解。

在我看來，整個討論都是關於語法的。有一個原因，您可以復制粘貼Python代碼，而沒人會蒙上眼睛（提示：即使是業餘愛好者也廣為人知），而您不能使用學習曲線更陡峭，更細微差別的語言。碰巧的是，當人們看到他們不喜歡的代碼（或者更可能是無法理解，可能部分是由於不熟悉語法）時，他們可能會錯過很大一部分貢獻。

偽代碼是為需要簡單構造IMO的過程算法而設計的。有時，根據您所演示的內容，編寫可執行代碼可能更具表現力。而且，這意味著您不必發明自己的語法，因為大多數偽代碼“標準”僅具有基本的命令性構造。