Wikipedia talk:格式手册/计算机

message: 很多算法或者设计模式的条目，例如冒泡排序，对于例子的选择——不，完全就没有什么“选择”或者“筛选”，基本就是各种代码都丢上去。这些代码：
* 意义重复。上文已有伪代码描述，下面还一个个翻译个遍。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)
replies: text: (！)意見如果大家看英文版的设计模式条目，你衹看到伪代码和類似C (C-like - 因大多语言很相似C類语言)的代码。會找這些条目的人，不是數學家就是程序員；他們該知道如何把伪代码轉變成语言的代码。還有，偽代碼該用漢字的嗎？中/港/臺的程序課本用什麽，就該用那字來寫伪代码。(～)補充我看我的"Introduction to Algorithm 2nd Edition"英文版是衹有伪代码的。George Leung（留言） 2016年5月27日 (五) 20:53 (UTC)
replies: text: : 英文版伪代码我注意到一个问题，开头空格的 pre 方框和 math 互相混合导致格式混乱。其余没有什么个人觉得需要注意的地方。另外，我记得我读的除了高一Visual Basic 6（真是黑历史）之外的书都是用英文伪代码。--Artoria2e5 更改·工具 2016年5月27日 (五) 22:58 (UTC) 当然伪代码这东西光说基于的自然语言没什么用，要写成AppleScript那副啰嗦的样子还是算法导论那种接近程序语言的样子还是需要MoS讨论。另外就是伪代码还是要试着提炼出rotate之类的操作。
thread_title:  计算机类条目的代码范例多而杂 

message: 有些数学、计算机科学条目中涉及到一些公式与算法，加入程序代码以助理解本无可厚非。然而目前条目中各种代码风格参差不齐，部分条目像是被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;
}
=== 分析 ===
# 变量命名不恰当。从a到z完全不知道每个变量什么意思，你以为是excel的单元格编号啊？
# 基本没有注释。乍一看去，完全不知道这些语句什么意思。输入的位数还要乘十除三加二十？我想不应该让读者把时间浪费在理解这种奇怪的代码上。
# 排版格式不一致。不仅是此条目的问题，目前很多条目代码缩进都不统一，有的空两格，有的空四格，有的是个\t，有的数不清空几格。这两个也是。
# 表达式太紧凑。各种逗号表达式的滥用（没用goto真是谢天谢地），等号、括号等等左右也没有空格。
以上。我知道OI和ACM党什么的常常敲出这样的代码，不过那个AC了就没人管了啊！！！维基上的代码是给人看的啊！！！
这种让人看都不想看的代码出现在维基百科，实在与为大众传播知识的目的相矛盾。虽然程序是正确有效的，但如此紧（la）凑（ji）的代码风格让人颇有“食之无味，弃之可惜”之感。我认为作为一部百科全书，其中的示例代码必须首先注重可读性，其次才考虑效率（当然在复杂度上最好只是常数的差异），所以有必要限制这方面的格式（注释、表达式的使用、变量命名、排版等方面）。目前没有找到社群相关共识，故希望与各位讨论。 --砜中嘌呤的白磷萃取 打谱 2017年1月26日 (四) 09:09 (UTC)
replies: text: :我觉得只保留部分为了演示算法步骤的伪代码，所有具体语言实现不应该保留，单就风格这点，而且有些显得极度啰嗦没有。参见数据结构各子项目。——路过围观的Sakamotosan 2017年1月26日 (四) 09:39 (UTC)
replies: text: ::，也不错。如果限制代码风格的话会有很多棘手的问题。 --砜中嘌呤的白磷萃取 打谱 2017年1月26日 (四) 09:42 (UTC)
replies: text: ::仅贴出伪代码。一个功能可能有多种实现的代码，而用伪代码解释思路会在不影响（甚至是促进）理解的基础上使条目更为精炼。zhwiki不是CSDN。 --RubyyTalk|Flow 2017年1月29日 (日) 10:04 (UTC)

text: ::，算法才是核心，语言仅为方法。Apflu（留言） 2017年2月1日 (三) 19:21 (UTC)

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

text: ::，以上提到的内容在这个讨论的存档目标Wikipedia_talk:格式手册/计算机早已有过，建议再次提出重审。如果现有的编程语言能够清晰易懂地描述某一算法，则不必要发明“恶搞语法”，另外定什么伪代码（伪代码的词汇也会有类似于风格的问题）。因而精神上，实现上略微。——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月10日 (五) 04:03 (UTC)

text: 可參考英文MOS--Temp3600（留言） 2017年1月26日 (四) 15:18 (UTC)
replies: text: :这里。和我的意见类似，不过对于伪代码的强调更多一点。伪代码大概可以变成“难懂处的”注释形式？——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月10日 (五) 04:05 (UTC)
=== 結論 ===
如無反對，可改。--Temp3600（留言） 2017年2月9日 (四) 15:03 (UTC)

text: :自己弄吧...--Temp3600（留言） 2017年2月13日 (一) 15:38 (UTC)
replies: text: ::（没收到ping）有空就弄。 --砜中嘌呤的白磷萃取 打谱 2017年2月14日 (二) 13:11 (UTC)
replies: text: :::弄好了嗎?--Temp3600（留言） 2017年2月19日 (日) 13:03 (UTC)
thread_title:  对条目中程序代码风格的限制 

message: # 变量命名不恰当。从a到z完全不知道每个变量什么意思，你以为是excel的单元格编号啊？
# 基本没有注释。乍一看去，完全不知道这些语句什么意思。输入的位数还要乘十除三加二十？我想不应该让读者把时间浪费在理解这种奇怪的代码上。
# 排版格式不一致。不仅是此条目的问题，目前很多条目代码缩进都不统一，有的空两格，有的空四格，有的是个\t，有的数不清空几格。这两个也是。
# 表达式太紧凑。各种逗号表达式的滥用（没用goto真是谢天谢地），等号、括号等等左右也没有空格。
以上。我知道OI和ACM党什么的常常敲出这样的代码，不过那个AC了就没人管了啊！！！维基上的代码是给人看的啊！！！
这种让人看都不想看的代码出现在维基百科，实在与为大众传播知识的目的相矛盾。虽然程序是正确有效的，但如此紧（la）凑（ji）的代码风格让人颇有“食之无味，弃之可惜”之感。我认为作为一部百科全书，其中的示例代码必须首先注重可读性，其次才考虑效率（当然在复杂度上最好只是常数的差异），所以有必要限制这方面的格式（注释、表达式的使用、变量命名、排版等方面）。目前没有找到社群相关共识，故希望与各位讨论。 --砜中嘌呤的白磷萃取 打谱 2017年1月26日 (四) 09:09 (UTC)
replies: text: :我觉得只保留部分为了演示算法步骤的伪代码，所有具体语言实现不应该保留，单就风格这点，而且有些显得极度啰嗦没有。参见数据结构各子项目。——路过围观的Sakamotosan 2017年1月26日 (四) 09:39 (UTC)
replies: text: ::，也不错。如果限制代码风格的话会有很多棘手的问题。 --砜中嘌呤的白磷萃取 打谱 2017年1月26日 (四) 09:42 (UTC)
replies: text: ::仅贴出伪代码。一个功能可能有多种实现的代码，而用伪代码解释思路会在不影响（甚至是促进）理解的基础上使条目更为精炼。zhwiki不是CSDN。 --RubyyTalk|Flow 2017年1月29日 (日) 10:04 (UTC)

text: ::，算法才是核心，语言仅为方法。Apflu（留言） 2017年2月1日 (三) 19:21 (UTC)

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

text: ::，以上提到的内容在这个讨论的存档目标Wikipedia_talk:格式手册/计算机早已有过，建议再次提出重审。如果现有的编程语言能够清晰易懂地描述某一算法，则不必要发明“恶搞语法”，另外定什么伪代码（伪代码的词汇也会有类似于风格的问题）。因而精神上，实现上略微。——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月10日 (五) 04:03 (UTC)

text: 可參考英文MOS--Temp3600（留言） 2017年1月26日 (四) 15:18 (UTC)
replies: text: :这里。和我的意见类似，不过对于伪代码的强调更多一点。伪代码大概可以变成“难懂处的”注释形式？——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月10日 (五) 04:05 (UTC)
thread_title:  分析 

message: 如無反對，可改。--Temp3600（留言） 2017年2月9日 (四) 15:03 (UTC)
replies: text: :自己弄吧...--Temp3600（留言） 2017年2月13日 (一) 15:38 (UTC)
replies: text: ::（没收到ping）有空就弄。 --砜中嘌呤的白磷萃取 打谱 2017年2月14日 (二) 13:11 (UTC)
replies: text: :::弄好了嗎?--Temp3600（留言） 2017年2月19日 (日) 13:03 (UTC)
thread_title:  結論 

message: 目前的问题         	重新讨论清理条目中的冗余代码，以及将多余代码迁移至维基教科书
问题背景          	计算机语言（C语言）和计算机算法（普林姆算法）条目内的代码过多、过长，影响阅读，而且维基百科不是教程，维基教科书才是。
我的观点          	将解决方案中的内容通过为指引：
# 删除冗余代码。
# 向维基教科书移动代码。
我的解决方案        	条目中的代码示例只能为伪代码或某种主流程序语言的代码之一，且表述一个过程只能有一份代码，其余代码全部清理至维基教科书的相关页面，具体执行细则为：
# 在下述所有条目中：
## 在维基教科书的讨论页张贴来源横幅。
## 在条目的外部链接部分使用模板来指出代码的位置，并同时编辑维基数据项将教科书内的页面和维基百科条目关联。
# 关于计算机算法的条目（如快速排序）中：
## 每种算法思想只能有一份代码表述。
## 在维基教科书b:算法实现内罗列各种语言的实现。如b:算法实现/排序/快速排序
## 可以而且应该使用另一份代码，来描述影响算法行为与性能的实现方式的差异。如快速排序中对两种实现的描述。
## 基于计算平台与编译器而且影响代码风格的调优应该移入维基教科书，避免影响代码可读性。
# 关于计算机语言的条目（如Python）中：
## 只保留该语言的helloworld程序示例
## 介绍语法的代码段移入维基教科书对应语言的页面
## 使用列表来列出该程序语言支持的语法特性。
## 对于编程语言的语法特性（如函数对象），只用文字来简要提及该语法特性，同时使用模板来指向语法特性的说明页面，避免直接张贴代码段。
# 关于计算机语法特性的条目（如函数对象）中：
## 避免提及特定语言对该语法特性的支持情况，相关内容移动至该语言的维基教科书。
## 描述该语法本身的行为（如函数对象可以保存状态）时，每种行为只能使用一份代码来表示。
## 把对比特定程序语言的语法特性的表达方式的内容（如比较C++中函数和指针）移动至维基教科书b:常见编程语言特性与范式（此书目前不存在）
此前的类似讨论       	
* Wikipedia_talk:格式手册/计算机
--jingkaimori（留言） 2020年4月5日 (日) 15:39 (UTC)
----
*(！)意見：TheEndOfKeyHighSchool综合考虑维基百科讨论:格式手册/计算机，个人意见如下：
replies: text: * 没必要提案修改规则。前人就是差不多的想法，没必要继续讨论，按自己的想法操作便是，有争议之后再说。

text: * 没必要强求移动到维基教科书。网上随便一搜索就能搜到很多质量更好的代码，而且写维基教科书就得花时间把内容调整得符合教科书标准，所以说当兴趣就够了，别当作要求。

text: 因此可考虑直接结案。--高文海（留言） 2020年4月6日 (一) 15:08 (UTC)
replies: text: :伪代码作为一种经常用来描述算法的方式，我认为大多数情况下可能不需要删去？---{百無一用是書生}- (☎) 2020年4月7日 (二) 02:47 (UTC)
replies: text: ::优先保留伪代码。如果伪代码含糊其辞，需要进一步明确其含义，可以保留一种程序语言代码。其他的可执行程序语言代码应该全部移除。--jingkaimori（留言） 2020年4月7日 (二) 09:38 (UTC)
replies: text: :::如果编码规范、注释良好的C/C++/Java实现比伪代码更容易阅读的话，也可考虑使用真代码实现。--高文海（留言） 2020年4月7日 (二) 14:33 (UTC)

text: 目前不建议直接增加规则。可否举一两个具体问题以便社群达成共识？ --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2020年4月7日 (二) 06:57 (UTC)
replies: text: :@-{UjuiUjuMandan}-：删除多余代码前的快速排序条目、归并排序。可以看出相当数量的程序设计相关条目在罗列程序代码，页面非常长，不便于阅读。--jingkaimori（留言） 2020年4月7日 (二) 09:38 (UTC)
replies: text: ::第一个我还真看过。我同意应当把示例代码放到维基教科书，并在条目里加入链接。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2020年4月8日 (三) 06:24 (UTC)
*的確是有必要明確規範。--Temp3600（留言） 2020年4月11日 (六) 04:02 (UTC)
thread_title:  清理和迁移条目中的冗余程序代码相关事项