How should I ask a question if I don't know it has a definitive answer?

Question

This kind of question is especially common in "best practices" topics. A common experience in programming is choosing one of two apparently trivially different alternatives that "seems right" and then realizing later that the chosen option causes unforeseen issues with anything from compatibility to maintainability.

Consider the heuristic for determining the quality of a question by the quality of the answers it might receive. If the question solicits opinions, all of which are equally valid ("no wrong answer" / "no right answer"), then it shouldn't be asked. However, it is not always possible for the asker to apply this heuristic because the asker doesn't know if the question even has a right answer.

Hypothetical example:

Should I use for(i=0;i<10;i++) {code} or i=0; while(i<10) {code; i++}?

Assume this is in a language where they are semantically equivalent and have no side effects. Anyone who attempts to give something other than a non-answer (e.g. "it doesn't matter; do whichever is more readable") would have nothing to contribute other than "I prefer x." Based on the above heuristic, this question shouldn't be asked. But someone unfamiliar with the language doesn't know that. What if a for loop is 10 times faster than a while loop, but the counter is inaccessible to the code in a for loop?

Are people that strict about determining if a question is "constructive"? Is there a universally "right" way to turn it into a constructive question, e.g. prefacing it by asking "Are these equivalent or is one superior to the other? In which cases would it be superior?" How should one avoid falling into the "Stack Overflow is not a recommendation engine" trap if one doesn't doesn't know that the question solicits recommendations based on preferences instead of a commonly established best practice or an alternative that is clearly superior to another?

Answer 1

There's a very simple (?) trick, don't ask just out of curiosity but only when you have an actual, practical problem you are trying to solve. Having a specific problem means we (the answerers) have a well specified set of parameters to base our answers on, we won't be theorizing on what the elusive "best practice" is, but we will be trying to help you discover what the best practice is for your exact situation.

Answer 2

There are several cases to consider, as you mentioned. Take your hypothetical example.

1. If the question deals with a language where one really would be 10 times faster than the other, state that and state why it is the case.
2. If they are semantically identical and translated into the same code by the compiler, interpreter, etc. state that. Maybe provide assembly if applicable.
3. Otherwise, I would say vote/flag to close it as subjective. If cases 1 and 2 aren't fulfilled, it probably is a subjective difference. There are, of course, nuances depending on the language, the specific code, the readability of the code in context, etc. but some of those judgement calls may be subjective as well.

If you're the person asking the question, and you're not sure, take a step back and think about your question. Is it subjective? Can it be answered by "this is incorrect because..." or "this should be done with way because "? If so, great, it's probably a decent question (at the risk of oversimplifying...) . If it can only be answered by "I've done it this way because I like it that way..." or "my personal preference is..." it's probably not a good fit for the site.