# Strict requirements around code examples in questions leading to counterproductive results?

Here's a post that exemplifies my question:

Extension method to enumerate a hierarchical object

Looking at the history, all I can think of is "poor OP." Several items of note:

1. In an attempt to simplify his question, he made some edits to his code that made his code not compile. While posting code that doesn't compile can imply that someone just threw some pseudocode together, it can also be the result of legitimate actions such as making edits to production code, refactors made to satisfy commenters, etc.

2. If you look at what got OP's question closed for a while, it was the omission of a parameter name in a legit edit. All of the other code was completely valid and was easily understandable. As peer developers on a code review site, we should easily be able to infer the nature of a compilation error and as such exercise discretion in choosing to close a question. It appeared to me that a dogpile resulted over a missing parameter name.

3. Observe that OP felt compelled to modify his question so heavily as a result that it warranted a rollback. While I can only speculate on why he changed it, I am concerned that the level of scrutiny applied to code examples may contribute to users drastically changing their code and obsoleting code examples in answers.

My question really comes down to whether others agree that the means by which code examples are deemed worthy are a bit too strict and can have negative consequences. I believe we should be a bit more flexible in understanding what OP's intent is.

Why can't we either fix syntax errors for them or go ahead and answer anyway instead of using bureaucracy to force OP to edit his question? If we vote the question closed or on hold, we've put a hold on all new answers and further discussions on those answers that may actually be answering what OP is looking for, which I find very counterproductive, especially since a lot of us are in different time zones.

@Heslacher brought up a second issue with the example that I missed and I agree that it may no longer be as small of a fix as I originally thought, but the fact that I missed it and it had little bearing on my understanding of what OP was asking for speaks to the gray area that exists when OP's code doesn't compile but you know exactly what they want/need.

Consider posts similar to this example. If you legitimately cannot understand what OP is asking because the code is so egregiously bad, that is one thing, but I find that the attitude around here is generally requiring all ambiguity to be explicitly dispelled before an answer can be provided. Why don't we still answer, fixing or calling out the error instead of limiting our contributions to those solely around making the error go away?

• What would you suggest as a solution? – xDaevax Dec 19 '14 at 15:50
• I like that you are bringing this question to meta, but I am not sure about what exactly it is you are trying to say with this? – Simon Forsberg Dec 19 '14 at 16:06
• Updated with much clarification. – moarboilerplate Dec 19 '14 at 16:46
• After your update, this question popped into my head. Possibly related: meta.codereview.stackexchange.com/questions/1859/… – Simon Forsberg Dec 19 '14 at 16:56
• @SimonAndréForsberg good link. I read through the comments and understand the implications. I still believe however that a more gracious attitude and less focus on "the answer" is required for code review. After all, code review is inherently subjective, and you can see that there are generally answers all over the spectrum in terms of quality on any given post...and OP might not even choose the best for the answer! – moarboilerplate Dec 19 '14 at 17:04
• @moarboilerplate I don't really have time to write up a full answer, but I did want to point out that this is one of the exact reasons why we ask for real code as opposed to examples of a problem being faced. – RubberDuck Dec 19 '14 at 17:07
• @moarboilerplate What exactly do you mean by less focus on "the answer"? Code Review is subjective, yes. Sometimes it is hard to choose "the best" answer, and now it feels like you are talking about this old meta question - what is it that you are trying to say with this? – Simon Forsberg Dec 19 '14 at 17:14
• @SimonAndréForsberg I was only using that statement to illustrate my position on the link you posted, that users highly prize and wish to preserve a primary emphasis on deductive/convergent thinking. Functionality in code review to choose an answer that rewards users reinforces that mindset. However, since code review is inherently subjective and users already face difficulty reconciling the two as evidenced by the link you just posted, that philosophy, which is apparently a founding principle of this site, has a much shorter way to go before providing diminishing returns. – moarboilerplate Dec 19 '14 at 17:49

In an attempt to simplify his question,

So my first thought is: Should the question really have been simplified? Was there any comments suggesting that it should? On Code Review, we do want the actual code, we do not want any simplifications or any short and simple examples (like Stack Overflow).

he made some edits to his code that made his code not compile. While posting code that doesn't compile can imply that someone just threw some pseudocode together, it can also be the result of legitimate actions such as making edits to production code, refactors made to satisfy commenters, etc.

If you look at what got OP's question closed for a while, it was the omission of a parameter name in a legit edit. All of the other code was completely valid and was easily understandable. As peer developers on a code review site, we should easily be able to infer the nature of a compilation error and as such exercise discretion in choosing to close a question. It appeared to me that a dogpile resulted over a missing parameter name.

It is the original poster's responsibility to make sure that the code - as it is posted on Code Review - is working. If there's a missing parameter name, then we can be assured that the code in the question is not a copy of the original code in the OP's IDE. What other mistakes can there be?

A question I sometimes ask is:

If it is not, then how can we tell what is real and what is not? (OK, it doesn't have to be "all your code", it is OK to ask for portions of something. The code doesn't have to be compilable for everyone, but it should be compilable for the OP)

The code asked in a question on Code Review and the code that was ran in an IDE and that the OP has checked that it works - both versions should match.

If you're asking for a review on code that technically does not exist, then the answers you get can differ quite a bit from if you ask about the code that you actually have.

Observe that OP felt compelled to modify his question so heavily as a result that it warranted a rollback. While I can only speculate on why he changed it, I am concerned that the level of scrutiny applied to code examples may contribute to users drastically changing their code and obsoleting code examples in answers.

The whole question was edited a bit much, and it felt like it was an edit for iterative review purposes. The entire question started to get confusing, so I wanted to slow the question down a bit. I added a comment to the question and pointing to the link above, and another person (which I communicated with in the chat room) rolled it back.

Looking back at it now, perhaps this time the rollback wouldn't have been necessary, but I also felt that the actual edit that was rolled back wasn't necessary.

### What we can all learn from this

When posting code here in a question (whether it is an edit or an original post), take your time, don't be too hasty. Make sure that the code, as written in the question, hasn't diverted from the code that you actually have been working with.

Why can't we either fix syntax errors for them or go ahead and answer anyway instead of using bureaucracy to force OP to edit his question?

Code Review is not Stack Overflow. We are getting enough off-topic questions already. We do not want people to get the impression that we can help them fix their code when they know that it doesn't do it's job.

Admittedly, sometimes I do help them fix their problem, or give them a push in the right direction.

• I agree with your post. For what it's worth, I believe the rollback was necessary, actually, but like you, what I'm interested in is what led OP to update it. It's kind of a sticky requirement to say on one hand "this must be the code you are working with" but still require continuity on the other hand--OP could be making significant edits in the meantime. – moarboilerplate Dec 19 '14 at 16:48
• What you're asking for re: how do we know this is op's working code in his IDE? may be a bit pie-in-the-sky. Many times code has to be simplified, edited, dependencies removed, etc. to make it both palatable and "versionable" in that OP can't copy the whole app into the post. – moarboilerplate Dec 19 '14 at 16:52
• @moarboilerplate As I wrote in my answer: it is OK to ask for portions of something. The code doesn't have to be compilable for everyone, but it should be compilable for the OP. Also see the edit I made at the bottom. – Simon Forsberg Dec 19 '14 at 17:01
• I wholeheartedly agree with your statement about not fixing code when they know that it doesn't do its job. If a post appears to be doing that I ignore it. – moarboilerplate Dec 19 '14 at 17:06
• @moarboilerplate if a post seems to be doing that don't ignore it. Down vote it. – RubberDuck Dec 19 '14 at 17:08
• not enough reputation – moarboilerplate Dec 19 '14 at 17:09
• Ahhhh my apologies @moarboilerplate. But stick around a little bit and you will. – RubberDuck Dec 19 '14 at 17:12

If you look at what got OP's question closed for a while, it was the omission of a parameter name in a legit edit. All of the other code was completely valid and was easily understandable.

That is just wrong. The code in question had been this

public static class MyObjectExtensions
{
public static IEnumerable<MyObject> FindAllObjectsRecursive(this MyObject )
{
var objects = new List<MyObject>();

foreach (MyObject innerObject in objects)
{
}

return objects;
}
}


now leaving aside the missing parameter name, the whole method could be replaced by

public static IEnumerable<MyObject> FindAllObjectsRecursive(this MyObject )
{
return new List<MyObject>();
}


that's why I had left a comment that he/she should recheck the method.
After about 30 minutes I added another comment because of the missing parametername and after waiting another 15 minutes I voted to close.

• Fair; I hadn't even noticed the second error, which is kind of what the spirit of my question is. In scenarios in which we can easily figure out what OP is asking, should we be a bit more forgiving? Or at least fix the code to what OP obviously intends for it to be instead of voting to close? This may no longer be a good example because the issue you called out does make the code start to border on confusing for those less-experienced who happen upon the post. – moarboilerplate Dec 19 '14 at 16:25
• I guess it isn't a problem for an OP to fix his/her question after getting closed. After editing the question will be in the reopen review queue. – Heslacher Dec 19 '14 at 16:30