題:
在同行評審期間,我應該評論作者的凌亂代碼嗎?
reviewer
2018-08-29 03:30:24 UTC
view on stackexchange narkive permalink

我正在審查一篇純粹數學的論文。本文中的許多結果在很大程度上取決於計算機的計算,並且作者在文章中提供了指向用於大多數這些計算的Magma代碼的鏈接。但是,由於編寫方式凌亂,因此幾乎無法理解該代碼。例如,它不使用任何縮進,並且所有變量都被賦予了諸如“ aaa”或“ X”之類的名稱,這些名稱並未提供有關它們在程序中的用途的任何信息。

一方面,對這些計算所基於的數學進行了充分的解釋,從而可以在不使用作者代碼的情況下重現結果(這就是我最後要做的)。而且,本文僅包含指向代碼的鏈接,而不包含實際的代碼本身,因此我不確定代碼是否真正在審查範圍內。而且,難以閱讀的代碼在學術界似乎並不罕見,而且大多數人似乎並不介意。另一方面,我認為作者的少量工作(大概確實理解該代碼)會使該代碼對其他人更有用,只需將某些變量名替換為實際上傳達某種含義的名稱即可。

我的問題是,對我來說告訴作者他們的代碼不必要地難以理解並應該加以改進是否合理?

我不明白為什麼代碼內容使它與證明沒有任何區別:如果我引用的論文帶有證明對變量的命名不當或沒有解釋發生的情況,我將要求作者對其進行改進。
如果您最終編寫了自己的代碼版本,如果願意幫助他們,可以考慮將其發送給作者?IDK如果與作者“合作”到這樣的程度,將超出審閱者應該做的事情的範圍,但是從實際的角度來看,對我來說似乎是合理的。(我是自由軟件怪胎,而不是學者)。
關於代碼要記住的一件事是,這種樣式非常主觀。-我個人不喜歡LaTeX文件和bash腳本中的縮進。-我可以在Eclipse中使用Ctrl + I輕鬆將其添加到我的C ++代碼中並使用它。有什麼用嗎?有時是,其他時候是。-但是有意義的變量和函數名稱非常有用。如果您看到過舊的Fortran代碼,則將看到大量的描述性註釋,然後看到“奇蹟代碼”,該文獻未記錄/沒有得到很好的解釋...-但它可以工作。(並且可以跟踪各個變量。)
該網站上的相關問題:[我應該分享我的可怕軟件嗎?](https://academia.stackexchange.com/q/37370/529)
當您說您重現了他們的結果時,是否意味著您重新實現了他們的計算?
可能是該軟件是由其他工具自動生成的嗎?
@DetlevCM樣式是主觀的,是的,但是,如果您的代碼沒有縮進,很抱歉,但是您的代碼客觀上很爛。縮進的目的是使查看代碼各個部分(例如,塊,循環等)的範圍變得容易。沒有它,將使閱讀和解密變得更加困難。
您是否認為如果沒有代碼,就無法審查該論文,或者它是必不可少的一部分?我並不是說,如果您具有良好的理解和重新實現的能力,則不需要它,但是,如果您希望普通讀者能夠在沒有代碼的情況下使用本文。
@JimClay有趣的是,我經常發現縮進使代碼的可讀性更好。關於範圍:這就是括號的作用。
“大多數人似乎都不介意”-需要引用
“純”數學論文中的代碼如何特別相關?
該期刊是否有可以引用的代碼風格標準?否則,不僅是風格上的觀點還是其他?幾乎沒有理由拒絕論文
很難判斷代碼質量與您的評論之間的相關性,但是我的經驗是,編程代碼的易讀性通常是更深層問題的徵兆。這就像語法和英文拼寫很差:要么表明作者對這種語言不是很精通(在編程語言的情況下是危險的信號),要么表明思維混亂,或者對細節的關注不足。
@GitGud這種事情已經持續了數十年。例如,請參見[四色定理]的證明(https://en.wikipedia.org/wiki/Four_color_theorem)。
-1
十 答案:
aeismail
2018-08-29 03:43:43 UTC
view on stackexchange narkive permalink

如果作者提供了指向其代碼的鏈接作為參考,則可以提供評論,尤其是如果該文章是基於代碼的。

但是,我建議提出批評。建設性的:提供有關如何改進它的具體建議,而不僅僅是說它是“凌亂”或“草率”,需要“清理”。

難道這實際上不會成為經過改進的代碼的PR嗎?看起來這將減輕工作的負擔,以便向了解這意味著什麼的審閱者編寫好的代碼。因此,人們將繼續產生錯誤的代碼,並希望審閱者為他們修復它。聽起來像是錯誤的激勵機制。
@Hakaishin仍然可以選擇拒絕紙張。
@Hakaishin我不理解這個原因。aeismail不建議為作者清理代碼並發送請求請求,他只是建議提供可操作的反饋,而不僅僅是說代碼凌亂並且需要改進。如果我們以根本無法提供任何有用反饋的理由為理由,那麼我們可以擺脫同行評審,而只是在紙上做是/不是決定。
@Hakaishin否。建設性反饋並不意味著“為您修復代碼”。反饋可能像“更好地排列代碼塊”那樣簡單。關鍵是它應該是可行的。模糊的“修復它!”沒有人幫助。但是,是的,如果代碼是本文的重點,那麼對於審稿人來說,這是很公平的。
@aeismail對您的評論的附錄:就像您說的那樣,建設性批評並沒有為該人確定代碼。它只是指出具體的問題,並有選擇地解釋它們為什麼是問題,而不僅僅是說“這很糟糕,請解決”。最後那是沒有建設性的,因為沒有辦法知道_what_是不好的,並且您很可能再次犯同樣的“錯誤”,因為您不知道不這樣做。
Ben
2018-08-29 06:06:19 UTC
view on stackexchange narkive permalink

該代碼在審查範圍內,應該對此進行審查並針對其缺陷提供建設性的建議。現在,請記住,作者有責任讓他們的論點滿意,如果論點依賴於混亂不堪的計算機代碼,那麼您就不必為他們解決這個問題。在這種情況下,建設性建議可能僅限於解釋為什麼現在難以閱讀(即缺少縮進,變量名不清楚等),並且可以合理地提出修改和重新提交的建議。嘗試在描述為什麼現在難以閱讀的代碼時變得清晰而全面,因此可以預期以後的重新提交將完全由零開始。

在這些情況下,最好的做法是對待就像論文中的散文一樣。就像散文一樣,相對於編碼標準,計算機代碼也必須清晰易懂。如果它是混亂且難以理解的,則需要對其進行修改,直到清楚為止。當散文難以理解時,審稿人不會迴避拒絕論文,因此要求使計算機代碼具有可理解性是完全合理的。

如果手稿本身值得更積極的建議,那麼混亂的代碼可能不是進行重大修訂的正當理由。
如果它太凌亂而無法理解,並且論文中的論點依賴於此,那麼我想說,如果不進行更改,您將無法接受。在那種情況下,有什麼比修改然後重新提交更積極的呢?
在這種情況下,OP無需代碼即可驗證結果。這是灰色區域。我個人會提到這些問題,但是如果所有其他問題都得到解決,則決定權交給編輯。
einpoklum
2018-08-29 15:28:34 UTC
view on stackexchange narkive permalink

是的,您應該發表評論,甚至可能更多。

您自己說過:

論文中的很多結果在很大程度上取決於計算機計算。 / p>

那麼,用於計算的程序代碼因此是您正在檢查的工作的一部分。如果論文的文本難以閱讀,您是否會認為這是一個缺點?因此,從邏輯上講,代碼也是如此(即使范圍較小)。

此外,如果您對代碼不可讀,儘管數學聽起來不錯,但可能還是有錯誤下。最後,如果您不使用代碼就能知道結果應該是什麼,那為什麼還要使用代碼呢?

因此,如果您覺得混亂不排除要“解析”紙張,請對其進行評論(也許,如果相關的話,可以將其從“強接受”降級為“弱接受”,儘管這可能太苛刻了-取決於具體情況。)

如果您需要閱讀代碼以獲取非常好的結果,您只需不能,那是一個更嚴重的問題。但是在說出“需要修訂”之類的內容之前,請諮詢期刊編輯/程序委員會主席等。

注意:我是計算機科學家,所以我的回答可能有些偏頗。另一方面,我寫的是純理論論文,沒有代碼。 sub>

kingledion
2018-08-29 17:47:27 UTC
view on stackexchange narkive permalink

混亂的代碼會影響可重複性

您嘗試使用鏈接的代碼來再現其結果,但無法做到。儘管您暗示最終可以開發自己的代碼並複制結果,但我認為編寫得不好的代碼會影響可重複性。在計算機編程中,這可能更為重要,因為編程語言不一定具有很長的使用壽命。誰知道50年後岩漿或其他語言是否是常識。

從長遠來看,可重複性是科學工作中最重要的部分。證明只要做一個 a 都會導致 b ,這是可以由任何願意嘗試的人再次證實的事實,這是可以接受進一步科學結果的公理基礎。

如果可重複性很重要,那麼告訴他們清理代碼就沒有錯。坦白說,如果他們的代碼像您描述的那樣糟糕,聽起來作者可能會在幾年後難以理解自己的工作。在這種情況下,通過強迫他們學習一些有關編寫出色代碼的知識,您將對他們有幫助。

E.P.
2018-08-29 17:45:54 UTC
view on stackexchange narkive permalink

讓我簡要介紹一下現有答案中未出現的一個方面。

我的問題是,對我來說告訴作者他們的代碼不必要地難於合理嗎?理解並應加以改進?

,您應該對代碼進行評論,但不僅限於以下內容:說服作者自己-有興趣解決這些問題。

可讀代碼是易於重用的代碼。可重用代碼是使您可以輕鬆探索本文中介紹的數學的代碼。可探索的數學更有可能讓讀者找到有趣的擴展。有趣的擴展名會被發布,這些出版物會引用原始代碼-而且還會提供一些最有價值的引文。

使代碼具有可讀性和可重用性並不保證一定會發生這種情況。發布不可讀的代碼,您可能會在讀者面前擺出一個人為障礙,後者可能會或可能不會繼續根據您的工作進行進一步的研究,而如果有足夠的此類障礙,那麼該讀者就會轉向其他地方。使代碼具有可讀性是對時間的適度投資,從而大大提高了工作的可擴展性。

當然,這種障礙並不是代碼所獨有的:不清楚數字,糾結的結構,混亂的語法,缺失的引理以及其他各種問題也可能造成類似的障礙,而您作為審閱者的工作包括指出這些問題並幫助作者擺脫它們。代碼沒什麼不同-幫助他們進行改進!

ivanivan
2018-08-30 08:17:49 UTC
view on stackexchange narkive permalink

我現在不在學術界,也不是該級別文章/論文的審稿人(理工學院的兼職人員),但我確實對很多編程作業和奇特的技術文檔樣本進行了評分,並且我從事軟件開發以實際付費賬單。

如果論文依賴於所生成的代碼的輸出,那麼該代碼必須是可讀且可理解的-否則,該代碼可能無法執行作者認為的工作,並且其他人無法確認w / o自己重新實現。如果這樣的重新實現相對來說是微不足道的,那麼實際的代碼似乎並不重要,因此我會問為什麼在學術論文中會包含或引用基於規範易於實現的破損代碼。 p>

鑑於您能夠使用自己的算法實現代碼進行驗證,我認為情況並非如此,但應將其考慮在內。任何體面的IDE甚至高級文本編輯器都應該能夠自動設置代碼格式並進行項目範圍的搜索/替換(重構)。金達指出純粹的懶惰。...

*“任何體面的IDE甚至高級文本編輯器都應該能夠自動格式化代碼” *-相反,這意味著任何人都可以按照自己的意願格式化代碼。因此,缺乏格式不是問題。當然,這很懶,但這對讀者來說只是一個不便。
@NisargShah,,IDE無法為您的變量提供有意義的名稱。
Pierre de Buyl
2018-08-29 16:12:24 UTC
view on stackexchange narkive permalink

作者在文章中提供了鏈接 ,因此該代碼被視為參考或研究的一部分。無論如何,這都會引發問題:

  1. 代碼是否已存檔?歸檔代碼的實用方法包括 Zenodo figshare。主頁上的代碼與完全沒有代碼一樣好。
  2. 代碼是否有許可證?如果不是這樣,那麼它的狀態根本就不明顯。
  3. ol>

    作為審閱者,您應該決定做什麼。可能的操作包括:

    1. 不要對代碼發表評論。
    2. 對代碼發表評論,我稱之為最低要求:要求對代碼進行正確的歸檔和許可
    3. 取決於計算機程序在研究中的重要性,需要最小的可讀性,並且作者在程序上提供了一些測試(即,如果某些參數集允許,則程序可以提供已知的分析答案)。
    4. ol>

      關於檔案,您可以參考開放式研究軟件雜誌的社論信息。

鑑於指向Codeplex和Google代碼的鏈接已在相當一段時間前停止運行,因此“開放研究雜誌”似乎並不值得信賴。最後,需要為出版物付費,這又再次引起了人們對可信賴性的質疑,特別是考慮到過時的信息以及明顯依賴作者將代碼託管在其他地方……(Elsevier也有“付費出版”軟件)日記-但是他們將/提供與紙一起託管您的代碼的副本。)
與Elsevier相比,它們的出版費用很低,並且它們來自科學社會([軟件可持續發展研究所](https://software.ac.uk/),所以我不同意您的評估。(免責聲明:我與他們一起發布)。關於存儲庫列表,您是正確的,我會向他們提及。
325英鎊vs 500歐元差別不大。現在,他們可能有一個信譽良好的支持者,但是應該進行適當的溝通,並且他們應該使自己的資源保持最新。Google Code於2016年初關閉,而Codeplex於2017年12月關閉。(現在做更多的谷歌搜索,似乎Ubiquity Press通常是開放獲取文章的“公認發行商”-但是該期刊的介紹並不能完全激發人們的信心。)
Albert van der Horst
2018-08-31 18:31:41 UTC
view on stackexchange narkive permalink

我是一名軟件工程師,我想從這個角度回答這個問題。大多數代碼本身都不可讀。您需要註釋以記錄子例程調用的數據結構和規範。學者不是軟件工程師,我不希望他們在這方面做專業的工作。當然,這仍然是為了評論軟件的質量。如果不看實際的代碼,我不確定我是否會評論它是不可讀的,因為該文章(根據證詞,足以重現代碼)將被視為程序文檔的一部分。如果程序使用的短名稱與本文中使用的短名稱相同,那沒有問題。缺少縮進並不表示質量低下,而是許多級別。我建議您表達一種難以閱讀的感覺,但是您也不是任何代碼專家,並且可能需要一些軟件工程師來研究它。您知道這是另一種技能。

最重要的是:我在清理代碼方面做得很好,在目的級別上我還不了解。您會驚訝於不同領域的專家的能力。

最重要的是,代碼不是本質,代碼的質量是偶然的,並且不應該以任何方式影響您的決定。

akhmeteli
2018-08-31 11:17:09 UTC
view on stackexchange narkive permalink

我的理解是作者未提交代碼以供發布,因此該代碼似乎不受您的審查。作者只提供了指向其代碼的鏈接。這就引出一個問題:如果他們只是提供了他們在其他地方發表的作品的參考,您是否會考慮告訴他們 應該得到改善?有人可能會爭辯說,其結果的有效性取決於其代碼的正確性,但他們可以選擇根本不提供對代碼的訪問權限,因為“對這些計算基礎的數學進行了充分的解釋,從而有可能在不進行計算的情況下重現結果。使用作者的代碼”。您,作為審閱者,很難驗證其計算結果,因此超出了您的職責範圍,但這意味著它們的結果確實可重複。

所以我認為您可能會提到他們的代碼很糟糕(雖然顯然是正確的),但這不應影響您對發表/不發表論文的建議。

如果他們提供了一個* link *以便在其他地方工作,並且在該鏈接之後指向的頁面基本上是不可讀的,那麼向他們指出這一點將不是一個壞主意。
@RDFozz:這似乎與我回答的最後一段中的結論並不矛盾。
在閱讀問題時,我什麼也沒看到,這表明OP不會根據代碼的狀態建議不要發表論文(儘管也許我遺漏了一些東西)。我主要關注您答案的前兩句話,並試圖指出引用某種已出版作品之間的區別(這可能實際上需要獲得該作品的物理副本才能進行查看,並且大概是不允許簡單修訂的格式),以及指向網頁的鏈接(通常相對容易更改/改進)。
@RDFozz:可能存在一些實際差異,但是該代碼仍超出了審查範圍,並且作者可能出於各種原因而不接觸該代碼。
dusa
2018-10-23 19:43:03 UTC
view on stackexchange narkive permalink

我不知道有任何科學期刊將其決策基於代碼。是否雜亂與期刊無關。它應該是可複制的應該引起關注,但是我不知道有任何期刊將其作為標準,除了某些社區的一些倡議,例如NIPS,CVPR。在我看來,選擇發布它已經是一種獎勵(在某些情況下,由於組織的規定,甚至甚至不允許人們發布它們)。如果您有任何聲稱該代碼不正確或未按照規定做的聲明,則可能是另一回事了,但是您需要證明這一點。如果您只想對代碼的草率進行評論,我認為您應該澄清您的評論,並強調它不會影響總體審核,我同意先前發表的評論。“使作者相信,解決這些問題的個人利益。”只要知道您對代碼的評論與本文的評論無關即可。另外,即使代碼“亂七八糟”,也不要勸阻那些發布代碼的人。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...