How much research do we expect before asking? For me, I would say "A bit". Do not post your question as soon as your code seems to be working. You should "review it yourself" first. Ideally, you should feel that you have done the best you could before posting to Code Review. Don't just "get it done fast".
Preferably, if you are a somewhat skilled programmer (for beginners I imagine this step is much harder), you should have read other people's questions before you post yours, and quickly scan through the reviews they got and see if you can find anything that applies to you as well.
If it is a specific question about something like SQL-injection, I'd expect that you should understand what SQL-injection is, and that you should have reviewed your own code first to the best of your ability.
If it is a programming-challenge and/or time-limit-exceeded, then it is especially important that you do your research first. It is quite likely that you may encounter a question that has an algorithm equal to yours, and that is also asking the question about how to speed it up. Again though, this is easier to do if you are able to read and understand other people's code. The algorithm that matches yours might have been posted in a completely different language.
An important question in all of these cases, however, is: Do you want a specific answer to your concern or are you really looking for reviews on any and all aspects of the code? Although "Do you want a review on any and all aspects of the code?" is one of our "six magic on-topic questions", in practice that's not how it is handled (and it would be stupid in my opinion to close questions just because they have a specific concern instead of saying "I want reviews on all aspects of the code").
How to handle questions with low research effort then?
Let's take a look at our options, shall we?
- Vote to close as off-topic: Questions with low research effort are not off-topic according to any of our current close reasons, and they probably shouldn't be specifically off-topic either. They're on topic but not a question that we'd really like to see on the site.
- Downvote: Unless it's a well-asked question (the most well-asked linked-list that you have ever seen?), then feel free to downvote.
- Comment: Yes! Comments are good! Post a comment with something like: "The question you are asking is very similar to others already posted on this site. Have you taken a look at what questions have already been asked here? In particular you may like the following questions: (...)"
- Vote to close as a duplicate: For questions only mentioning a specific concern I think this should be an option. For questions asking about reviews on all aspects of the code, then it's hard to be a duplicate.
- Ignore and move on: Unfortunately, this is probably the most common option chosen today. You can only review so many calculator questions. You will probably get tired of them sooner or later.
- Answer anyway: This is also an option that is chosen quite often today. Sure, an answered question is an answered question. It's good for the site because it is one unanswered question less. It is good for you because you get reputation. It is good for the OP who gets an answer (assuming you're actually answering their concern and not just complaining about variable names when they are looking for a faster algorithm). The bad thing is that way too few people choose this option.
Post a comment recommending the user to look at already existing questions.
If you have a specific question, then it may be a duplicate. (This is currently not site policy but I suggest that it should become that)
If you really are looking for a review on any and all aspects of your code, then choose one or two of: downvote, comment, ignore the question completely, post an answer.