You have several options for follow-ups:
- #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.
- #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.
- #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.
- #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.
Simple 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:
