# One Question Per Question

I voted to close this question as being "Too Broad," on account of the fact that it's actually five, independent questions. At the very least, an answer would have to address all five questions, so it's certainly unlikely to be answered "in a few paragraphs," unless you have a very liberal definition of "few."

The OP disagrees:

For as simplistic and tiny as each code snippet is, posting five independent questions would simply waste time. So, I apologize for trying to be succinct and streamline things.

Snarky no-pology aside, is this considered a valid question for CR?

• Given how short some questions on Code Review are I don't think any of those individual problems is too short to be its own review. – SuperBiasedMan Dec 7 '15 at 15:55
• An answer doesn't need to address all the independent problems; from the help centre: "Do I want feedback about any or all facets of the code?" Reviewers are free to comment on as much or as little as they would like in regard to the code. If they only wish to comment on one function in it, then they are free to. That's the beauty of Code Review. – Der Kommissar Dec 7 '15 at 16:18
• @all this is a healthy debate to have, and meta is the right place to have it. Please keep it civilized. – Mathieu Guindon Dec 7 '15 at 17:11

The size of the post should not be a major consideration. We've had questions about everything from one-liners up to the 64 kB limit.

Rather, the issue is whether there is unity in the question — a unifying theme that is more substantial than whether they are all problems from Project Euler or from CS123 Problem Set 9.

Namely, the criteria should be:

• Is there any shared code among the solutions?
• Is there any pattern that would indicate a potential for sharing code?

In this specific example, main calls the code to print all five solutions. Perhaps an answer could point out a way to extract printfn "Solution to Project Euler %i: %i".

Also, several of the solutions use the |> Seq.filter … |> Seq.max and the |> Seq.filter |> Seq.head pattern. It might be possible to write an answer that address all of the uses of Seq.filter.

Given those observations, I would give @EBrown the benefit of the doubt.

That said, perhaps a better way to ask would be to post a smaller question, wait for answers, and post another small question that incorporates the feedback from earlier reviews.

Note that in the past, I have forced users to split up questions, such as UPenn CIS 194 Homework 1, which covered credit card number validation and log file parsing.

We had questions here which had only a small amount of code in it but got rather long answers regardless if it stated no question, or only one question, like for instance "How can this be improved regarding performance?".

I don't see a problem having multiple questions in a post if they belong together targeting one "problem", but if it comes to or I would plead for multiple posts for the sake of clarity.

• "would plead for" as in "will vote to close as too broad if I ever encounter the opposite"? What's preferred and acceptable can be different. It sounds like you prefer multiple questions, but how much are you against the cases of a single question? – Simon Forsberg Dec 7 '15 at 18:51
• Like vote to close if I encounter seeing such a question again if this is consent on meta. (if this is still unclear then its the fault of my not that good english and I will try to explain this better tomorrow while I am not on my phone) – Heslacher Dec 7 '15 at 19:02

I voted to close primarily because I think there's no advantage to putting them all into one post. It creates mild confusion by putting them all together. The only benefit is reducing it to one post, but Code Review has no problem with question volume.

It would only be a problem if the OP repeatedly posted code with the same mistakes, but there's no reason they can't post one, wait for feedback and then improve the others in light of that feedback before posting more.

Arguments could reasonably be made for either side of this coin, so I'll take OP's side here and see where that takes us.

Sure, it could be 5 independent posts. But this isn't the first to combine two or more Project Euler challenges into a single post, and I'm willing to bet it won't be the last.

What if the specs were "write a program that solves Project Euler 1-5"? Wouldn't one expect something like this in such a program?

[<EntryPoint>]
let main argv =
printfn "Solution to Project Euler 1: %i" ([ 1 .. 999 ] |> Seq.filter (fun x -> x % 3 = 0 || x % 5 = 0) |> Seq.sum)
printfn "Solution to Project Euler 2: %i" (1 :: 2 :: (fibsRec 1 2 4000000) |> Seq.filter (fun x -> x % 2 = 0) |> Seq.sum)
printfn "Solution to Project Euler 3: %i" (findMaxPrimeFactor 600851475143L)
printfn "Solution to Project Euler 4: %i" (findLargestPalindrome [ 100 .. 999 ])
printfn "Solution to Project Euler 5: %i" (findSmallestMultiple [| 1 .. 20 |])
0 // return an integer exit code


I think it makes a reasonably sized question. I also think we've seen much larger ones.

I haven't reviewed the code, but the style is likely consistent between the 5 problems, and if OP made beginner mistakes, they're likely all over the code: reviewers don't have to review the thing line-by-line, they're free to address any & all aspects of the code and never obligated to cover everything there is to cover - the onus is on the OP to provide a reasonably-sized post if they want a thorough review; by combining 5 problems into one, OP ultimately made it potentially harder for them to pick an answer to accept - but it's not any harder to review than 5 distinct posts.

What's a question anyway? "One question per post" as stupilated in this meta, seems to imply that any post that's providing more than a method, or more than a class, is too broad - and I can't agree with that.

• I didn't say more than one method, I said one question. A question is one coherent unit. A code review for a reinventing-the-wheel of std::map will be huge, but coherent. The fact that you can invent an arbitrary umbrella that includes all 5 questions doesn't make them a coherent unit. And the argument for that it "won't be the last" overly board question is incredibly weak - I just VTCed a question with broken code, it won't be the last of those either, should we start keeping those too? – Barry Dec 7 '15 at 16:32
• What would you consider "too broad", if not something along these lines? – Barry Dec 7 '15 at 17:13

There are loads of posts here on Code Review having multiple questions which have not been closed as "too broad". Could EBrown have posted this as multiple questions, yes. Would that hide the fact that he want a more general review as a beginner in rather than a specific review on each question? Yes.

To me what matters is whether the concept of the question is too broad, or not. Not the actual amount of subquestions within the post. One post should primarily be about one concept, in my mind, and for this particular post the concept is: "How am I doing as far as idiomatic F# code goes?", and as thus it has the right to live.

• It's not because we didn't close questions before that it make this one valid. Community decision for what is off or on-topic can move in time and we can adjust this based on community decision. – Marc-Andre Dec 7 '15 at 18:00
• @Marc-Andre, I'm not claiming historic reasons for it being valid. I do see and understand that reasons for closing should evolve. My point is more that a lot of current questions do have a much wider scope of questions than this question, and that this questions should possibly have been clearer formulated as a review on general concepts of F# instead of review of each of the 5 problems. And in that respect, I think it's not "too broad". – holroy Dec 7 '15 at 18:12

You got a point and most opinions have been voiced already. However, one of your premises is flawed.

At the very least, an answer would have to address all five questions

No. Simply, no. Answers should state something not already stated by other answers. They can elaborate on them, supplement them or even disagree with them. But answers don't have to be complete.

Of course, if an incorrect style is used this will likely be apparent in multiple parts of the question. Mentioning this will thereby touch on multiple parts of the question as well. But it's not required.

To quote the established guide:

Simply ask yourself the following questions. To be on-topic the answer must be "yes" to all questions:

Is code included directly in my question? (See Make sure you include your code in your question below.)
Am I an owner or maintainer of the code?
Is it actual code from a project rather than pseudo-code or example code?
Do I want the code to be good code? (i.e. not code-golfing, obfuscation, or similar)
To the best of my knowledge, does the code work as intended?
Do I want feedback about any or all facets of the code?

Where, exactly does this question, and this style of question generally, not meet these criteria?

• Comments are not for extended discussion; this conversation has been moved to chat. – Mathieu Guindon Dec 7 '15 at 17:47
• Being too broad and on-topic are two different things. This question was closed for being too broad, the question(s) itself can still be on-topic. Those 6 magic questions are about being on-topic, not too broad. – Simon Forsberg Dec 7 '15 at 18:11