是的，應該。

首先，大多數科學軟件都非常糟糕。如果您的性能差於平均水平，我會感到非常驚訝：僅您知道設計模式以及遞歸和循環之間的差異就表明它更好。

第二，您不太可能擁有激勵或動機除非或直到其他人（或您在6個月內）需要它，否則它才能變得更好。

潛在的好處：可能的新合作者，錯誤修復，擴展，出版物。

潛在的缺點：時間浪費（為他人維護代碼或解決問題），被挖出來。我會很清楚：我不會非常認真地對待這些缺點中的任何一個。

我會整理一下並分享。這些年來，我已經發布了很多代碼，並且出於您給出的原因也沒有發布代碼。

仔細研究並註釋它，並以任何級別進行。保留“失敗的嘗試”，並對其進行評論。說出他們為什麼失敗，以及您嘗試了什麼。這對跟隨您的人來說是非常有用的信息。

製作一個自述文件，要求您將其發布，以希望對您有所幫助。假設您知道代碼很醜陋，但還是希望它有用。

因為它不是完美的，所以有太多人阻止了事情！

是的！特別是如果您的紙張是關於您已經實施的新算法/改進算法，或者進行了重要的非標準數據分析，或者基本上所有復制結果都意味著重新實現軟件的事情。

紙張很少有空間提供更多功能比大綱。我知道我花了很多時間來嘗試從那些遺漏了關鍵（但與論文並不嚴格相關）細節的論文中實施算法。

？您認為您的代碼混亂嗎？我已經看到（並嘗試使用）令我惡夢的代碼：

• 嵌套了五層 if True ，通過代碼分散在任意位置。
  • li>
  • 創建一個零數組，將其轉換為度，取餘弦，然後返回弧度。然後，扔掉結果。
  • 在正在大量開發的軟件上，“受支持的體系結構”列表非常古老（而且他們確實說了自己），很難使用這些計算機之一。
  • 功能已在多個版本中被破壞或修改，但仍在文檔中推薦。
  • 代碼從使用標準格式輸入變為自己的某種格式。如何產生呢？沒人真正知道，開發人員會做出回應。
  • 發布甚至無法編譯的版本。 （您甚至測試過嗎？）
  • 必須按特定順序訪問的GUI菜單。否則，您將遇到分段錯誤，並且必須從頭開始。
  • 通過代碼分散的硬編碼路徑。因此，您必須遍歷幾個文件來查找並將所有 / home / someguy / absurd_project / working / 的出現更改為您自己的。

  而且，我個人最喜歡，這是一個包含數千行代碼的特定程序，僅使用註釋消除了隨機的代碼位，除了以下內容：

  在這裡我們打卡。

  仍然，不知道它在做什麼。

  這只是在經典的良好實踐知識之外，例如整個代碼中的一個字母變量，未在任何地方指定的算法...

  如果您擔心代碼的質量，則可能意味著您已經足夠在意它的質量，使其優於平均水平。如果您等到代碼乾淨之前，它可能永遠不會消失，您的科學貢獻將被部分損失。

  我認為，您應該依次關注的重要事項是：

  1. 輸入和輸出格式。使用可用的標準，不使用時簡化。簡化將程序用作黑盒的操作。
  2. 評論。功能的簡要說明，算法的快速概述。
  3. 可信度。使用慣用的代碼，好的變量名...
  4. 結構。當您知道要做什麼時，這會更容易，而在研究代碼中通常不是這種情況。只有在社區中有興趣時，您才可以考慮對其進行重構。
  ol>

  因此，只要有1個，就發佈軟件（編寫時應同時包含2個和3個部分） 。

您要問的是，共享低質量的軟件是否會給您留下不好的印象。我認為共享軟件絕對會給人留下很好的印象。

1. 作為計算機科學家，我喜歡同事公開源代碼。這使我更有可能更深入地研究他們的作品，也許與他們聯繫，甚至引用他們，因為還有更多的工件可以與之交互（不僅是論文，而且還有代碼）。

2. 當一篇論文報告的結果得到了源代碼“證明”但源代碼不是公開的時，我常常想知道結果是否真實。查看源代碼（或者只是源代碼的可用性，而不用看它）可以說服我。

ol>

因此，共享您的源代碼，無論是否可怕，

現在，如果您想給人留下深刻的印象，它將對您有幫助或幫助...

...

...，如果您的代碼包含一個自述文件，該文件將您的論文聲明與來源聯繫起來，那麼在github之類的網站上發出請求時，即當我看到其他人試圖與您聯繫並且您做出反應時。碼。這樣，當我閱讀本文並想了解更多信息時，可以使用自述文件跳到代碼中的適當位置。這樣的自述文件中的典型短語可能是：“本文第3.2節中的算法在文件algorithm / newversion / related / secondtry / foo.c中”或“使用第2節中描述的小型數據集重複運行”在紙上運行“ make;第二步; foo_bar_2數據集/christmas.dataset。在我的筆記本電腦上運行大約需要2天。

您可能還對 http://matt.might.net/articles/crapl/上的Matthew Might的CRAPL（社區研究和學術編程許可證）感興趣。它包含以下術語：“您同意使作者免於程序中發現的任何駭人聽聞，尷尬或信仰飛躍的尷尬，尷尬或嘲笑。”對於我來說，尚不清楚此“許可證”是否具有法律效力，但其意圖很明確：釋放您的醜陋代碼，不要認為別人的醜陋代碼不好。

與您有切身關係，我將針對您的問題如何進行共享（而不是應該共享已經有答案的軟件）。

將失敗的嘗試有效地放入版本控制中意味著沒有人會看到它們。我處理此問題的方法是將每次嘗試都放入一個方法中，而每個失敗的嘗試都放在一個單獨的方法中：

  def main（）：get_foobar（x，y）def get_foobar（）：返回x ** ydef get_foobar_legacy_1（）：“”“此嘗試不適用於值> 100”“” return x + ydef get_foobar_legacy_2（）：“”“此嘗試在9月的星期三不起作用”“” return x-y  

根據下面的評論，可能是將這些方法放在單獨的FailedAttempts或BadIdeas類中是一個好主意。這具有很好的效果，可以根據實際需要對過程的各個階段進行劃分。我發現計算機程序員對於何時將邏輯分解為方法以及何時不將邏輯分解為方法常有訣竅，但是計算機科學家通常沒有。這種方法可幫助計算機科學家在必要時分解為一種方法。

當然您應該共享源代碼。

從學術上講，使用不易獲得的代碼的基於軟件的結果不是很有價值，因為如果需要，其他人將如何驗證您的主張？您是否希望它們為此目的而自己編程？僅共享二進製文件的價值要低得多，並且經常會給試圖運行它們的人們帶來噩夢。

我認為您應該分享它。首先，您應該進行一些基本清理。 （例如：不再使用不再使用的早期代碼；註釋中沒有代碼；註釋的有效方式等）此外，如果您在代碼中添加了“要做的事情”，其他人會發現您已經沒時間了，他們可以看到你的意圖（例如：todo：應更改為枚舉）我也認為您應該共享算法中最重要的部分。當我共享代碼時，我從未共享過不重要的部分。每個人都可以處理文件的讀/寫，線程之間的通信，GUI等。但是不要共享不可讀的代碼。這是沒有道理的。因此，我認為中間方法是最好的方法。 :-)

與您的計算機科學系的一些教授交談。看看他們中是否有人正在尋找一個項目，學生可以清理混亂的代碼以使其更具表現力。

對於修改代碼的學生來說，這是一次很好的學習經歷。當程序員以結果為先的心態或僅以結果為心態進行編程時，會發生什麼？他們看到了第一手資料。他們還可以應用他們一直在學習的一些最佳實踐。知道其他專業人員已經對查看代碼感興趣，他們可能會被激勵做特別出色的工作。

一位教授甚至可能會參加競賽，屆時所有的學生團隊都會努力修改軟件，並與世界其他地區分享最好的結果。

如果他們的重構工作失敗了，那麼您將比從前落後。如果是這樣的話，免責聲明是一件很了不起的事情。只需共享代碼，但要添加一個警告：“這並不漂亮。當我寫這篇文章時，我試圖完成我的研究–我不認為它會超出我的計算機實驗室。但是，不客氣看看您是否真的願意。”

在其他答案中也提到了很多支持發布代碼的要點，我完全同意。因此，由於已經討論了發布代碼的基本要求，因此我想補充一個需要考慮的其他要點清單。這些問題中的許多實際上可能出現在所有學術軟件中，因此即使您無法回答“這不適用於 my 項目”。對於所有這些人，在發布您的代碼之前，您至少應該能夠回答“這是一個問題，但是我們可以通過...處理此問題”：

• 您可以發布代碼嗎？
  • 您可以保證只使用允許重新分發的代碼片段嗎？還是您可能使用了來自非開放源代碼的代碼您可以將其用於自己的內部軟件，但不允許發布？您能保證所有使用的代碼都可以在一個完整的程序包中發布嗎？許可證兼容性是一個不小的問題。
  • 您甚至可以可靠地找到答案嗎？您是否將編碼工作的任何部分外包了，還是從其他地方集成了未發布的代碼？例如，您是否在畢業論文期間對任何學生進行了監督或僱用了任何學生研究助手，他們的工作都是基於您的研究，因此他們的代碼已添加到您的代碼庫中？是否有任何同事向您的代碼庫貢獻代碼？他們從學生那裡得到了一些密碼嗎？所有這些參與人員是否都適當注意了許可問題（如果他們完全有知識對這些許可問題做出有根據的判斷）？甚至還可以確定代碼的哪些部分起源嗎？貢獻每個部分的人還知道嗎？他們甚至還在您的“聯繫範圍內”嗎？
  • 該代碼是否在工作時間內基於第三方資金開發？如果是這樣，資助合同條款是否允許發布代碼，或者它們是否包含必須與項目合作夥伴專有共享在資助項目內創建的軟件的任何要求？
• 您是否有足夠的資源（時間和其他資源）來花一些時間清理代碼及其註釋，但仍然有意義，但不會提供任何信息不能公開嗎？
  • 您對發表代碼的人有何評論？根據自己的資助，提供代碼的人員是否被正式允許從事各自的研究？ ？ （軟件開發人員非常清楚，團隊合作和組件的複用是軟件開發的核心方面。不幸的是，供資機構通常對此並不了解，並假設如果開發人員A由項目X資助，而開發人員B由項目Y資助， A專為X工作，B專為Y工作，並且在博客中透露，A僅花費了半個小時來完成某項最終在Y項目中的工作，這可能會導致嚴重的後果，例如收回部分資金。）
  • 發布的數據中的任何內容都不會洩露有關工作方式的特殊性的信息嗎？如果要在VCS中使用整個提交歷史記錄，這尤其重要公開（或者，實際上意味著永遠不要發布提交歷史），但在其他情況下也可能起作用。例如：是否在正式指定的工作時間之外（例如在周末）完成了對代碼的任何工作？工作時間是否表明您每天的工作時間超出了您所在國家/地區的法定上限？工作時間是否表明您沒有遵守法律規定的休息時間？工作時間是否浪費了分配給其他項目的人員做出的貢獻？工作時間是否提供任何理由使您不信任您對工作時間所做的其他陳述（例如，在項目成功報告中，需要將工作時間詳細分配給具有一定最大分配量的預定義工作包）？在您本不應該工作的情況下（例如在項目會議期間），有什麼東西能透露您的工作？
  • 有什麼能說明您在不應該工作的地方工作的信息（例如，在家中，當您的合同不允許您進行家庭辦公時，例如由於保險相關的並發症）嗎？代碼中是否有任何秘密信息，例如密碼，用戶帳戶名或不得公開的URL（因為服務器的佈局不適合少數用戶選擇，而不能處理大量用戶）誰獲得了個人用於測試設置的URL）？
• 該代碼是否可被其他任何人使用？
  • 代碼將運行，還是需要大量的配置工作？您可以花費精力解釋必要的配置嗎？
  • 代碼可以編譯嗎？您是否使用了任何非公開訪問的非官方修改或定制編譯器？如果是這樣，那麼代碼是否會增加您論文中作為偽代碼算法可能提供的內容？
  • 代碼是否需要任何外部資源？如果它可以訪問由於某種原因而無法與代碼一起發布的服務器，庫或數據集，它是否有用？至少可以提供這些資源的描述，或者它們的接口受某種NDA約束嗎？
  • 代碼是否對運行的系統進行了不可逆轉的更改？例如，它是否會自動更改任何系統配置（例如覆蓋系統搜索路徑）？它是否執行對硬件組件的任何低級別訪問，而這些訪問可能會導致某些星座（您在測試設置中內部避免使用）某些星座，從而永久損壞任何組件？您能可靠地警告用戶這種有害副作用的代碼嗎？

當然。您要在編寫優秀軟件方面變得更好的唯一方法是獲得反饋（所有類型）。如果您害怕反饋，那您將不會走得很遠。編寫優秀軟件的三個基本知識是實踐，實踐和實踐。相反，我認為沒有人會尊重您的學術素養。並期待與您合作。

您可以將其推送到 GitHub並嘗試維護一個項目，以防其他對您的項目感興趣的人輕鬆訪問您的代碼，也許他們可以幫助您改進代碼。

是的，你應該。畢竟，Linux內核源代碼是一團糟，並且並未阻止許多專業開發人員對其進行研究並為其提供補丁和添加。還請記住，Linux內核是運行世界上最快，功能最強大的超級計算機和大多數設備的操作系統的基礎。 Linux內核源代碼雜亂無章，從而受到了任何負面影響或損害。

沒人提到為什麼要共享代碼的原因是，您可能會發現有興趣與您合作的人，但願意花更多時間清理代碼並使之在不同的系統上工作，

很多人認為這種工作非常令人滿意，如果您的代碼對他們確實有用，他們可能會很樂意這樣做。無論如何，您可能會發現，從嘗試使用它但需要某種幫助的人那裡獲得反饋，是使您變得更易於維護/使用和理解的良好動力。

您絕對應該共享您的代碼。

要對內容進行排序，請對代碼的相同部分進行區域劃分，例如對嘗試失敗的區域進行劃分，並說明失敗的原因。另外，如果您使用Visual Studio開發，請從Extension Manager安裝“ CodeMaid”擴展並清理完整的解決方案。它將刪除空格並刪除未使用的引用，從而使大多數內容看起來更好。

如果您使用C＃開發，請與我共享您的代碼。我也可以幫助您解決問題：）

如果要共享，則不要共享。我知道這聽起來很棘手，但我認為如今“分享所有內容”的壓力太大了，人們會試圖讓您為不分享而感到內,，但實際上您沒有義務分享任何內容。

提出免責聲明，該代碼按“原樣”提供，沒有任何支持承諾，等等。然後共享該代碼。

案例研究：將孤立的點雲變成水密表面這是一個極為重要的實際問題，從機器人技術到計算機視覺，再到處理來自Microsoft Kinect等3D傳感器的數據，都得到了廣泛應用。解決這個問題。但是直到今天，每個人都還在使用它。為什麼？因為作者發布了代碼，並且此後將其合併到了許多流行的幾何處理庫中。現在該論文已被引用超過一千篇。

是的。您應該在CRAPL許可下發布代碼。目標是建立更美好的未來-糟糕的代碼將幫助人們做到這一點。需要注意的是，您應該記錄如何成功地很好地操作代碼，以使某人有足夠的機會重現任何已發布的結果。

並且不要擔心-我研究過的一點研究代碼由大約5年的一系列項目的編程能力的5位博士後開發。

全局變量列表（僅名稱）大約有4頁。

其中大約三分之一用於設置默認行為，以更改在給定時刻起作用的功能。另外20％是並行數據結構-意味著它們存儲的數據大致相同-因此，函數或多或少隨機地從數據結構中提取代碼。是。他們有時不同步。有時需要不同步。

大約有50個未記錄的版本，存儲在小組服務器的隨機部分中-每個版本至少滿足一個特定的目的-只有一名管理員保留了這些特定的目的。在他的頭上。人們為了給定的目的使用“錯誤的”版本比不使用它更為普遍。

使用難以置信的複雜遞歸過程（例如，編寫文件）是標準做法。認真地講-幾千行保存圖像結果。

哦，這是通過從未創建新變量來解決內存洩漏（實際上是一個看不見的數字）的殘酷嘗試。

哦，還有那個可愛的數據庫。由於（a）數據庫設計錯誤（b）數據輸入錯誤（在自動程序中），約有一半的數據不可用。從數據庫檢索文件的代碼長了幾百行邏輯...數據庫本身也很友好，可以包含許多相同數據的副本，而且表之間的鏈接斷開了。約束？否。我看到統計學家在被委託使用數據庫後的一個月內，就從沮喪，恐懼到哭泣，再到退出……

有大約0到1種方法可以操作軟件並檢索正確的結果。在任何給定的瞬間……

是的，有很多東西。

哦，為了確保不透明和不確定的操作，通過調用GUI進行了一系列計算具有相關回調的按鈕。

任何給定功能的大約90％確實可靠，與結果或結果調試無關，而是由插入的短期項目組成，然後再也沒有刪除。認真的說-我寫了一個功能完整的版本，實際上是它的大小的1/10。重要的部分是複制粘貼的插入函數，其中許多彼此不同。

而且，弗吉尼亞州沒有，沒有文檔。還是描述性的變量名。

哦，還有未記錄的，錯誤的，dll和相關的庫-使用不再存在的代碼生成。

全部用Matlab編寫。根據Matlab編碼慣例，假設大量使用eval將是您今天的重頭戲。

嚴重的是，您的代碼還不錯。

這就是說，如果您做了一些實際有用的事情，發布一個清理後的版本以供其他人使用和引用您的庫可能會促進職業發展。如果您剛剛做過某事，那麼複製就可能是您明智的選擇。