我知道你的感受。我也遇到过很多很多次同样的情况。
你的应用程序中有些东西不工作,而你却不知道如何去解决它。
你已经经历了常规的步骤。
- 检查控制台日志,查看有用的错误信息
- 在谷歌和StackOverflow上寻找答案
但你还没有找到解决方案,现在只剩下一件事可以做:寻求帮助。
无论你是向课程教师还是向软件包维护者求助,他们都有可能愿意帮助你。
但他们的时间是有限的。
因此,这里有一些建议,如何提出好的编码问题,更快地得到你需要的答案。
不要粘贴你的代码的屏幕截图
这看起来很方便,因为你所要做的就是把你的代码截图并放到Slack/Discord/GitHub上。
带有代码截图的问题示例
但要考虑到接收者的体验是什么。
- 他们可能会也可能不会阅读你的代码(有些用户需要屏幕阅读器)
- 他们肯定无法复制你的代码并在他们的IDE中进行测试,也无法在StackOverflow上进行查询
- 因此,他们无法在制定答案时重复使用和编辑它。
换句话说:通过使用截图,你可能会迫使对方用手重新输入你的代码。😭
幸运的是,有一个更好的方法。
方法:使用带有语法高亮的代码块
只需从你的IDE中复制代码。
在Slack/Discord/GitHub中,用三个回车键(```)创建一个代码块,并将其粘贴在里面。
用三个反记号创建的代码块的例子
使用三连击可以创建一个所谓的代码栅栏。这是GitHub Flavored Markdown规范的一部分,在网络上得到了广泛的支持。
更棒的是:你可以在开头的回车键后指定你使用的是什么语言。
这样,你的代码块就会得到语法高亮显示。
带有语法高亮的代码块的例子
注意:语法高亮在GitHub和Discord上有效,但在Slack上无效。
好多了。现在,你的代码片段更容易阅读、复制和粘贴了!但是你知道吗?
但你知道吗?你可以做得比这更好!
做法:创建一个小样本
你有没有注意到,流行的GitHub仓库有一个问题模板,说明你应该如何提问?
这里有一个Riverpod包的问题模板的例子。
**Describe the bug**
<!-- A clear and concise description of what the bug is. -->
**To Reproduce**
<!-- Please add a small sample that can be executed to reproduce the problem. As a general rule, 100 lines is the maximum -->
**Expected behavior**
<!-- A clear and concise description of what you expected to happen. -->
这样做的目的是为了给那些将帮助你的人提供足够的关于你的问题的背景。
下面是我最近为Riverpod包打开的一个问题的例子。
如果你分享一个小的代码样本,人们可以不费吹灰之力就能理解它。👍
但对你来说也有一个好处:创建一个小例子,迫使你把你的问题与项目的其他部分隔离开来进行思考。这可能会给你一些有趣的见解(有时,甚至是你正在寻找的解决方案!)。
奖励:分享一个可运行的DartPad
你知道什么比分享一个小例子更好吗?
分享一个可运行的小例子。
而由于DartPad和GitHub的gists,这是很容易做到的。
本指南涵盖了所有的细节。
结论
提出问题和接受答案是一条双向的道路。通过遵循这些步骤,你可以使每个人的生活更轻松。
- 不要粘贴屏幕截图;使用带有语法高亮的代码块代替
- 用示例代码和足够的上下文描述你的问题,以便接收者能够帮助你
- 奖励:创建一个可运行的代码样本,并以Gist或Dartpad的形式分享。
至少要遵循第1和第2步。
如果你要在GitHub的公共仓库中打开一个问题或提出一个问题,那么第3个步骤将非常值得赞赏!
编码愉快!