查看“How To Ask Questions”的源代码

以下是对初学者和其他新手的一些提示，以最大程度地提高你获得有用答案的机会，并让社区乐于帮助你，而不是因你的抱怨而烦恼。 它的灵感来自文档[http://www.catb.org/~esr/faqs/smart-questions.html 如何以聪明的方式提问]，你可以通过网页搜索 (Google How To Ask Questions The Smart Way) 轻松找到该文档。 此处的指南仅是Eric S. Raymond的 “官方” 文档的子集，该文档主要适用于web论坛 (尤其是本论坛)。

'''注意：''' ''虽然这应该是显而易见的，但还是经常发生，所以需要提一下——'''永远'''不应该在任何Eric S.Raymond和Rick Moen他们个人没有参与的软件项目上直接联系他们，寻求帮助！ 发生这种情况的事实表明，像这样的网站读者还没有阅读和理解他们的建议。 由于作者明确要求将这一警告与他们的文件链接在一起，因此需要在任何可能的机会都强调这一点。''  

==用户标识和用户帐户==
花时间预先设置一个用户帐户，并带有可识别的用户名和头像。 如果仅根据问题描述和IP地址，试图找出“aetroi”和“sdfoiu”是否是同一个人，会导致反复提出同样的问题。 你的用户帐户为我们提供了一种私下联系你的方式，如果我们觉得回复会离题或太长，可以通过电子邮件发送回复。 一个独特的头像有助于一眼识别你的帖子。

''注意： 在OSDev.org论坛上注册是强制性的。 作为注册的好处，你还可以注册同时获得wiki edit访问权限。''

==标题==
这有助于 ''我们'' 识别我们知道的主题。 “内核问题”是一个糟糕的主题标题。“IVT问题”是一个稍微好一点的标题。 “鼠标移动时的中断处理程序三重故障”是一个很好的主题标题。 许多论坛常客也不会阅读每个主题。论坛流量现在已经增加到几乎不可能的程度 (尤其是在OS开发子论坛中)。 一个好的标题会吸引那些知道这个主题的人的注意。

==语法==
错误的语法，拼写和/或标点符号会使你的帖子 “非常” 难以理解。 你最终会被人忽略你的帖子，或者开始理解你的语言，而不是理解你的问题。 也不要使用1337（译者注：指Leet，一种流行于欧美技术论坛的黑客火星文）等一些短信快捷方式。 基本上，请使用正确的英语 (无论是英语还是美语拼写在很大程度上是无关紧要的)。

作为补充说明，OSDev.org 论坛目前没有任何其他语言的子论坛。 这是故意的。 将论坛分开更多意味着更少的人阅读并能够回答每个主题。 Eric S.Raymond还指出，编程（尤其是操作系统开发）总体是一个使用了大量英语单词的主题，因此用英语交流更容易。

==编程背景==
操作系统开发不是学习如何用C，汇编或任何其他语言编程的合理场所，这在本wiki和论坛规则中都有指出。 这些警告是有原因的，如果你问的问题向我们表明是关于这方面的，要么是你没有阅读和理解这些规则，要么是你选择无视这些规则，就不太可能在这里赢得太多同情。

的确，操作系统开发论坛有对新手苛刻的名声。 这是有原因的: 操作系统开发不是一个新手程序员可以合理探讨的话题。 在他们还没有真正了解自己在做什么的背景和经验之前，许多人过早地投身于这一领域，并因缺乏准备而感到焦头烂额。 不幸的是，这导致我们一次又一次地看到许多相同的错误和问题，如果发帖者能阅读这些警告并遵循他们的建议，这些错误和问题是可以避免的。

这不是一个可以通过简单的教程学习的领域，尤其是如果你什么都不做，只是复制和粘贴教程代码，并试图让它在你不理解的情况下工作。 确实存在一些教程但更确切的说它们其实是方向指导，而不是cookbook。 对于这一领域的大多数科目来说，很难简单而有条理的说明全部问题，所以没有任何完善教程。 从几个不同的现有源中剪切和粘贴代码，并期望它们神奇地结合在一起，这在操作系统开发中简直是一种不可行的方法。 在以有意义的方式进入这一领域之前，你需要学习很多知识，并彻底了解自己在做什么。

==研究==
维基在不断扩展和修改。 很有可能你的问题已经有了答案。 如果你在开发周期的早期遇到问题，情况尤其如此：诸如[[Interrupts|中断]]、设置[[GCC Cross-Compiler|GCC交叉编译器]]和[[Printting to Screen]]等主题在维基中已有“大量”信息。

如果你使用的是更常见的教程/示例内核之一，则你的问题可能已经在论坛中得到回答。 也可以使用论坛搜索功能以期待得到答案。

如果你的问题是“我在哪里可以找到X”，或者“有没有做Y的程序”，搜索引擎几乎肯定会给你一个比我们更快，甚至可能更了解情况的答案。

人们一旦找到解决方案，坚持使用解决方案是很常见的- 这里的许多人可能会给你指出一两个选择，但可能会错过最适合你的一个。

你不太可能通过询问诸如“如何从FAT磁盘读取数据？”、“如何加载程序？”或“是否有任何内存管理教程？”之类的一般性问题来获得你想要的回答。 问这样的问题表明你缺乏基本的编程技能; 程序员应该能够自己解决问题，上面这样提问表现出他们自己还没有完成该做的研究。 一个更好的例子可能是将问题重新表述为 “我正在尝试做X，我已经做了Y，但我不完全理解Z。”

===关于过期或不完整的维基文章===
对于任何大型协作项目(如维基)来说，不可避免的是，一些信息在没有人注意到的情况下就过时了，这是一个令人悲哀的事实。 同样不可避免地，有些主题根本没有得到他们需要的关注。 如果你认为发现了以上种事情，请尽量不要生气；相反，礼貌地把它放在留言板上，这样某人——可能是你自己——可以添加和/或更新它。

可能是因为到目前为止还没有人注意到这一点，或者还没有主题专家解决过这个问题；也可能是有人将页面的副本挂到了自己的私人页面上，以便再进行大检查，而这还没有反映在官方页面中。 甚至可能在如何解决该主题方面存在争议，导致了计划更新的延迟。 相反，你可能错过了其他方面的某件内容（考虑到维基的大小和规模，这肯定会发生），熟悉该主题的论坛用户可以为你指明正确的方向。 在任何一种情况下，反馈最好是建设性的和积极的，而不是对此大发雷霆。

== 详细信息 ==
操作系统代码高度相互依赖。 如果你只给我们三重故障的中断处理程序的源代码，我们将无法在你的IVT设置中找到实际“导致”错误的错误。 我们还需要知道你使用的是什么编译器/汇编程序/链接器，在哪个版本中，以及你使用的是哪些命令行选项。

在[[Projects|OS项目列表]]中创建一个描述你的项目和环境的条目，并在你的论坛签名中添加一个指向该条目的链接，还可以让我们快速获得诸如“你使用的是什么编译器？”等琐碎问题的答案。或者“你的开发环境是什么？”，“你在用GRUB吗？ Bochs？ VMware？”等等。

正如提供的信息太少不行，太多也同样有害。 很容易给人错误的印象 (“我有问题，但不愿费心缩小范围。帮我修好它!”)。

虽然你的项目结构对你来说可能是完全合乎逻辑和直观的，但其他人可能仍然感到困惑，没有人喜欢通过挖掘几十个源文件来了解发生了什么。

尝试找到足以重现问题的最小代码子集。(这也是一种很好的调试技术；你可以在该过程中自己定位错误。)

与往常一样，任何操作系统项目的一个关键组成部分应该是一个异地源代码控制存储库; 除了关于代码保留和备份的优点之外，它还允许问题回答者查看有问题的代码，而不必费力地浏览一个大代码帖子，或者不得不要求一遍又一遍地发布代码。 如果你有这样一个存储库（而且你应该这样做），一定要包含一个指向你遇到问题的代码部分位置的链接。 这将允许论坛参与者看到最新版本的代码，并直接引用它。 如前所述，你应该将代码帖子限制在你遇到问题的代码的那一部分; 如果问题被证明在别处，可以在后续提供的代码存储库中定位到它。

==格式化==
论坛有一个[code] ... [/code]格式化命令，你可以使用该命令突出显示你的代码片段，避免笑脸/字体标签弄乱你的帖子。

把你的帖子分成几段。 不要显得大喊大叫（例如用大写字母书写），也不要使用漂亮但无用的格式（比如发光的彩色字体、移动的文本、成排的表情符等）。 如果可能，请使用“预览”功能。


== 描述目标 ==
当一个人在处理一个特定的问题X时，通常会找到一个看起来合适的解决方案Y，但你不知道如何正确地实现，或者在调试中遇到问题。 这可能会导致你发布一个关于如何正确做Y的问题。 这可能也行，''但是''这样做而不解释为什么要解决问题Y的上下文 (问题X) ，可能会导致解决了Y，但不是解决问题X的目标。 实际上，可能是Y根本不能解决问题X，或者有一个更好的方案，你不知道。 在这种情况下，询问Y反而会把你引向死胡同。 充其量，这会使那些可能对你的目标感到困惑的人更困惑，即使他们实际上知道如何解决X，他们也根本不会回答。

这种错误的解决方案求助方式被称为[https://en.wikipedia.org/wiki/XY_problem XY问题]（或者更幽默地说，是一个[https://weblogs.asp.net/alex_papadimoulis/408925 “瓶子或旧鞋”问题]），这是论坛上最令人沮丧的沟通问题之一。  

为了避免这种情况，你应该仔细考虑一下，在寻求帮助时，你是否已经充分解释了你试图实现的目标。 你不需要详细说明你的项目，但是眼前目标的大体介绍 (以及你过去使用过的任何解决方案) 可以为受访者建立足够的上下文，进而对回答你的问题有很大的帮助。

==识别问题并向他人描述==
试着在发帖之前尽可能地隔离出你的问题，并在你的帖子中尽可能多地提供信息。 信息太少和太多，都很难回答问题，但总的来说，多总比少好。 

一般来说，在寻求编程帮助时，最好给出[http://www.sscce.org/ 简短、自包含、正确（可编译）、示例]的问题信息，与实际代码库隔离。 然而，在OS Dev中，这可能是做不到的，因为错误通常与整个环境紧密相关，并且在任何情况下，隔离内核或驱动程序操作的代码都可能是不现实的。 如果你能给出一点 -- 即使它需要一些额外的脚手架 -- 那么就这样做，因为它将把问题与无关的细节隔离开来，但如果你不能，我们不会责怪你 (但不尝试是不礼貌的)。

===发布代码示例与到存储库的链接===
在解释问题时，你可能需要提供问题部分的代码示例，或者提供到代码库的链接，或者两者兼而有之。 通常，在发布代码示例时，会希望给出足够的代码来说明问题，而同时又不需要太多。 然而，这到底有多少可能很难判断。 此外，极长的代码示例往往很难在帖子中通读，因此如果一个代码片段中的代码行超过(比方说)50行，最好改为链接到它。 即使使用较小的代码段，也应该包括指向你的代码仓库的链接，因为它可能使我们能够为该问题获得一些其他上下文。

请注意，发布代码或仓库链接，并告诉我们“这不起作用”是不够的。 简单地给出一个很大的代码样本或一个指向代码库的链接，然后期望我们回答你的问题，而不至少告诉我们你认为问题在代码库中的什么地方，这是非常粗鲁的。 这样做而不解释故障模式 (不解释发生或没发生什么) 更是如此。 恐怕有人会认为这不需要说，显然是这样。



遵循上述准则会大大提高你获得快速而有用答复的机会。 （这会让你变得更受欢迎，这样那些有专门知识的人会留下来，下次仍然可以帮助你。）

[[Category:OS Development]]