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 ...
How to NOT write a zombie.
A zombie is a question that remains unanswered. As a question asker, your goal is to avoid writing one.
Beyond meeting the on-topic requirements, I think "good CR questions" can be broken down into several question types.
This answer is longer than I would have liked, but there are pictures.
Code is not malicious (guns don't kill). It is the way that code is used that makes things a problem. I am certain that every piece of 'malicious' code has an 'angelic' corollary.
If code can be 'malicious' then computers are 'malicious', and operating systems are 'malicious', and networks are 'malicious', etc.
If I feel that the code in a particular ...
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 ...
I think that such question should clearly state that it is a follow-up question to a previously asked question.
A good follow-up question should include, in my opinion:
Which question it is a follow-up to
What changes has been made in the code since last question
Why a new review is being asked for
If a question does not include (at least some of) these ...
No code in the question
Very easy to test for. If there is not a single formatted full line of code in a question:
Code Review questions must include the code to be reviewed in the body of the question.
Make the code as clean as you can before submitting it for review.
The more work you put into your code, the more you're likely to get out of review.
That's because reviewers (especially the volunteers here) have a limited amount of time and energy to put into a review. If they have to spend their time pointing out basic issues such as lack of ...
After you ask your question
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 ...
When things go awry
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.
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 ...
Is it a best practice to include things like function documentation and inline comments when posting code for review?
If you normally document your code, then include the documentation when posting here.
If you normally don't document your code, then don't add documentation just for the sake of posting it here.
We prefer to see the code as it was written.
No it doesn't have to be clean.
It can get reviewed, but people will point those problems out. If you know they are bad you should probably clean them, that way we won't badger on about them, and more about bits you don't know how to improve.
So it's best if you do clean it, but not a requirement.
Hypothetical code makes poor Code Review questions, which produce poor answers.
For example, here is a code excerpt that made a poor Code Review question:
bool f(const string& key, const string& value)
// some codes for input check
exec_cmd("cmd %s %s", key.c_str(), value.c_str());
// some codes for making return value
bool f(const ...
There's way too many cases to consider here, we should apply Machine Learning to this to make a machine learn what makes a question likely to be a bad question.
I have recently studied Machine Learning, and to me this sounds like a multi-class classification problem, to which it is possible to apply Logistic Regression, and/or Neural ...
Code Review is not like other Stack Exchange sites. Other sites create a 'corpus' of reference questions and answers to problems experienced by people in those specific subject areas. This difference is most clearly seen in the handling of Duplicates. On other sites, questions that are the same, or similar to other questions are closed as duplicates.
If the question has been answered, you must not edit it in a way that would invalidate the answers; that is not permitted on Code Review.
If the question is still unanswered, and the bug is easily fixed, then edit (consider temporarily deleting the question if the edit will take more than a few seconds, e.g. due to testing).
If the bug is non-trivial, then ...
Answering your direct questions first:
.... or posting links to GitHub instead of code chunks, etc.?
The keyword you use here is 'instead', and the answer is 'no'. You cannot post questions here with links INSTEAD of the code. You can post questions with both the code, and the link though, if you want. Only the code you post in the question is for review ...
Title contains "this * code" or "do* this"
Every single question with "this code" or "this [language] code" in the title has been retitled, closed, and/or downvoted; some have comments asking for clarification.
The same goes for "do this" or "doing this". (The wildcard used for the Data Explorer query is crude and catches more titles than a properly ...
Yes, if you have automated tests, please include them.
Some folks will take the posted code and paste it into a dev environment/IDE and make changes there (so they can ensure that their answer has the correct syntax). If you include your test code, reviewers can be bolder in their changes with less concern that they have broken something.
I wasn't one of the downvoters, so I can only speculate.
However, it is site policy to include textual summaries of programming challenges. This policy was actually instated when Project Euler went offline for some time. So, the first thing you can do is include descriptions of the problem that you're trying to solve.
The next thing you could do is take ...
The problem is not the number of follow-up questions. The problem is the rate of posting them. If you post a follow-up once a week, probably nobody will even notice. As long as it's well done, for example by following the great tips in this other discussion.
Posting follow-ups too soon is not good for anyone:
Posting too fast is not good for you. Given ...
Title that looks like a question
The following patterns in a question title predict a problematic post:
…? (i.e., a title that ends with a question mark)
The tip could say:
Titles that contain a specific question are generally inappropriate for Code Review. Please see How to Ask.
I think that this ...
The line between real and hypothetical code is sometimes blurry, but I would consider this code sample to be on the wrong side of the line for Code Review. Code that contains Foo or Bar identifiers is generally an indicator that you are withholding something from us. We would have to speculate as to what you really mean, which makes reviewing this code ...
Just one note, if I would see this as an entirely new user:
Titles that contain a specific question are generally inappropriate for Code Review.
I would be very confused. If I would come here from other SE sites, this goes against how most other SE sites work. I think it would be good to specify what we do want here. Something like:
I have my 'pet theory' about Code Review. This is my personal theory, and it is about human psychology, so you will have to take it with some salt..... It goes like this:
You post code for review, and...
noone knows how good you are as a programmer
they do one of two things:
find the most glaring problems in your code, and identify what they think will ...
I think that there is also a legal reason for this: whenever you post something to a Stack Exchange site, you release it under the CC-BY-SA license. If the author doesn't post the code here, but to some other site, then they most likely didn't release it under that license. And you, as someone who didn't write that code, have no right to do that.
Like all questions on Code Review, there should be enough detail in the question to determine what the desired implementation should be. Good questions have a good description.
The Project Euler situation highlights this need as now some questions have no description.
Just like we require questions to contain the code-to-be-reviewed embedded in the question ...
To answer the surface question, "Is it too easy to post your code for review?", the answer is an emphatic No. It certainly is not too easy to post code for review. I don't think it could be too easy. In fact, it should be as easy as possible to come to our community and ask a question in my opinion. I'm not saying there shouldn't be barriers to entry, but ...
Not a problem
If it would be a problem, you wouldn't be allowed to use someone else's libraries either.
That rule is there to prevent people from dumping code that they don't understand and/or 80% copied from the internet. We can't review that for a whole lot of reasons explained in other meta posts, enough of them already visible in the 'Related' section ...