Skip to main content

More advice

Summarize your task at a high level​

Every question should start with a brief description of your goal. Before you share or explain any code at all, the reader should be able to understand why that code needs to exist. Here are examples of good summaries:

  • “I’m creating a web form in a Next.js app to collect some information about the user so that I can create a row in MySQL with it. The data needs to be sanitized before adding it.”

  • “I’m creating an alert system for my iOS app that allows the user to receive a message in the Notification Center in response to code running on a node.js server using Firebase Cloud Messaging.”

  • “I’m writing an Apache rewrite rule that removes the trailing slash from a list of specific URL paths.”

Summarizing your task is important because you might be trying to do something that’s not feasible, or you are going about it the wrong way. The members of Stack Overflow can give you feedback on that so you don’t spend any more time on a solution that doesn’t exist.

Don’t require external and off-site resources​

Stack Overflow requires that all relevant information be included directly in the question itself. This means that you should not require the reader to click links to external information in order to answer your question. This is important for several reasons:

  • Links to external information could become stale over time, which makes the question unhelpful to others in the future.

  • It helps search engines index your question so that it’s more easily found by others in the future.

  • Requiring the reader to use outside information makes it harder for them to answer the question. You should always put effort into making the question as easy as possible to answer.

Providing code​

Do not: Link to your project code on GitHub or other sites.

Do: Construct a minimal, complete, reproducible example and include the code directly in the question. Format it so that it’s easy to read.

Linking to tutorials​

Do not: Link to an external tutorial and assume the reader will follow along with it.

Do: Explain in your own words what you’re doing and where you are stuck.

Linking to documentation​

Do not: Link to the documentation you’re using and expect the reader to click through and study it on their own.

Do: Link to the documentation and cite just the relevant text by copying it into the question and formatting it as a blockquote.

Don’t change the nature of the question​

After receiving an answer to your question, you might find that you have a followup question or another problem after the first one is resolved. In these cases, do not edit the original question to change it. Instead, post an entirely new question.

There are two reasons for this:

  • If your first question received a valid answer, and it was helpful, it’s best to preserve that as a record to be helpful for others in the future. By changing the question, you are effectively erasing that knowledge from the site, which is counterproductive.

  • By changing the question after an answer, you are invalidating the previously correct or helpful answer, which could upset the person who went through the trouble of composing the answer. If an answer addresses the original question, you should always upvote it and mark it as correct as a courtesy to that person.

If you do change the nature of the question without being asked to do so, someone with a high enough reputation might revert those changes with an explanation that your edit was not productive.