-1
\$\begingroup\$

Consider this question - https://codegolf.stackexchange.com/questions/15412/spell-it-per-the-nato-spelling-alphabet

The 4 downvotes confirm that it is a bad question but there isn't a specific enough reason in the close-vote box.

  • It's not a duplicate
  • It's not off-topic. It does have an objective winning criterion (code-golf)
  • The main requirement is clear enough.
  • It's not too broad.
  • It's not opinion based.

The correct reason IMO would be "Not well-defined" since the question lacks specific IO requirements.

I guess that leaves the "other" option in off-topic.

Should we have a close-reason of the type "Requires stricter rules"/"Not well-defined" for questions like these?

\$\endgroup\$
  • \$\begingroup\$ I could go with "unclear" or "not objective enough" \$\endgroup\$ – John Dvorak Apr 11 '14 at 18:26
  • 3
    \$\begingroup\$ I voted as "unclear what you are asking" \$\endgroup\$ – Mhmd Apr 11 '14 at 19:02
8
\$\begingroup\$

If the specification is unclear---like say the IO requirement is underspecified---then why not go with "unclear what you are asking"?

You seem to have dismissed that as a reason because "the main requirement" was clear, but the thing is that if you were specifying a bit of coding without saying how it would interact with the rest of the system you would be more likely to get something that did not do what you intended as to get something that did.

Writing specs is a skill and takes attention to detail.

My personal (that is, not diamond powered) opinion that the challenge has to be clearly specified before it is clear, and that includes things like

  • sub-program versus stand-along code
  • input and output formats

For real code it includes things like exception behavior and error handling too, but we usually allow [code-golf] entries to cut corners in those areas.

Still going with my opinion...

The thing I have found most frustrating about a lot of challenges on the site recently has been how little effort authors have been putting into them. Some of them are less specified then the problem in a "learn to program" book, and wouldn't be treated as appropriate for scrawling on a cocktail napkin over drinks by serious programmers.

Ghaw! Err! ::gnashing of teeth::

\$\endgroup\$

You must log in to answer this question.

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