@Malachi What do you think about this question? codereview.stackexchange.com/q/201755/94458

It clearly seems like size() and back() are missing (both are referred to, but no definition is included)

I know the language (C++), libraries used (none) and what the OP is trying to accomplish (making a std::vector analogue for non-movable non-copyable types).

The sane guess would be that he forgot to include those functions (which would make that question "not working as intended")

But equally, one could argue "OP doesn't want us to review that code" and we should just assume reasonable implementations and thus make a review

(In other words: If there isn't enough context, it gets hard to deduce whether some code is implemented and/or working as intended)

Before reading your answer to my latest meta question, I'd just VTC that question as "not working as intended"

But now I'm not sure anymore... "If the code fits all other on-topic reasons" would mean I'd have to be able to evaluate whether the code is working as intended.

But that in turn requires me to be able to evaluate whether there is enough context, and the earlier part of the definition of having enough context for a review states "there is enough, for someone who knows the language and the libraries that are being used, to understand what the OP is trying to accomplish"

So unless there is some obvious logic error, I'm now unable to VTC a question for "not working as intended", since the missing parts might just be not-included context (which would still be on-topic, if I interpret that part correctly)

I know I'm borderline creating a strawman here, but the circular dependency of that "enough context" definition (at least for me) is problematic.

@hoffmale Why should a reviewer have to assume anything though?

People want volunteers to help them with their code. If they can't put in the effort, why would the community have to do extra?

Not saying it's that black and white, but taking a counter stance here for a moment.

@Mast Because otherwise we'd only be able to review code that is 100% executable with complete build scripts

@hoffmale So where should the line be drawn in your opinion?

That should cover most edge cases

Oh, for #2: "any public available library" should require mention of it somewhere in the question (even if it's just a import numpy)

This way, either something is explicitly mentioned in the question (text or code) or it is missing/unspecified.

This would still allow for some degree of freedom (OP doesn't have to include everything) at the cost of some explanation by the OP about the missing parts

Yes, this would push more responsibility on the OP to state their intent

But in turn, we as reviewers have much more information to build our review on

Which should result in better reviews overall

@hoffmale I don't have problems with that.

@hoffmale Which is very, very good.

Now we somehow have to properly communicate this to OP.

@hoffmale A bit of devils advocate. Say I include a header file, so we know size() -> int, would that be enough context? What if size has an error?

No

Could you provide an example of something passing 4?

int size() { exit(1); } or int size() { throw std::runtime_error{}; } would still be valid implementations

"size() returns the number of elements in the fixed_buffer."

Ok, so it's like an English version of the code?

for the missing parts, yes

more like a specification, really

I can get behind that. I also prefer the idea of strict rules, lenient enforcement.

@Peilonrayz Definitely.

Currently the rules about it are vague and open to interpretation. We can't have that.

@hoffmale assume reasonable implementations this starts to sound like the reasoning behind stub code being off-topic. if your idea of reasonable implementation is different from theirs and you offer a review with your idea....see where I am going with this?

@Malachi So you're telling me I have to include every dependency in my question?

@hoffmale no, if it is common, and not custom you shouldn't have to

right?

So... what is "common"?

what you were saying is that it needed an implementation, but you didn't say whether there is a canned implementation or not.

your review could say something like, "with X implementation of Size() ...."

does that make sense?

IIUC now you're contradicting yourself...

"Don't assume (because it might be wrong)" is at odds with "assume a specific common implementation"

I said that the wording might lead us down a path similar to "stub code", I didn't say don't assume. it is situational.

Ok, point taken

Well... that's what I'm trying to achieve: A good set of rules

I have to get ready for a meeting, but I like having this room to be able to go through these kinds of questions. I will be here often.

Any issues with this proposal? chat.stackexchange.com/transcript/message/46240139#46240139

@Malachi What's wrong with having wording like "stub code"?

sorry, @Peilonrayz. the wording might have led us down a path similar to the stub code off-topic reason.

not the actual wording "stub code" but the wording that @hoffmale used.

@hoffmale I like that, but it needs to be Meta, so that the community can weigh in on it and decide.

Sure

just double checking before I post it there

Ok, but still, what's wrong with having wording like stub code?