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

以下是给初学英语的人和其他新手的一些提示，以最大限度地提高你获得问题有用答案的机会，并让社区乐于帮助你，而不是因为你的抱怨而烦恼。 它的灵感来自于[http://www.catb.org/~esr/faqs/smart-questions.html 如何聪明提问]文档，您可以通过web（谷歌）搜索轻松检索该文档。 这里的指南只是Eric S.的“官方”文件的子集。 雷蒙德：这适用于网络论坛（尤其是这个论坛）。

“注意：”“虽然它应该是显而易见的，但它经常出现，需要说出来-埃里克S。 Raymond和Rick Moen应“永远”直接联系，以获得他们未亲自参与的任何软件项目的帮助！事实上，这种情况的发生表明，像这样的网站的读者还没有阅读和理解他们的建议。 由于作者明确要求将这一警告与他们的文件的任何链接一起包含，因此需要在任何可能的机会都强调这一点。''

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

''注意：在OSDev上注册。组织论坛是强制性的。 作为注册的一个好处，您还可以注册以获得wiki编辑访问权限。''

== 标题 ==
这有助于“我们”识别我们知道的主题。 “内核问题”是一个糟糕的线程标题。 “IVT问题”是一个稍微好一点的标题。 “鼠标移动时的中断处理程序三重错误”是一个极好的线程标题。 很多论坛常客并不是每一个话题都读；论坛流量现在已经增加到几乎不可能的程度（特别是在OS开发子论坛中）。一个好的标题会吸引那些知道这个话题的人的注意力。

== 语法 ==
糟糕的语法、拼写和/或标点符号会让你的帖子“更难理解”。 最终，人们会忽略您的帖子或调试您的语言，而不是调试您的问题。 远离1337和短信快捷方式。 基本上，使用正确的英语（无论是英国还是美国的拼写在很大程度上是无关的）。

作为补充说明，OSDev。除英语外，组织论坛目前没有任何其他语言的子论坛。 这是故意的。 将论坛拆分得越多，阅读和回答每个主题的人就会越少。 Eric S.Raymond还指出，一般的编程（特别是操作系统开发）是一个使用了大量英语单词的主题，因此用英语交流更容易。

== 编程背景 ==
OS开发不是学习如何使用C、汇编或任何其他语言编程的合理场所，这是本wiki和论坛规则中都指出的。 这些警告的存在是有原因的，如果你问一个问题，表明你没有阅读和理解这些规则，或者选择无视这些规则，那么你不太可能在这里赢得很多同情。

== 编程背景 ==
OS开发不是学习如何使用C、汇编或任何其他语言编程的合理场所，这是本wiki和论坛规则中都指出的。 这些警告的存在是有原因的，如果你问一个问题，表明你没有阅读和理解这些规则，或者选择无视这些规则，那么你不太可能在这里赢得很多同情。

的确，操作系统开发论坛以对新手苛刻而著称。 这是有原因的：操作系统开发并不是一个新手程序员可以合理处理的话题。 很多人过早地进入这个领域——在他们有背景和经验来真正理解他们正在做什么之前——并被他们缺乏准备所烧伤。 不幸的是，这导致我们一次又一次地看到许多相同的错误和问题，如果海报只是阅读这些警告并遵循他们的建议，这些错误和问题是可以避免的。

这不是一个可以通过简单的教程学习的领域，特别是如果你什么都不做，只是复制和粘贴教程代码，并试图在不理解它的情况下使其工作。 确实存在的教程——对于这一领域的大多数科目来说，没有任何教程，而且它们也不能合理地“是”任何教程——只是作为指导方针，而不是食谱。 从几个不同的现有源代码中剪切和粘贴代码，并期望它们神奇地结合在一起，这对于操作系统开发来说是不可行的。 你需要学习很多东西，彻底了解你正在做什么，然后才能期望以有意义的方式进入这个领域。

== 研究 ==
维基不断地扩展和修改。 很有可能你的问题已经有了答案。 如果您在开发周期的早期遇到问题，这一点尤其正确：诸如[[Interrupts]]、设置[[GCC交叉编译器]]和[[Printing to Screen]]等主题在wiki中已经有了“大量”的信息。

如果您使用的是更常见的教程/示例内核，那么您的问题可能已经在论坛上得到了回答。 使用论坛搜索功能，答案将等待。

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

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

你不太可能通过问一些一般性的问题得到你想要的答案，比如“我如何从一张胖磁盘上读取？”，“如何加载程序？”，或者“有内存管理教程吗？”问这样的问题表明缺乏必要的编程技能；程序员应该能够自己解决问题，这清楚地表明他们还没有完成研究。 一个更好的例子是将问题改为“我正在尝试做X”。 我做了Y，但我不完全理解Z。"

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

这可能是因为到目前为止人们一直没有注意到这一点，也可能是因为还没有一位主题专家对此进行过讨论；也可能是有人将该页面的副本挂到了自己的私人页面上，以便对其进行重大修改，而这一点尚未反映在官方页面中。 甚至可能在如何解决该主题上存在争议，这推迟了计划的更新。 相反，你可能错过了其他地方的东西（考虑到维基的规模和蔓延，这肯定会发生），熟悉该主题的论坛访问者可以为你指明正确的方向。 在这两种情况下，最好是建设性的、积极主动的，而不是火冒三丈。

== 细节 ==
操作系统代码高度相互依赖。 如果您只提供tripple故障的中断处理程序的源代码，我们将无法在您的IVT设置中找到实际“导致”错误的错误。 我们还需要知道您正在使用的编译器/汇编器/链接器、版本以及使用的命令行选项。

在[[Projects | OS Projects list]]中创建一个描述您的项目和环境的条目，并将该条目的链接添加到您的论坛签名中，这也将使我们能够快速获得诸如“您使用的是什么编译器？”等琐碎问题的答案或者“您的开发环境是什么？”或者“您正在使用GRUB？Bochs？VMware？”等

正如提供的信息太少，太多也同样有害。 很容易给人留下错误的印象（“我有一个问题，但不能费心去缩小它。 帮我修一下！").

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

试着找到一个足够重现问题的最小代码子集。 （这也是一种很好的调试技术；您可以自己在过程中找到错误。)

和往常一样，任何操作系统项目的一个关键组件都应该是一个非现场源代码管理存储库；除了在代码保留和备份方面的优势外，它还允许响应者查看有问题的代码，而无需费力阅读大量代码帖子，或要求反复发布代码。 如果您有这样一个存储库（而且您应该这样做），请确保包含指向您遇到问题的代码部分位置的链接。 这将允许论坛访问者看到最新版本的代码，并直接参考它。 如前所述，您应该将代码发布限制在您遇到问题的代码部分；如果问题在其他地方，回购协议应允许随着时间的推移确定问题。

== 格式化 ==
论坛有一个[代码]。。。[/code]格式化命令，您可以使用该命令突出显示代码段，避免smilies/fontifig标记弄乱文章。

把你的文章分成几个句子的段落。 不要大声喊叫（例如用大写字母书写）或使用漂亮但无用的格式（如发光的彩色字体、移动的文本、微笑的线条等）。)。如果可能，请使用“预览”功能。


== 描述目标 ==
当一个人处理一个特定的问题X时，通常会找到一个看起来合适的解决方案Y，但您不知道如何正确实现，或者在调试时遇到问题。 这可能会导致您发布一个关于如何正确执行Y的问题。 这很好，“除了”这样做而不解释为什么要解决问题Y的上下文（问题X）可能会导致解决Y的答案，但不是以解决X的方式。 事实上，可能是Y根本不能解X，或者有一个更好的解可以解X，而你却不知道。 在这种情况下，询问Y会让你走上死胡同。 充其量，这可能会让那些可能回答的人对你的目标感到困惑，导致他们根本不回答，即使他们可能真的知道如何解决X。

This sort of false solution is known as the [https://en.wikipedia.org/wiki/XY_problem XY Problem] (or more humorously, a [https://weblogs.asp.net/alex_papadimoulis/408925 'Bottle or Old Shoe' Question]), which is one of the most frustrating communication problems one can have on a forum.

为了避免这一点，你应该仔细考虑你是否已经解释了当你寻求帮助时你想要完成的事情。 你不需要详细描述你的项目，但是一个直接目标的略图（以及你过去使用过的任何解决方案）可以在很大程度上为回答你的问题的人建立足够的背景。

== 识别问题并向其他人描述 ==
在发布之前，尽可能地隔离你的问题，并在帖子中尽可能多地提供信息。 信息太少和太多都会使回答问题变得更加困难，但总的来说，信息太多总比信息太少好。

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

=== 发布代码示例与链接到存储库 ===
在解释问题时，您可能需要提供问题部分的代码示例或到代码存储库的链接，或者两者都提供。 通常，在发布代码示例时，您希望提供足够的代码来说明问题，而不是更多。 然而，这到底有多大可能很难判断。 此外，非常长的代码示例往往很难在文章中通读，因此，如果一个代码段中有超过（比如）50行的代码，那么最好链接到它。 即使是一个较小的片段，包括一个链接到您的回购是感激的，因为它可以让我们获得一些额外的背景问题。

请注意，张贴代码或回购链接，并告诉我们“这不起作用”是不够的。 简单地给出一个大的代码示例或一个到回购协议的链接，期望我们回答您的问题，而不至少告诉我们您认为问题在代码库中的什么位置，这是非常不礼貌的。 这样做而不解释故障模式（即，发生了什么或没有发生什么）更是如此。 有人会认为这不需要说，但显然是这样。

----

遵循上述指导原则可以大大提高您获得快速、有用回复的机会。 (它使帮助你变得更有趣，所以那些有诀窍的人会留下来，明天仍然可以帮助你。)

[[Category:OS Development]]