Seemingly arbitrary requirements

Question

This meta question is actually a follow-up of a discussion started on The 2nd Monitor about the following question: Checking if a number is divisible by 9.

To put it bluntly, the objects of interest are the requirements in the question:

I tried to develop a new way to check if a number is divisible by 9. I have written my code and it is working fine. I'm not allowed to use *, / and %.

More specifically, it is about « I'm not allowed to use *,/ and % ». Some of our dear critters deemed these requirements « silly » and « uninteresting » with actually some pretty convincing arguments. Enter the debate: are seemingly arbitrary requirements on implementation on-topic for Code Review or should the asker provide a meaningful reason for these requirements for the question to be acceptable?

Answer 1

are seemingly arbitrary requirements on implementation on-topic for Code Review or should the asker provide a meaningful reason for these requirements for the question to be acceptable?

I think two things is of importance here:

Who have those requirements?

• Is it an assignment from school?
• Is it defined in some programming-challenge?
• Is it from an interview-question?
• Is it yourself?
• Is there a technical restriction preventing you from being able to do anything else? (Not being able to use Java 8 features and similar) - These are not really "seemingly arbitrary"

I consider school assignment, programming challenge, interview question, and technical restriction to definitely be valid reasons.

So the only one left is if it is yourself that put the restrictions there, and about that, see below.

Why those requirements?

This primarily applies if it is yourself who added the restrictions.

You want to do it just because you want to see if it is possible? Okay, I can relate to that. This is a valid reason, but in some cases you might want to consider loosening the restrictions a little.

You want to do it just because you want to know how to reinvent the wheel as a learning exercise? Sure. There are quite many of those questions already.

You want to add this restriction because you feel that not having this restriction would be "cheating" or "not the right way"? Then there's probably something wrong with your assumptions.

What if no good answers to these questions is provided?

As this is not really about on-topic vs. off-topic, the only thing I can think of is: Vote to close as "Unclear what you are asking". Ask for more detail about these restrictions in a comment.

Answer 2

Code Review questions generally follow the form:

I have implemented code, which, given X input, will return Y output. How can it be improved?

To which simply the following is an acceptable answer:

You have written a lot of code, but did you know function F in the standard library already does? You should use that instead.

Followed by example usage.

A full review of the actually implemented code can be constructive as well, yes, because even if the asker does stick to the code they posted, there are still general things they can learn and apply.

Some Code Review questions might also take the following form:

I have implemented code, which, given X input, will return Y output. I cannot use approach Q for reasons R, S, and T. How can my code be improved without using Q?

These questions can also be good. But having reasons R, S, and T is vitally important to this. We must understand why Q isn't an acceptable answer because that shapes our answers.

Is Q too slow and your implementation is an effort to make a faster Q? If so, depending on what Q is, it might be very relevant to include information about compiler, operating system, and/or hardware. And either way, good answers should show how faster Q runs, how fast your implementation runs, and how fast their suggestions can make your implementation run.

Is Q not going to work because of hardware reasons? If so, it's probably even more necessary here to provide some information about the compile options and the hardware this is supposed to run on. How can you get good answers if you don't share this information with the reviewers.

Is Q not going to work because your professor says you can't use it and you're doing a homework assignment? While I'm okay with reviewing homework, I don't think it's particularly constructive or useful to the site to allow for these sorts of restrictions on answerers. If a professor has placed this sort of restriction, then the point of the exercise is to understand some lower-level concept. While I might take more time to explain why Q is better than your implementation if your question is tagged homework, I'm not going to be interested at all in a question where Q is off the table because homework.

Questions in the format simply:

I have implemented code, which, given X input, will return Y ouput. I cannot use Q.

Aren't good questions. It is important to understand the why behind the restriction of Q.

---

Code Review is about making real working code as good as possible. If there are any restrictions on a particular piece of code, the reasons behind those restrictions are important. The reasons for those restrictions can shed light on what is actually the best way to solve the problem.

Questions without plain-English descriptions of the problem tend to be closed as "Unclear what you're asking". We can primarily do this because without a plain-English description, it's almost impossible to determine whether the posted code is working as intended.

Without any explanation at all whatsoever behind restrictions, how can we be sure that either the code in the question or the code in any answer is actually meeting those requirements?

If, for example, your code is an attempt to implement a timesTen() function without using *... well what if the compiler itself is optimizing your instructions into the same thing as if we were to just use the * operator? At that point, haven't we failed to meet the requirement? And if we haven't failed to meet the requirement, then isn't the requirement unnecessary, silly, and should be removed?

The source code should be in the most readable format that will compile into code that performs the desired operations with the desired accuracy, speed, memory footprint, etc. If we've implemented some lines of source code that compile identically the same as the * operator would compile, then we've not written the best possible code, either because our source code isn't in the most readable format for the given set of compiled instructions, or because our compiled instructions don't match the requirement of not using the * operator basically.

I'm not entirely certain that questions which don't even remotely explain the reason behind the restriction are necessarily off-topic (I'm on the fence), but they certainly deserve downvotes and comments asking for explanation of the restriction. How can any answer posted have any certainty of being remotely good if the answered didn't bother to actually understand the requirement?