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.
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:
- 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.
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
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.
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\$