@hoffmale Be flexible. Don't try too hard to make rules. There are plenty of questions (with Java / C# webapps, for example), that are part of a larger project that would be inappropriate to expose publicly, and where the meaning of the missing parts can be reasonably inferred.

That said, there are some Ruby on Rails questions where we only get to see one method, and it's not even clear whether some of the identifiers are variables or function calls.

Each user should make their own judgement calls about whether a question is clear enough, or should be downvoted, or should be closed. That's why it's called "voting".

@200_success: So, what can be reasonably inferred in general?

what if the inferred doesn't match the actual?

Also, I suggest that you avoid using "broken code" or "stub code" as reasons, when you actually want more context. People hate it when you accuse their code of being broken (when, to them, it's clearly working) or stub (when, to them, it's "obviously" real code).

If the intended meaning of the missing parts is obvious enough, don't be pedantic, and don't insist too hard.

If there is ambiguity, then sure, ask for (or demand) clarification.