I know how you feel. I've been in your same situation many, many times.
Something doesn't work in your app, and you can't figure out how to fix it.
You've already gone through the usual steps:
- checked the console log for helpful error messages
- looked for answers on Google and StackOverflow
But you haven't been able to find a solution and there's only one thing left to do: ask for help.
Whether you're reaching out to a course instructor or a package maintainer, chances are they are willing to help you.
But their time is limited.
So here are some suggestions for how to ask good coding questions and get the answers you need faster.
DON'T: Paste a screenshot of your code
This may seem convenient because all you have to do is to take a screenshot of your code and drop it on Slack/Discord/GitHub:
But consider what the experience is for the recipient:
- they may or may not be able to read your code (some users need a screen reader)
- they definitely can't copy your code and test it in their IDE or look it up on StackOverflow
- as a result, they can't reuse and edit it when formulating an answer
In other words: by using screenshots, you may be forcing the other person to re-type your code by hand. 😭
Luckily, there's a better way.
DO: Use Code Blocks with Syntax Highlighting
Just copy the code from your IDE.
And inside Slack/Discord/GitHub, create a code block using a triple backtick (```) and paste it inside it:
Using a triple backtick creates a so-called code fence. This is part of the GitHub Flavored Markdown Spec and has wide support across the web.
Even better: you can specify what language you're using after the opening backticks.
As a result, your code block will get syntax highlighting:
Note: syntax highlighting works on GitHub and Discord, but not Slack.
Much better. Now your code snippet is easier to read, copy, and paste!
But you know what? You can do better than this!
DO: Create a small sample
Have you noticed how popular GitHub repositories have an issue template for how you should ask questions?
Here's an example of the issue template for the Riverpod package:
**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. -->
The purpose of this is to give enough context about your problem to whoever will help you.
Here's an example of an issue I recently opened for the Riverpod package:
If you share a small code sample, people can understand it with little effort. 👍
But there's a benefit for you too: creating a small example forces you to think about your problem in isolation from the rest of the project. This may give you some interesting insights (and sometimes, even the solution you were looking for!).
Bonus: share a runnable DartPad
Do you know what's better than sharing a small example?
Sharing a small runnable example.
And thanks to DartPad and GitHub gists, that's very easy to do.
This guide covers all the details:
Conclusion
Asking questions and receiving answers is a two-way street. By following these steps, you can make everyone's life easier:
- don't paste screenshots; use code blocks with syntax highlighting instead
- describe your problem with sample code and enough context so that the recipient can help you
- bonus: create a runnable code sample and share it as a gist or with Dartpad
At a very minimum, follow steps #1 and #2.
And if you're opening an issue or asking a question on a public GitHub repo, #3 will be very appreciated!
Happy coding!