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:

### Sections:

• This post is community wiki. You are encouraged to update, adapt, extend, and otherwise improve this question/answers. – rolfl Sep 3 '14 at 15:57
• the difference in votes cast on "before you ask" and "when you ask" indicate that at least (at the time of writing this comment) 3 people are still stuck in the first faze ;) – user28366 Nov 12 '14 at 16:44
• (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.) – greybeard Feb 2 '16 at 22:59
• @greybeard I can't speak to the rest of your comment, but the golden rule about editing code in questions is don't, under any circumstances. Leave a comment by all means, but posting code to Stack Exchange carries legal implications (licensing) which only the O.P. has the legal authority to do. – Kaz Feb 2 '16 at 23:40
• (I knew I was able to ambiguously express myself. And forget addressing…) @Zak : The After you ask answer doesn't advise the O.P. against editing at later stages. – greybeard Feb 2 '16 at 23:46
• Ahh, I understand now too. Yes you're correct, and it should. – rolfl Feb 2 '16 at 23:46
• @greybeard - please review the answer now, the second paragraph should clear things up. Fix it to be better if you see any issues. – rolfl Feb 3 '16 at 0:00
• The new paragraph should do just fine for after the first answer. With answers taking hours, even days for a first version, I'm not entirely comfortable with the Feel free to edit all parts of your question before answers are given part - but then, a question can "always" be deleted. Perhaps a description of draft retention (in Before you ask), and how it should facilitate not posting prematurely, would help. But, then, this post is long enough to have forgotten half of Before you ask by the time trying to internalise After you ask. – greybeard Feb 3 '16 at 0:26
• @Kaz See footer - "user contributions licensed under cc by-sa 3.0 with attribution required". By posting code on SE site you allow (among others) to remix, transform, and build upon the material for any purpose, even commercially. There are good reasons to avoid editing code (especially on codereview) but licensing is not one of them. – Mateusz Konieczny Oct 21 '16 at 10:33
• I agree that editing code in questions is almost certainly bad idea - the entire point of codereview site is to provide snippet of poor/not perfect code and receive comments how it may be improved. Improving code in question (beyond putting it in code block and similar) seems to be a really poor idea. – Mateusz Konieczny Oct 21 '16 at 10:35
• – Simon Forsberg May 18 '17 at 20:49

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.

### 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 or 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.

### 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, 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:

1. Describe the problem your code solves. Give enough context so that a reviewer can perhaps suggest an entirely different solution.
2. Describe what you think your code does, give a brief text-based description of the 'landmarks' in your code.
3. 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. 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.

• Perhaps an even better example of unhelpful titles would be if they contain "this code" – Simon Forsberg May 31 '15 at 16:52
• – Simon Forsberg May 18 '17 at 20:49

### 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 than 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.

### Understand human nature

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.

• Intrigued people will volunteer more time

### Decide what you want reviewed

Reviewers tend to go through a natural progression/process when reviewing a question. It goes something like this:

3. Anything obviously broken? If yes - Vote to close.
4. Was reading the code hard to do? If yes - give a 'code style' type answer - improve readability.
5. Will general refactoring help? If yes - suggest DRY, Code Extraction, etc.
6. Are there edge-cases or other more obscure bugs that should be addressed? If yes - give a non-obvious bugs answer.
7. Is the algorithm slow? If yes, suggest an improved algorithm
8. 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.

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

### 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.

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

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

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.

• If you engage personally with reviewers you will likely get a more personal response

# When things go awry

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.

• 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