The currently highest voted unanswered question is, well, unanswerable. As Martin said one year ago, "there is actually nothing here to review" and "the actual code is missing as are some other parts like the definition of enum_length".

The question has been voted to be closed several times, and every time the review queue votes to leave it open. Now, all those votes are based on personal preference, I guess. Some might see the high number of votes, the clear code style and say "this question is perfectly fine".

However, this particular question doesn't contain the necessary parts to get fully answered. Whether the "compile-time check[..]" works depends on enum_length. The original author has asked at least one question about the implementation of SETUP_ENUM_LENGTH, but our rules dictate that the code must be included in the question itself, not in the context of the question. Also note that DEF_ENUM was taken from this answer without proper attribution, but whether or not a three line snippet needs that isn't really part of this question.

At least from my point of view the question lacks critical context and therefore should get closed. But that's my opinion. So I'm wondering: why is this question still open?

  • \$\begingroup\$ Possibly relevant: codereview.meta.stackexchange.com/q/502/23788 \$\endgroup\$ Mar 30, 2018 at 14:17
  • \$\begingroup\$ Also: codereview.meta.stackexchange.com/q/6904/23788 \$\endgroup\$ Mar 30, 2018 at 14:22
  • \$\begingroup\$ @MathieuGuindon I'd concur, but enum_length is part of the interface via SETUP_ENUM_LENGTH. One could review the interface solely, but it's missing its documentation, so a review would most likely end in "that looks nice, but I have no idea what your code is supposed to do in scenario XY". It's not possible to review DEF_ENUM, though. \$\endgroup\$
    – Zeta
    Mar 30, 2018 at 14:28
  • \$\begingroup\$ I think it's a good point that the queue, full of people that might be unfamiliar with the language or even concept, keep it open because it seems fine (I'm guilty). This is one of those cases where a custom note in the close reason goes a long way. I can't see what was put as the close reason in the history, so maybe that did occur. I just mean that this is a good learning experience for users and can probably be referenced as an argument for writing a close reason. \$\endgroup\$ Apr 11, 2018 at 20:55

1 Answer 1


I have long been uneasy about this opinion that interfaces are reviewable. In my opinion, it conflicts with the current site standard, which is that stub code is off-topic.

I suppose that it might be possible to ask a good Code Review question about reviewing an interface, but this question, which has just one usage example, doesn't contain enough detail to proceed with a useful review.

I have closed the question for the "Lacks concrete context" reason.

  • 1
    \$\begingroup\$ I've added a link in the comments to this discussion. I concur, there's not enough detail. If the interface was documented or there were reproducible use cases it would have been fine from my point of view, but it's neither :(. \$\endgroup\$
    – Zeta
    Mar 30, 2018 at 15:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .