I have a project I am working on, and I would like some, or all of it reviewed, how can I ask for this review on Code Review in a way that produces the best possible value?
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.
For a more technical discussion on how to compose the question also see this:
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.
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 have about your code.
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 'concept' tag that extends beyond just a single technology or language. People 'follow' tags, and many reviewers can answer 'concept' 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.
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, when questions are presented on the front page, or in search results, code-first questions often look ugly:
A question that looks interesting in the first sentence, often summarizes much better:
Also, try to:
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.
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, then try to include only the 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. However, you should try, whenever it is possible, to provide everything required to compile/run your code on its own (sometimes, just a missing import or include can be a pain for a reviewer). It is much easier to suggest an enhancement to the code when one can check that everything seems to work fine once the code is changed (for that reason, unit tests and/or examples with expected output are always welcome - also, they help to describe what your code is supposed to do).
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.
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:
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.
Even though most people will spend just a few minutes looking at your question, if you 'hook' them with an interesting problem, intriguing concept, or some other 'sparkle', then you will likely be able to get them to volunteer more time for their answers.
Use this to your advantage. Find something in your code that you find interesting, and ensure that you find a way to express that in a catchy way when you write the question. People will want to help you if it is interesting to them too.
Reviewers tend to go through a natural progression/process when reviewing a question. It goes something like this:
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).
So you have asked a question, how do you ensure it succeeds?
Note: there are two sets of rules for editing your question - one set applies before there are answers to your question, and the other set applies when it has already been answered. Feel free to edit all parts of your question before answers are given, but read up on the restrictions for after answers arrive
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.
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.
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.
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 gives 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, and that improvement represents a substantial change to the code (warranting a new code review) you should consider posting the follow-on. Be aware that substantially similar code posted for re-review could leave reviewers wondering, "why is this being posted again?" On the other hand, most reviewers find it gratifying to see that their time spent reviewing the original code resulted in you being able to really improve your code.
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' then you should probably avoid complaining or pestering people.
Perhaps your question was too much to digest; perhaps it was tagged wrongly, and did not attract the right audience; perhaps your code is actually perfect!
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.
If the actual answers address more basic things like style, and bugs, then fix those things, and post a follow-on.
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.
You are encouraged to […] improve this question/answers- sure, but how do I know a change I think beneficial in fact is?) I didn't find strong advice against editing code presented in the question after a grace period (5 minutes? 13?), let alone the first answer referring to it. -- Would an indication of the proficiency level in written English make a useful addition to the user profile? (Nothing non-controversial beyond native speaker crossed my mind.) \$\endgroup\$