For an iterative review, is it okay to edit my own question to include revised code?

Question

Is it okay to edit the question to include the improved code?

I would like to do so for the following reasons:

• To share the improved code with others
• To show the answering persons that I take their feedback seriously
• To make sure that I understood (and implement) the feedback in the right manner

I understand that the original code must remain untouched otherwise it would invalidate the question.

But how do I handle code review iterations? Do I have to create a new question for each new revision?

In my opinion, writing code is an iterative process. I ask for a review, I consider the feedback and implement it, and then what? Shall I open a new question for the next review round or is it okay to update the question with the improved code (like suggested here)?

This meta question belongs to this post.

Note: that this question has established a new/revised policy for how to edit posts after answers are received. Previous policies have been made obsolete as a result. The previous policy questions have been deleted, but, for those with enough rep, can be seen here:

• https://codereview.meta.stackexchange.com/questions/41/obsolete-iterative-code-reviews-how-can-they-happen-successfully-obsolete
• https://codereview.meta.stackexchange.com/questions/210/obsolete-how-are-reposts-handled-on-code-review-obsolete
• https://codereview.meta.stackexchange.com/questions/1482/obsolete-can-i-edit-my-own-question-to-include-suggested-changes-from-answers

---

Quick copy/paste link for comments:

_{[What you may and may not do after receiving answers](https://codereview.meta.stackexchange.com/a/1765)}

Answer 1

You have several options for follow-ups:

1. Accepting an answer

   If one of the answers gives you good advice with clear directions for improving your code, just accept the best answer and upvote any other answers you feel were helpful. The checkmark that you confer is the best way to show appreciation on this site, as it gives 15 reputation points and raises that answer to the top, and you also earn 2 reputation points for accepting an answer. Posting your revised code would be redundant.

2. Posting a new question

   If you incorporate advice from one or more answers, but are still unsure that the code is as good as it should be, then post a new question with your revised code. For the benefit of other users, add mutual links: mention the previous question in the new question, and add a comment on the old question linking to the follow-up question. See How to post a follow-up question

3. Posting a self-answer

   If you want to show everyone how you improved your code, but don't want to ask another question, then post an answer to your own question. Selfie answers are acceptable on Stack Exchange sites, and even encouraged: there is a self-learner badge you can earn for that. Selfie answers can even be upvoted, downvoted, or commented on in their own right. However, your answer must meet the standards of a Code Review answer, just like any other answer:

   • Code-only answers that don't actually review the code are insufficient and are subject to deletion.
   • Describe what you changed, and why. (see above point)
   • Give credit to any other users who may have helped you. As stated in (1) above, posting a selfie that merely reiterates an existing answer without adding new insight would deprive another user of well deserved reputation. Also consider making your selfie community wiki if you feel that earning reputation from it would be unfair. However, if it's not done yourself, and a moderator determines that the self-answer is primarily dependent on other answers, then they are allowed to activate the CW status automatically.

4. Posting on an external site

   If you are unwilling to write a sufficient explanation to constitute a good Code Review answer, then it would be best to refrain from posting your follow-up on Code Review at all. Instead, you may host your revised code on an external site (e.g. GitHub, GitHub Gist, Pastebin, JSBin, JSFiddle, Ideone, SQLFiddle, your personal blog, etc.) If your off-site host has revision capabilities, then include a link to the revision that was posted in the question. Format the edit as if it was always part of the question, and not as if it is an "Update". Something like the following:

   This code and updates are available at: [this repository](...some revision...)

   You could alternatively link to it in a comment on the question or in a comment on the most helpful answer.

   Although we disallow code in questions to be hosted on an external site, posting your revised code externally is fine, because:

   • The primary concern of the site is make justified suggestions for improving the code. The reviews are more valuable than the final product.
   • The "final" code is supplementary information that is not essential to the question-and-answer process.
   • Comments are considered disposable. If the link dies, we can just delete the obsolete comment.

In addition...

• You must not edit the code in the question, as that would violate the question-and-answer nature of this site. (An exception to that would be if a user wrote a comment saying that your code is completely broken, and needs to be fixed before it can be reviewed.)

• You also should not append your revised code to the question. Posting improved code is an answering activity, not a questioning activity. An example of such a problematic edit is Revision 2 of Optimize vector rotation. While the addendum to the question does not necessarily invalidate existing answers, it muddles the question. What are late-coming reviewers supposed to do? Reviewing the original code would be silly, but reviewing the revised code could lead to version skew among the answers.

---

On the other hand, that improvement would have made a good answer, since it was prefaced with a good justification for the code change. A reviewer who spots a problem with the revised code could post a comment, and it would be clear that the comment pertains to that revision. You could even post multiple selfie answers without muddling the original question.

Here are a few more illustrations of how adding revised code to the question is poor practice:

• StoredErrorWriter — Notice the big code dump in the question labelled "// Edit". What is anyone supposed to do with that? Nobody wants to take the time to diff the final with the original, and the follow-up isn't going to help anyone learn anything.

• Simpler method to detect int overflow — The follow-up largely repeats the advice in one of the answers. Yet, posting the follow-up kills the question, leaving no room for late-coming answers. Accepting the leading answer, possibly with comment, would have sufficed.

• Linux C++ Timer Class: How can I improve the accuracy? — Revised code was added, but without explanation. One of the late-coming answers pertains to the revised code. Ideally, the revision should have been posted as a new question, since there was so much code that changed.

• Pretty-print Pascal's triangle — The follow-up seems to be largely based on advice from one answer, but it isn't clear exactly how. Furthermore, @alexwlchan had to post an addendum to an answer in response to the follow-up. That's a mess of a thread for anyone to follow. Then, when I later posted an answer, I had to preface my remarks by noting that I was reviewing Revision 7. Yuck!

• Milliseconds to Time string & Time string to Milliseconds — Bad code in a question is worthy of an upvote, since that's what makes an interesting question. However, bad code in a follow-up should be downvoted. I'm so conflicted! I wish I could vote on the original question and the follow-up separately.

• Hexadecimal to integer conversion function — Five addenda, 16 revisions. Enough said.

---

To end on a positive note, here is an example of what I consider to be a fruitful iterative review:

1. Python Port Scanner
2. Python Port Scanner 2.0
3. Python Port Scanner 2.1

Answer 2

I came here because of

The moderators have had a discussion, and we are proposing new guidelines for posting follow-up code. Specifically, we would like to end the practice of letting the OP append revised code to a question. Since this is a departure from past practice, please read and provide feedback. We plan to upgrade this to faq status soon.

I personally like the appending of the new and approved code at the end once, it is the easiest way for people who want to post another answer to determine what has been addressed already or not. [@Jamal, agreed, multiple updates on a question -> do not want]

Also, it seems that this will generate more work for the mods, whom I thought were already busy ;)

Not the greatest arguments ever, but I still wanted to pitch in my 2 cents.

Edit:

What story is good without a single skewed point of data ;) This : node.js Passport Wrapper 2

This is the 3rd time that a person resubmits a JavaScript question that nobody responds to, costing me rep to put a bounty and keeping the answered score artificially low.