This is not about a question being on-topic, or off topic. Rather, this is about making on-topic questions great questions for you, and the whole community.
#Before you ask your question...
###Understand the community
Code Review is a collection of users with different experience levels in different technologies. These users each have different time commitments and availability.
Understand that you are requesting a review, and you cannot demand one. Code Review is not just a 'service' to be used for free. It is a two way street. The people reviewing your code do it because they want to, and they enjoy it. Sure, there's some internet points involved too, but that is not actually the reason people spend the time to review your code.
If you want people to review your code, you have to present your code in a way that makes someone want to review it:
- Give as much relevant background to your code as you can. Make it both concise and complete (it can be done). Flowery and 'chummy' language does not help. Stick to the facts.
- Contain your questions to bite-sized portions - you should not expect anyone to have to spend more than 10 minutes looking at your question. If your question takes more then that to 'digest' then you likely will reduce the value you get from an answer, and people will answer just a part of your question.
Further, you can adapt your question to 'attract' the types of review you want to get, by adjusting your presentation to suit the nature of the reviewers you want.
- Understand that people volunteer their time, respect that, and help them to help you
###Decide what you want reviewed
Reviewers tend to go through a natural progression/process when reviewing a question. It goes something like this:
- read the text
- read the code
- anything obviously broken? If yes - Vote to close.
- was reading the code hard to do? If yes - give a 'code style' type answer - improve readability.
- will general refactoring help? If yes - suggest DRY, Code Extraction, etc.
- are there edge-cases or other more obscure bugs that should be addressed? If yes - give a non-obvious bugs answer.
- Is the algorithm slow? If yes, suggest an improved algorithm
- Other suggestions....
What I am saying, is that it is hard to progress from one step to the next if the earlier step is broken. A code reviewer will focus on the first issues they see. This is human nature. The Code Review site acknowledges this and has a formal procedure for Iterative Reviews which allows you to clean up one part of the code so the review can focus on the next part.
How does this affect you in asking a high-value question? Well, if you want the algorithm reviewed in your code, then you should make your code very readable first, and not have bugs, because otherwise the answers will focus on the things that were 'bigger' problems than the algorithm. If the algorithm is not immediately 'apparent' then your question will not likely get a good algorithm review (but will probably get a good code-style/readability review).
- The way you present your question influences the type of review you will get. Ensure that the reviewer can 'access' the code that embodies your concerns as easily as possible.
#When you ask your question
Your question is (should be) presented in 4 basic parts. The Title, Tags, Text, and Code. I suggest that you build your question up in that order too.
###Title
Use a title that is catchy, and describes the problem your code solves. A question with the title "New programmer looking for advice" is both 'obvious' and meaningless. How does that differentiate your question from any other? Everyone is 'looking for advice', so that's useless. A title like "Project Euler #18 - Max path in a triangle" is much better.
Many reviewers see only the title and tags when they scan the questions. Make your title work for you. The more people who click through your title to read the question, the more likely you are to get a good review.
Hint: If your title contains a question, it is likely a bad title.
- Titles should reflect what your code does, not what concerns you about your code
###Tags
Do not underestimate the power of the tags. The obvious one is to tag with the language you use, but also look for the tags like performance or algorithm or some other 'meta' tag that extends beyond just a single technology or language. People 'follow' tags, and many reviewers can answer 'meta' type questions like algorithm and performance in languages other than just the ones they follow. Use tags to bring your question to the attention of people beyond just your language/implementation.
- Tags are used by reviewers to find questions to review. Use this to attract people who can help you
###Text
Introduce your code before you present your code. Always put your text first. Describing what the reviewer is going to see before they see it,
Also, try to:
- describe the problem your code solves. Give enough context so that a reviewer can perhaps suggest an entirely different solution.
- describe what you think your code does, give a brief text-based description of the 'landmarks' in your code.
- give a particular concern you would like reviewers to address, what do you think your weakness is in your code. Why do you want a review?
There is no need to apologize for being a beginner, or for being non-English speaking, and there is no reason to add 'thanks' messages either. Stick to the facts. If you are non-English speaking, then you may find your question is edited for you, and the text is improved. English is the language for Code Review, and questions tend to be corrected where there are spelling, or grammatical errors. Do not feel embarrassed about this (we understand that English is hard, and will not hold it against you), and do not feel upset about these edits. They help you in the long run.
It goes without saying that these text-based statements should match the code. The text allows a reviewer to understand the context of the code, and to make suggestions that could occasionally be very valuable, that allow the problem to be solved in an entirely different way.
The text also allows reviewers to anticipate edge-cases you may have missed, and to identify other bugs that may be non-obvious.
- The text is to provide context, explanation, and direction. Be generous with context, and light on chatter.
###Code
Present your code in a way that will be as familiar to the language community that reviews it as you can make it. As much as you can, you should follow general code conventions for your language of choice, and use libraries and code that are commonly used as well.
Reviewers here generally expect code to follow a sensible and consistent style. If you want the reviewers to read your code, then give it to them in a way that makes it easy for them to digest. If your personal style is significantly different from common practice, then I suggest you either change the style for when you ask here, or alternatively add a note in your question saying you are aware of the discrepancy, and possibly why you do things differently. Regardless of the actual style used though, you should always be consistent in your style.
Try to focus your code on to only those things you want reviewed. If you want an algorithm reviewed, the try to include only that code that is related to the algorithm. This reduces the amount of 'distraction', and it also means there is less code to read, and criticize. The more code you include in your question, the more opportunity there is for reviewers to find the 'simple' things that are wrong.
- Code should be in a state that allows your particular concerns to be obvious. If your concerns are hidden behind other issues, then don't expect your concerns to be addressed
#After you ask your question
So you have asked a question, how do you ensure it succeeds?
###Keep in touch!
Many times reviewers will have additional questions for you in order to understand and clarify your code (or context). You should understand that you wrote the code so understanding it is easy. Reviewers have a disadvantage here, and will need help. Use these types of questions as a learning opportunity to understand how other people 'think' and how it should change the way you describe your programs in future. It is a very valuable skill to be able to describe your problems and solutions in a way other people understand the first time. Use this as a way to learn that skill, and to learn what sorts of things in your code and description are hard to 'grok'. Do not be offended that other people can't see what is 'obvious' to you.
Additionally, a person who engages positively with the reviewers is likely to get a more personal and well-thought-out answer.
- Be available to answer questions, and be respectful no matter how stupid you may think the question is.
###Swallow your pride
It is inevitable that people will find faults in your code, thinking, or style. You will be criticized, and mistakes will be pointed out. This is a good thing. This is an opportunity for you to learn, and it is why you are here. Read all the answers, and comments, and understand them. Sometimes answers point out things that you disagree with. This is OK. The trick is to understand that there are multiple ways to do things, and what may work for someone else, may not work for you. Still, you should understand why this will not work for you, and accept that the advice given does not apply in your context.
There is no value in getting defensive or upset about the criticism. Rather, even if you feel defensive or upset, it is OK, and you can either dismiss the critical opinions entirely, or use them as a way to learn about yourself, your code, and your peers. Do not engage the person though in a dialog, or try to 'educate' them as to why what you are doing is right, and why their answer is wrong. Despite what you may think, this does not actually work out well. The truth is that the other person has no emotional involvement with your code, so they will not feel things the same way you do. This is human nature. Get over it, it happens.
- Criticism can be hard to take. Do not take it personally, and use it as an opportunity to learn. Not all criticism is right either, so it is OK to disagree, but do so respectfully
###Vote and Comment
The best way to 'say thanks' is to up-vote on answers that help you, and to accept the answer that best addresses what you think was important in your question.
If an answer is not helpful at all, then down-vote it.
There will often be multiple good answers, and you can only accept one. This is a known flaw in the Stack Exchange system for the Code Review site. We know that, and as a result, we also know that not everyone can have an accepted answer even if we all have good answers. You should not feel 'guilty' about accepting one answer and not accepting another. Up-vote all the helpful answers, and accept one if you feel it helped you the most.
- Votes are good for everyone and are a feedback mechanism too
###Follow up
If you got answers to your question that helped you, and you want to make changes to your question, and re-ask it with a different focus, then the right thing to do is to post a new question with the revised code.
This is a good thing. It shows how you are progressing, it allows you to focus the question in to things that were not reviewed the first time, and it fives everyone another opportunity to ask, answer, vote, and earn those mysterious internet points.
If you have used advice from a previous question to improve your code, you should consider posting the follow-on.
- If you engage personally with reviewers you will likely get a more personal response
#When things go wrong
What happens when you don't get answers, or get answers that are helpful, but don't address your main concerns?
First, be patient. Code Review normally has a few hours at least before you can expect your question to be 'cold'. If your question is still on the 'front page'
###No answers
Perhaps your question was too much to digest, perhaps it was tagged wrong, and did not attract the right audience. Perhaps even your code is perfect (though unlikely).
Possibly the concepts in your code are very complicated and can only be addressed by the most experienced reviewers.
There are lots of potential reasons for a question getting low exposure. I recommend going to The 2nd Monitor and asking for some feedback on your question.
A bounty on your question is also a good idea, but get an opinion from other CR folk in the chat room first, because there may be a better option.
- Be patient, people volunteer time, you cannot demand a response.
###More basic criticisms
If the actual answers address more basic things like style, and bugs, then fix those things, and post a follow-on.
- Understand that reviewers review the obvious things first. This likely means your code was not prepared well enough for the review.
###The wrong things
If actual answers are good, but did not address the concerns you had, then I would suggest discussing this in The 2nd Monitor and potentially offering a bounty.
- Sometimes you just don't get the right reviewer, you can be patient, or you can promote your question in some way