維基百科討論:格式手冊/計算機

計算機類條目的代碼範例多而雜

很多算法或者設計模式的條目，例如冒泡排序，對於例子的選擇——不，完全就沒有什麼「選擇」或者「篩選」，基本就是各種代碼都丟上去。這些代碼：

• 意義重複。上文已有偽代碼描述，下面還一個個翻譯個遍。WP:NOT裡面真應該加一條「維基百科不是代碼複製粘貼大辭典（スタックオーバーフロー（Stack Overflow））」。（已經有「不經篩選的信息收集處」和「詞典」了）
  • 不要說什麼「每個語言有自己獨特的地方」之類的話。先不說語言特性不該是描述某個算法本身的條目的內容，某些選擇首先就是嚴重重複冗餘的。一個C++程式設計師看著欽定了類型的C，難道不會自己把int換掉，變成模板指定的類型？一個C#、Java或JavaScript程式設計師看著C，難道就不會按照自己語言的特性，把傳入長度的地方換掉變成數組對象本身自帶的信息？
  • 插入排序更是神奇。Python的另一個版本、Java的另一個版本，哈哈哈哈哈……
    • 順便一提，Python那個遞歸版本占用${\mathrm {O} }(n^{2})$空間，原因是array slicing複製。
    • 這裡倒是可以適當地用一些語言特性描述某些行為。例如C++這裡，可以用rotate描述次序輪換的步驟，避免循環套循環的噪音。
• 格式混亂。代碼你貼就貼吧，還貼得亂糟糟。好好加幾個空格，或者按照每個語言的流行方式（這需要MOS欽定）格式化一下，很難嗎？Python就去用PEP8，JS就去用standardjs，C就用K&R……
  • standardjs裡面有我不加分號的習慣或者惡趣味。也是減少噪音。
• 重點不明。代碼中輸出代碼之類的噪音非常多。例如我提到的冒泡排序中，Java、JavaScript之類的都有輸入輸出代碼。Pascal更搞笑，空有輸入輸出描述沒有輸入輸出代碼。

總而言之就是囉嗦加沒用，應該減少噪音，點到為止。要有解決方案的話，只能去格式手冊加東西。慢著，你說格式手冊？

“

如果為了正確地作出說明必須使用一串與特定Shell類型相關的命令，那麼你應當同時提供類ALGOL的sh，ksh和bash代碼，以及C語言風格的csh和tcsh代碼。

”

——Wikipedia:格式手冊/計算機（英文我查過了，也是這個說法）

這裡對於例子的還是太寬。C shell is dead，按照這東西現在的地位應該把fish之類shell的都加進去。有個標準化的POSIX sh就夠了。

--Artoria2e5 更改·工具 2016年5月27日 (五) 15:37 (UTC)

(！)意見如果大家看英文版的設計模式條目，你衹看到偽代碼和類似C (C-like - 因大多語言很相似C類語言)的代碼。會找這些條目的人，不是數學家就是程序員；他們該知道如何把偽代碼轉變成語言的代碼。還有，偽代碼該用漢字的嗎？中/港/臺的程序課本用什麽，就該用那字來寫偽代碼。(～)補充我看我的"Introduction to Algorithm 2nd Edition"英文版是衹有偽代碼的。George Leung（留言） 2016年5月27日 (五) 20:53 (UTC)

英文版偽代碼我注意到一個問題，開頭空格的 pre 方框和 math 互相混合導致格式混亂。其餘沒有什麼個人覺得需要注意的地方。另外，我記得我讀的除了高一Visual Basic 6（真是黑歷史）之外的書都是用英文偽代碼。--Artoria2e5 更改·工具 2016年5月27日 (五) 22:58 (UTC) 當然偽代碼這東西光說基於的自然語言沒什麼用，要寫成AppleScript那副囉嗦的樣子還是算法導論那種接近程序語言的樣子還是需要MoS討論。另外就是偽代碼還是要試著提煉出rotate之類的操作。

對條目中程序代碼風格的限制

有些數學、計算機科學條目中涉及到一些公式與算法，加入程序代碼以助理解本無可厚非。然而目前條目中各種代碼風格參差不齊，部分條目像是被OI黨攻占了，其中的代碼慘不忍睹，以圓周率為甚：

例子及其問題所在

#include<stdio.h>
#include<iostream>
using namespace std;
int main(void)
{   //本程序为每四位数输出，如果请求计算的位数不是4的整数倍，最后输出可能会少1~3位数
	long a[2]={956,80},b[2]={57121,25},i=0,j,k,p,q,r,s=2,t,u,v,N,M=10000;
	printf("%9cMachin%6cpi=16arctan(1/5)-4arctan(1/239)\nPlease input a number.\n",32,32);
	cin>>N,N=N/4+3;
	long *pi=new long[N],*e=new long[N];
	while(i<N)pi[i++]=0;
	while(--s+1)
	{
		for(*e=a[k=s],i=N;--i;)e[i]=0;
		for(q=1;j=i-1,i<N;e[i]?0:++i,q+=2,k=!k)
			for(r=v=0;++j<N;pi[j]+=k?u:-u)u=(t=v*M+(e[j]=(p=r*M+e[j])/b[s]))/q,r=p%b[s],v=t%q;
	}
	while(--i)(pi[i]=(t=pi[i]+s)%M)<0?pi[i]+=M,s=t/M-1:s=t/M;
	for(cout<<"3.";++i<N-2;)printf("%04ld",pi[i]);
	delete []pi,delete []e,cin.ignore(),cin.ignore();
	return 0;
}

#include<iostream>
#include <stdio.h>
using namespace std;
int main(void)
{
	long b=1000,c=200,d=0,e,f,i=0,N;
	cout<<"请输入圆周率位数(不超过100000)\n",cin>>N,N=N*10/3+20;
	long *a=new long[N+1];
	while(i<N)a[i++]=c;
	for(;(N-=10)>0;printf("%03ld",d+=(c+=e/b)/b),d=c%b,c=e%b)
		for(e=0,i=N;--i;a[i]=(e+=a[i]*b)%(f=i*2+1),e=e/f*i);
	delete []a,cin.ignore(),cin.ignore();
	return 0;
}

分析

1. 變量命名不恰當。從a到z完全不知道每個變量什麼意思，你以為是excel的單元格編號啊？
2. 基本沒有注釋。乍一看去，完全不知道這些語句什麼意思。輸入的位數還要乘十除三加二十？我想不應該讓讀者把時間浪費在理解這種奇怪的代碼上。
3. 排版格式不一致。不僅是此條目的問題，目前很多條目代碼縮進都不統一，有的空兩格，有的空四格，有的是個\t，有的數不清空幾格。這兩個也是。
4. 表達式太緊湊。各種逗號表達式的濫用（沒用goto真是謝天謝地），等號、括號等等左右也沒有空格。

以上。我知道OI和ACM黨什麼的常常敲出這樣的代碼，不過那個AC了就沒人管了啊！！！維基上的代碼是給人看的啊！！！吐槽吐完了，好爽啊

這種讓人看都不想看的代碼出現在維基百科，實在與為大眾傳播知識的目的相矛盾。雖然程序是正確有效的，但如此緊（la）湊（ji）的代碼風格讓人頗有「食之無味，棄之可惜」之感。我認為作為一部百科全書，其中的示例代碼必須首先注重可讀性，其次才考慮效率（當然在複雜度上最好只是常數的差異），所以有必要限制這方面的格式（注釋、表達式的使用、變量命名、排版等方面）。目前沒有找到社群相關共識，故希望與各位討論。 --碸中嘌呤的白磷_{萃取 打譜} 2017年1月26日 (四) 09:09 (UTC)

我覺得只保留部分為了演示算法步驟的偽代碼，所有具體語言實現不應該保留，單就風格這點，而且有些顯得極度囉嗦沒有。參見資料結構各子項目。——路過圍觀的Sakamotosan 2017年1月26日 (四) 09:39 (UTC)

(＋)支持，也不錯。如果限制代碼風格的話會有很多棘手的問題。 --碸中嘌呤的白磷_{萃取 打譜} 2017年1月26日 (四) 09:42 (UTC)

(＋)支持僅貼出偽代碼。一個功能可能有多種實現的代碼，而用偽代碼解釋思路會在不影響（甚至是促進）理解的基礎上使條目更為精煉。zhwiki不是CSDN。 --Rubyy^Talk|Flow 2017年1月29日 (日) 10:04 (UTC)

(＋)支持，算法才是核心，語言僅為方法。Apflu（留言） 2017年2月1日 (三) 19:21 (UTC)

(－)反對如何處理Hello World程序樣例?--Temp3600（留言） 2017年1月29日 (日) 13:37 (UTC) fine then.--Temp3600（留言） 2017年2月9日 (四) 03:42 (UTC)

前面討論中提到的程式，目的不是講解程式語言的語法，而是演算法的實現思路，同時要避免讓讀者因為不熟悉特定語言的程式碼感到困惑。不過Hello World的目的（Hello World條目也好，編程語言的條目也好）就是展示完整的程式碼，所以屬於例外情況。--逆襲的天邪鬼（留言） 2017年1月31日 (二) 14:29 (UTC)

(！)意見，以上提到的內容在這個討論的存檔目標Wikipedia_talk:格式手冊/計算機早已有過，建議再次提出重審。如果現有的程式語言能夠清晰易懂地描述某一算法，則不必要發明「惡搞語法」，另外定什麼偽代碼（偽代碼的詞彙也會有類似於風格的問題）。因而精神上(＋)支持，實現上略微(－)反對。——Artoria2e5_編 保持討論完整，直接ping我回復。 2017年2月10日 (五) 04:03 (UTC)

可參考英文MOS--Temp3600（留言） 2017年1月26日 (四) 15:18 (UTC)

這裡(＋)支持。和我的意見類似，不過對於偽代碼的強調更多一點。偽代碼大概可以變成「難懂處的」注釋形式？——Artoria2e5_編 保持討論完整，直接ping我回復。 2017年2月10日 (五) 04:05 (UTC)

結論

如無反對，可改。--Temp3600（留言） 2017年2月9日 (四) 15:03 (UTC)

@WhitePhosphorus：自己弄吧...--Temp3600（留言） 2017年2月13日 (一) 15:38 (UTC)

（沒收到ping）有空就弄。 --碸中嘌呤的白磷_{萃取 打譜} 2017年2月14日 (二) 13:11 (UTC)

@WhitePhosphorus：弄好了嗎?--Temp3600（留言） 2017年2月19日 (日) 13:03 (UTC)

清理和遷移條目中的冗餘程序代碼相關事項

目前的問題	重新討論清理條目中的冗餘代碼，以及將多餘代碼遷移至維基教科書
問題背景	計算機語言（C語言）和計算機算法（普林姆算法）條目內的代碼過多、過長，影響閱讀，而且維基百科不是教程，維基教科書才是。
我的觀點	將解決方案中的內容通過為指引： 刪除冗餘代碼。 向維基教科書移動代碼。
我的解決方案	條目中的代碼示例只能為偽代碼或某種主流程序語言的代碼之一，且表述一個過程只能有一份代碼，其餘代碼全部清理至維基教科書的相關頁面，具體執行細則為： 在下述所有條目中： 在維基教科書的討論頁張貼來源橫幅。 在條目的外部連結部分使用{{wikibook}}模板來指出代碼的位置，並同時編輯維基數據項將教科書內的頁面和維基百科條目關聯。 關於計算機算法的條目（如快速排序）中： 每種算法思想只能有一份代碼表述。 在維基教科書b:算法實現內羅列各種語言的實現。如b:算法實現/排序/快速排序 可以而且應該使用另一份代碼，來描述影響算法行為與性能的實現方式的差異。如快速排序中對兩種實現的描述。 基於計算平台與編譯器而且影響代碼風格的調優應該移入維基教科書，避免影響代碼可讀性。 關於計算機語言的條目（如Python）中： 只保留該語言的helloworld程序示例 介紹語法的代碼段移入維基教科書對應語言的頁面 使用列表來列出該程序語言支持的語法特性。 對於程式語言的語法特性（如函數對象），只用文字來簡要提及該語法特性，同時使用{{main}}模板來指向語法特性的說明頁面，避免直接張貼代碼段。 關於計算機語法特性的條目（如函數對象）中： 避免提及特定語言對該語法特性的支持情況，相關內容移動至該語言的維基教科書。 描述該語法本身的行為（如函數對象可以保存狀態）時，每種行為只能使用一份代碼來表示。 把對比特定程序語言的語法特性的表達方式的內容（如比較C++中函數和指針）移動至維基教科書b:常見程式語言特性與範式（此書目前不存在）
此前的類似討論	Wikipedia_talk:格式手冊/計算機

--jingkaimori（留言） 2020年4月5日 (日) 15:39 (UTC)

---

• (！)意見：TheEndOfKeyHighSchool綜合考慮維基百科討論:格式手冊/計算機，個人意見如下：

• 沒必要提案修改規則。前人就是差不多的想法，沒必要繼續討論，按自己的想法操作便是，有爭議之後再說。
• 沒必要強求移動到維基教科書。網上隨便一搜索就能搜到很多質量更好的代碼，而且寫維基教科書就得花時間把內容調整得符合教科書標準，所以說當興趣就夠了，別當作要求。

因此可考慮直接結案。--高文海（留言） 2020年4月6日 (一) 15:08 (UTC)

偽代碼作為一種經常用來描述算法的方式，我認為大多數情況下可能不需要刪去？--百無一用是書生 (☎) 2020年4月7日 (二) 02:47 (UTC)

優先保留偽代碼。如果偽代碼含糊其辭，需要進一步明確其含義，可以保留一種程序語言代碼。其他的可執行程序語言代碼應該全部移除。--jingkaimori（留言） 2020年4月7日 (二) 09:38 (UTC)

如果編碼規範、注釋良好的C/C++/Java實現比偽代碼更容易閱讀的話，也可考慮使用真代碼實現。--高文海（留言） 2020年4月7日 (二) 14:33 (UTC)

目前不建議直接增加規則。可否舉一兩個具體問題以便社群達成共識？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2020年4月7日 (二) 06:57 (UTC)

@UjuiUjuMandan：刪除多餘代碼前的快速排序條目、歸併排序。可以看出相當數量的程序設計相關條目在羅列程序代碼，頁面非常長，不便於閱讀。--jingkaimori（留言） 2020年4月7日 (二) 09:38 (UTC)

第一個我還真看過。我同意應當把示例代碼放到維基教科書，並在條目里加入連結。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2020年4月8日 (三) 06:24 (UTC)

• 的確是有必要明確規範。--Temp3600（留言） 2020年4月11日 (六) 04:02 (UTC)