Simon's Guide for posting a good question
There are a lot of questions that appear on Code Review, and all questions are fighting for reviewer attention. This is a non-exhaustive list of items that I am looking for in a Code Review question when determining whether or not I should review it and how I should vote on it.
If your question is lacking a lot of the following, then it is very likely that I will down-vote it.
Is your question on-topic?
Make it clear whether or not the code works and produces the correct results.
Have you stripped your code from context before posting it on Code Review (not good!)? Is the code you are posting on Code Review your real code and exactly your real code (good!)?
Why did you spend time writing this code? Why does this code exist?
You might also want to say why you decided to post a question on Code Review. What are you hoping to improve in the code? If you have no specific wishes for improvements, just say something like "Any and all improvements welcome".
Usage code, example inputs and outputs
How to use your code? Is it a game that anyone can just copy and compile and run? Is it some library, or some methods, that should be used from other code?
If your code is some algorithm with a clear set of inputs and outputs, provide at least a few sets of input and output pairs. This will help reviewers understand what your code does, and to see what edge-cases you have already thought of.
If your code is for printing things to the console, provide an example output of what your program prints.
Don't just say "This is my code, can I make it better?". A reviewer does not want to read your code to understand what it does, the reviewer wants you to give a bit of explanation about what your code does and then the reviewer will decide if it is worth reviewing or not.
When asked to give more description about what your code does, don't just say "Can't you read the code?". You are the one who wants your code reviewed, then it is up to you to make your question interesting.
Describe the details and your approach
How did you approach the task of writing the code? How did you disassemble your problem? How did you assemble your solution? How do you eat an elephant?
There are many different ways to write tic-tac-toe or sudoku. How flexible is your approach? Do you support different sizes or other parameters? Have you used nine variables, a one-dimensional array, or a two-dimensional array?
To implement a certain algorithm, are you using a hashmap, a list, a set, a stack, or a queue...?
If you include multiple classes in your question, add a short summary about what each class is responsible for.
If you include only one or a few classes in your question, make a little list before you present your code about what functions/methods exists.
Don't assume that everyone knows what you are talking about
If you are making anything that few people know about, make people learn things just by reading your question.
If you are making a tool for something that few people know about (such as an already existing game or application), describe the context and maybe even describe why you wanted to make this tool for that game/application.
Even if your code is about something that is very common knowledge, such as playing tic-tac-toe, you can still include a link to the Wikipedia page.
Does your code do anything useful or interesting?
At least to me, reading code about interesting things (or in interesting ways) is much more interesting than reading yet another ordinary fizzbuzz.
If your code has some sort of GUI, add one or more screenshots of how it looks.
Take your time, don't be lazy
Never say "I want to do XYZ as well but I am lazy and haven't done so yet" or "I know that I should clean up the XYZ class/method but I have been lazy".
And absolutely do not say "I want to do this using XYZ instead, can you please write the code for me?"
Don't just write the code and put it up on Code Review as fast as you can. Review it yourself before asking us to review it.
Possible things you cannot use
Are there any restrictions that prevent you from using some techniques that you are familiar with, but prevented from using? (A common one is: What version of Java are you able to use? Can you use Java 8?)
Especially if there are restrictions that may seem arbitrary, provide reasons for why the restrictions exists.