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 ...
No. We require the code to be contained within the question, for the following reasons:
To avoid dependency on third-party hosting services. These links tend to go away after a while.
To prevent review requests of huge projects.
To make it easier to see the code and so it can interest more reviewers and get more reviews.
To avoid confusion when the OP ...
I think that such question should clearly state that it is a follow-up question to a previously asked question.
A good follow-up question should include, in my opinion:
Which question it is a follow-up to
What changes has been made in the code since last question
Why a new review is being asked for
If a question does not include (at least some of) these ...
I'd like to describe what I would like to see on this site, rather than the current practice.
As noted in Answering Guidelines (answer length), there is a desire for cultural change on this site. Allowing shorter answers should improve the answer rate by lowering the barrier to contribution, and hopefully increase reputation scores all around.
I think ...
Personally, I think that they should usually NOT be allowed for questions.
This site is about code reviews. Readability is an important issue in code reviews, as are syntax errors. Editing the post is not constructive. It is much more helpful to leave a comment or answer that points out the shortcomings.
If the code in the question is edited, other ...
Note Accumulating multiple discussions about why the 'own code only' restriction is in place on Code Review
There are multiple reasons why Code Review has the restriction that the code has to be your own code.
Moral / Polite
The purpose of a code review is to provide constructive criticism. Criticism can only be constructive if given to the person who is ...
Proof by [extreme] example.
(based on a true story)
Not too long ago, someone posted one of their employees' code and asked for it to be reviewed by the community. The OP wrote that based on the feedback we would give him, that he would decide whether to keep or to fire that employee.
Would you write the same review if you knew that what you write can result ...
Code Review is not like other Stack Exchange sites. Other sites create a 'corpus' of reference questions and answers to problems experienced by people in those specific subject areas. This difference is most clearly seen in the handling of Duplicates. On other sites, questions that are the same, or similar to other questions are closed as duplicates.
In conclusion, after reading the other answers, I think that the consensus about flagging as "not an answer" is, more or less:
Flag link-only answers; for example:
There's an interesting implementation at http://example.com
Do not flag short answers, even if they contains a link, provided that the answer would still be informative without the ...
Answers to off-topic questions are already invalid
One way to look at this is to say that if a question is invalid, it should be closed and not answered. Answering an invalid question sends exactly the wrong message and encourages unwanted behavior.
Following that line of reasoning, fixing the question to make it on topic doesn't invalidate any answer ...
Our focus is to improve working code. By definition, pseudo-code is not working code. The restriction is (partially) to make sure you've put effort in your code before showing it to us. Pseudocode doesn't demonstrate that.
The only thing that we could possibly review about pseudo-code is the algorithm. But that would be Algorithm Review, not Code ...
You should find the most pressing issues and comment on them. Do not clean their code for them, but show examples to illustrate your points.
Code is never "too bad" to review. As long as the code is working, has a minimum standard of formatting and otherwise is on topic, it can receive a valuable review. Remember that a review does not need to improve all ...
The problem is not the number of follow-up questions. The problem is the rate of posting them. If you post a follow-up once a week, probably nobody will even notice. As long as it's well done, for example by following the great tips in this other discussion.
Posting follow-ups too soon is not good for anyone:
Posting too fast is not good for you. Given ...
Reinventing the wheel can actually be a useful exercise. But letting someone reinvent the wheel when they don't know they are doing it is a problem.
Pointing out that a ready-made solutions exists is helpful part of an answer. But you should still provide a review of the code itself. If you don't want to can't, you should probably just leave a comment ...
I think that there is also a legal reason for this: whenever you post something to a Stack Exchange site, you release it under the CC-BY-SA license. If the author doesn't post the code here, but to some other site, then they most likely didn't release it under that license. And you, as someone who didn't write that code, have no right to do that.
To be completely clear:
homework  and coding challenges are on-topic.
Issues with tags should be edited, it's rare to get questions with perfect tags - I get them wrong all the time too.
This means the questions are on-topic and so we shouldn't close the questions.
TL;DR: It's recommended to ignore who the user is, but ultimately it's your choice to ...
My take on this is No, we should not allow such answers. Why?
We're doing Code Review here, so what does that mean?
Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the ...
The mission of Code Review is to help programmers improve working code. Although A-B comparison questions tend to elicit a different kind of answer and therefore make us feel uncomfortable, they are just another way for programmers to seek help to improve their working code. We should therefore welcome them as Code Review questions, even though they don't ...
A pun is only a pun if it relates to something meaningful. Something like: "The trip to the arctic was so cool" is only funny because there's two meanings to the word.
The same has to be true with a punny title. The title has to have relevance to the question at hand, but, if you can make a pun out of it, and the "other" meaning is entertaining, then sure, ...
The first thing that comes to mind is "this user is trying to somehow
abuse the system to farm upvotes, badges, and reputation score."
Because yes, people do that. All the time. And when you look like
you're abusing the system, chances are people will think you are
abusing the system.
And abusing the system leads ...
According to What topics I can ask about here?:
Simply ask yourself the following questions. To be on-topic the answer must be yes to all questions:
Does my question contain code? (Please include the code in the question, not a link to it)
Did I write that code?
Is it actual code from a project rather than pseudo-code or example code?
Do I ...
I am a comment lover. Comments helps a lot. Especially when it's not crystal clear for everybody that the code is not working as intended.
Sometimes it's even good if two or more users independently considers the code not working as intended and adds a comment about that. (Just to avoid five close votes because "one person says so")
The benefits of a ...
Of course you may! That is, after all, the point of Creative Commons licensing — that you are free to learn from others' work and remix content into your own creations. If it's a close derivative work, be sure to abide by the terms of the license. If your work is just loosely inspired by something you saw, then attribution probably isn't required, but use ...
We should just leave them alone
There is no good solution to these mixed-bag questions with code in varying states. If there was an easy solution, we would have done it already.
As it stands, my recommendation is that we just leave these things alone, and 'grandfather' the mess. New questions are held to the exacting requirements of 'no code changes after ...
The only logical point at which a follow-on process becomes too much, is when the code becomes a duplicate of previously posted code.
Follow-On questions are important on this site, they add a lot of value as they often lead users through a progression of steps resulting in great code.
My experience is that, when a particular user takes their code though a ...
In general you shouldn't be editing code in the question, but instead reviewing it. But there are at least two cases where it's fine to make an exception:
Where the poster has fumbled the formatting. See for example this question, where the poster didn't know how to follow a numbered list with a code block. It's fine to fix this kind of mistake.