# How much research effort is expected when posting a Code Review question?

On Stack Overflow, the community consensus for research before asking is:

A lot. An absurd amount. More than you think you are capable of. In fact, asking a question on Stack Overflow is the absolute last thing you ever want to do. You want to avoid it at all costs. You want to think of it as a horrible shame that will forever haunt you and pass down from you to your descendants. You want very much to find your answer some other way.

What should the standard be for Code Review?

So far, it seems to be that any on-topic question is acceptable. We just answer it anyway, even if it is boring. Should the standard change, now that Code Review is a more mature site and we already have a lot of implementations of some common tasks?

Does it matter if the poster is a ?

Does it matter if the code is about a very common subject, such as ?

Does it matter if there is a specific concern raised in the question, such as ?

Should the standard be higher for a question that already has a similar answer on this site?

If you think that there is a research threshold, how do you react to questions that don't meet that threshold?

• For the sake of clarity, let's focus on research about the code in question, and ignore presentation quality (whether it is well formatted, conforms to our How to Ask guidelines, etc) for now. – 200_success Jul 6 '16 at 20:30
• How do you define research? On most SEs research is to solve your problem and avoid duplicating questions, but here two copies of Project Euler 24 or whatever are fine. Do you mean looking for through other answers and taking that advice? – Fund Monica's Lawsuit Jul 7 '16 at 3:58
• @QPaysTaxes I'm asking, for example, whether "I've written a naïve literal implementation of Project Euler 24, but it's taking forever" should be welcome, if there are already reviews on this site that tell you the trick. I'm opening a candid discussion, not necessarily bound by precedent about the way we have been doing things. – 200_success Jul 7 '16 at 4:03
• Is this post just wanting us to put the current community consensus into words? Or are you challenging the current community consensus, with two briefly mentioned reasons that takes up a hundred odd characters? Your question just doesn't tell me what you want out of this question, and why you're asking this. – Peilonrayz Jul 8 '16 at 14:58
• @JoeWallis As noted in the comment above, I'd like a candid discussion. It's not about what I want; I want to know what you feel. – 200_success Jul 8 '16 at 15:01
• The only 'research' required here is working code and a description of what it's supposed to do. Did you have anything else in mind? – Mast Jul 11 '16 at 11:48

I don't think that there is a minimum level of code quality that people should have to meet. Other than working of course. Bad code can make for good reviews.

And I don't think that the primary benefit of Code Review is about finding solutions to problems. I.e. if I want to write code to find the largest palindrome product (Euler 4), I don't think that I should have to look at other questions. (I do think it is reasonable for answers to point to answers to other questions as part of a larger review.)

To me, the primary benefit of Code Review is that the asker has certain habits. If those habits are changed or redirected, then I would find it easier to work with that person. So the primary purpose of Code Review to me is to expose habits of thinking to critique. Some of these habit critiques will be pedantic. Some will be substantial. Some will involve showing clever solutions to interesting problems. Only the last of those three could be solved by research.

To answer your question, I don't think that not having the tag should draw a higher standard.

To my mind, the only way that a Code Review question can show lack of research is to be malformed. Code not working. Title not a summary of the code's purpose. No problem statement. Insufficient context. Etc. But your comment suggests that you don't want that discussion here.

Code Review isn't Stack Overflow. I don't think that we should try to reject our staple questions in favor of Stack Overflow style canonical questions. I'd rather make an all star site where we migrate all the truly great questions/answers that exemplify solving a particular problem.

• I agree, with one caveat -- I think people should be encouraged to find previous critiques and apply them, though not required (and that encouragement would go in the comments, not as an answer) – Fund Monica's Lawsuit Jul 7 '16 at 4:06
• While I somewhat agree with that sentimentI find one of the greatest benefits of this site is 'trying it your own way / what comes intuitively' and having people tell you why that may be misguided. It's easy to see what other people have done, somewhat it's overwhelmingly the case to the point where you have no idea what is 'right' or current; it's not always evident why they've done something a certain way. I don't mind an answer providing a simple link saying: 'check out this question / answer here...they do x because y" because that is where the value and wisdom comes from. – Legato Jul 10 '16 at 15:38

By setting expectations on research we may be denying help to the people that need our help the most.

Who are our users?
We do get a lot of beginners, many of which are students. I think we help all industries that utilize software when we help these beginners. In many cases it's easy to tell when a person is a beginner even when they don't use the tag. I don't believe we should hold users to different standards. It would be very difficult to enforce.

What is the mission statement for Code Review?
After I saw this question and the two answers here, I searched the for anything that defined what Code Review was about, I looked through the help page and the tour. I can't find a definite definition. IMHO code review is about improving code for anyone that asks as long as the code is working.

What kind of research do you expect the users to do?
Every question we get is going to be different because the each person is going to write different code for the same solution. A code review is about critiquing the code being reviewed.

We get many people that haven't learned about Magic Numbers. We get many people that use 'i,j,k or x, y, z' for variable names. The Meta question you refer talks about Common Language Wikis. Meaningful variable names, using constants and use functions to decrease the complexity of the code could apply to all languages, should we have a Wiki that includes the basics? Should we add a statement to the help page that good question have well formatted code (Why is indentation important)?

• IMO Code Review is about making code slightly less wrong... whatever that stands for. – Mathieu Guindon Jul 12 '16 at 20:27
• Whether or not we deny help to people depends on how we handle the posts with low research effort. – Simon Forsberg Jul 15 '16 at 14:08

How much research do we expect before asking? For me, I would say "A bit". Do not post your question as soon as your code seems to be working. You should "review it yourself" first. Ideally, you should feel that you have done the best you could before posting to Code Review. Don't just "get it done fast".

Preferably, if you are a somewhat skilled programmer (for beginners I imagine this step is much harder), you should have read other people's questions before you post yours, and quickly scan through the reviews they got and see if you can find anything that applies to you as well.

If it is a specific question about something like SQL-injection, I'd expect that you should understand what SQL-injection is, and that you should have reviewed your own code first to the best of your ability.

If it is a and/or , then it is especially important that you do your research first. It is quite likely that you may encounter a question that has an algorithm equal to yours, and that is also asking the question about how to speed it up. Again though, this is easier to do if you are able to read and understand other people's code. The algorithm that matches yours might have been posted in a completely different language.

An important question in all of these cases, however, is: Do you want a specific answer to your concern or are you really looking for reviews on any and all aspects of the code? Although "Do you want a review on any and all aspects of the code?" is one of our "six magic on-topic questions", in practice that's not how it is handled (and it would be stupid in my opinion to close questions just because they have a specific concern instead of saying "I want reviews on all aspects of the code").

### How to handle questions with low research effort then?

Let's take a look at our options, shall we?

• Vote to close as off-topic: Questions with low research effort are not off-topic according to any of our current close reasons, and they probably shouldn't be specifically off-topic either. They're on topic but not a question that we'd really like to see on the site.
• Downvote: Unless it's a well-asked question (the most well-asked that you have ever seen?), then feel free to downvote.
• Comment: Yes! Comments are good! Post a comment with something like: "The question you are asking is very similar to others already posted on this site. Have you taken a look at what questions have already been asked here? In particular you may like the following questions: (...)"
• Vote to close as a duplicate: For questions only mentioning a specific concern I think this should be an option. For questions asking about reviews on all aspects of the code, then it's hard to be a duplicate.
• Ignore and move on: Unfortunately, this is probably the most common option chosen today. You can only review so many questions. You will probably get tired of them sooner or later.
• Answer anyway: This is also an option that is chosen quite often today. Sure, an answered question is an answered question. It's good for the site because it is one unanswered question less. It is good for you because you get reputation. It is good for the OP who gets an answer (assuming you're actually answering their concern and not just complaining about variable names when they are looking for a faster algorithm). The bad thing is that way too few people choose this option.

### TL;DR

If you have a specific question, then it may be a duplicate. (This is currently not site policy but I suggest that it should become that)

If you really are looking for a review on any and all aspects of your code, then choose one or two of: downvote, comment, ignore the question completely, post an answer.

In my opinion, it's up to the asker, below the minimum level needed to not get closed (not broken, context, ...).

However. The quality of the answers depends on the quality of the code. If you have really bad code, you'll get pointers towards rough cleaning; if you have okay-ish code, you'll get answers regarding implementation details; if you have great code, you'll get answers about usability and algorithmic optimizations and documentation. In general, that is.

So if you don't put a whole lot of effort in, you're going to get answers that will tell you things that you could have known, had you spent some effort. As a result, you won't get a whole lot of use out of the review.

But there's value in not digging yourself deeper into a hole, so we shouldn't disallow such questions.

That all being said, I think there might be value in applying this to as a trial; most of those cases, you can find a better solution BY searching. Answers are going to give away the best algorithm most of the time anyway (you either already have it, in which case you'll get algorithmic improvements, or you don't, in which case either it doesn't matter OR and the best algorithm is necessary to solve the core issue).

• You're assuming that the asker will get any answers at all... – Simon Forsberg Jul 7 '16 at 11:25
• @SimonForsberg If the question is not closed, then ~93% ( RELOAD! There are 2528 unanswered questions (92.8925% answered) - 2016-07-07) will get answers as per our answered questions percentage... so yeah, what's wrong with this assumption? – Pimgd Jul 7 '16 at 11:41
• I'm just saying, our biggest challenge doesn't lie in the approx 93% of questions that get answered (and I think that for newly posted questions, it is significantly less than 93%, remember that the number is falling), our challenge is in those question that doesn't get answered. – Simon Forsberg Jul 9 '16 at 12:51