Please reconsider the rule: Pseudocode, hypothetical code, or stub code should be replaced by a concrete example?

Question

Related:

• Why is hypothetical example code off-topic for Code Review?
• Is pseudo-code alright when asking about performance?
• The gray areas of Code Review: Hypothetical / Example code

My concrete examples usually contain some proprietary things. Even a variable name or package name can convey something that is not meant to be public.

From Stack Overflow I've learnt to simplify, minimize, and isolate the problem.
(ask specific questions, MCVE, ...)

Examples of question one may want to ask:

What is the recommended way of passing arguments to a function in JavaScript?

var f1 = function(firstname, lastname) { ... };

var f2 = function(options) { ... };

f1("Michal", "Stefanow");

f2({firstname: "Michal", "lastname": "Stefanow"});

It is hypothetical code, yet in my opinion it is a perfectly valid question about best practices in terms of code structure and readability.

Another one I would like to ask personally but I cannot post it to Code Review as it is hypothetical. And I cannot include the actual code because variable names convey some meaning and I want to avoid paying hefty compensation.

What would be the best way to ask the question about following code?

Option 1:

var iammicrowave = /(microwave)/.test(navigator.userAgent);
if (iammicrowave) {
    var settings = { blah : 42 };
    magicFunction(settings);
} else {
    magicFunction();
}

Option 2:

var iammicrowave = /(microwave)/.test(navigator.userAgent);
var settings;
if (iammicrowave) {
    settings = { blah : 42 };
}
magicFunction(settings);

Option 3:

var iammicrowave = /(microwave)/.test(navigator.userAgent);
var settings = imamicrowave ? { blah : 42 } : undefined; // or maybe {} here?
magicFunction(settings);

---

Should I:

• Post on Code Review anyway?
• Post on Stack Overflow?
• Read more books?
• Make friends with developers who are better than me?

---

The actual question asked here.

Answer 1

We've all been there one time or another, so we understand what your problem is.

However, we simply can not throw this rule out of the window. It makes it unnecessarily hard on the reviewers and it would open the door for categories of questions we really don't want here. Please scour the meta for examples; I'll update this answer later with the most concrete examples if preferred.

The solution I prefer would be making a 'hobby' project which looks a lot like the real deal but with a different application. If you build a web server in a language on your work and you want to know whether you handled certain API calls correctly (just an example) but you can't disclose the code, consider writing a hobby version which contains most of the details you're interested in but isn't classified. This won't help you with the actual code, but it will point out flaws in your programming style and teach you to be a better programmer.

One of the typical things we review are variable names. If your variable names are foo, bar and f1, we will tell you to get better variable names. If you have better variable names but gave these place-holders because the actual variable names are classified, you wasted your own and our time.

And, if all else fails, consider one of the other Stack Exchange sites. There are quite a lot of them around.

Answer 2

Let me quote the help center here:

However, if your question is not about a particular piece of code and instead is a generally applicable question about…

• Best practices in general (that is, it's okay to ask "Does this code follow common best practices?", but not "What is the best practice regarding X?")
• Tools, improving, or conducting code reviews
  • [...]

then your question is off-topic for this site.

Your questions you lead as examples to allow hypothetical code are violating this rule, that is they are askin about best practices in general.

Allowing hypothetical code would breach this distinction, and as such I think hypothetical code being off-topic is just a consequence of this rule.

Code Review cannot provide a collection of general best-practices, while also providing guidance for specific questions. Additionally questions asking about hypothetical code are often too broad or unclear.

Context is extremely important for codereview. That said, there is a possibility to ask your questions anyway.

You could rewrite the variable names specifically for Code Review. I know that this has been done before¹

---

¹ As far as I know it's the less common case, though. e.g.: this vba question

Answer 3

Looking at your profile on the main site, it seems that you have not yet answered any questions on Code Review. I think that by the time you have written a few tens of answers, then your opinion on this issue will have changed.

Source code is rarely an end in itself; it is nearly always a means to solving someone's problem. So when answering a question on Code Review, the issue that we always need to have in our minds is, how well does this code solve the poster's problem? In the absence of an actual problem to solve, there is no objective basis to build a review on. That's why hypothetical questions are off-topic here: they simply can't be answered.

To take your examples:

What is the recommended way of passing arguments to a function in JavaScript?

Recommended for what purpose? In some cases it is best to pass arguments by position, and in other cases it is best to pass arguments by name, and in yet other cases it probably doesn't make any difference. We have to see the actual case in order to answer the question for that case.

Similarly, in your magicFunction example, it really depends on the parameters taken by magicFunction, and what microwaves really put in their user agent strings, and how often this code gets called, and whether settings needs to be cached somewhere to avoid having to re-parse the user agent string, and so on. We need to see the actual details.

So what should you do?

• "Post on Code Review anyway?" — no, hypothetical code is off-topic here.
• "Post on Stack Overflow?" — no, subjective questions are off-topic there.
• "Read more books?" — a good idea, but books are not likely to help you with this kind of style issue.
• "Make friends with developers who are better than me?" — also a good idea, but no matter how good your developer friends are they won't be able to review your hypothetical code any better than we can here at Code Review!

I recommend not worrying about minor issues of style, and instead writing real code solving real problems. When you have a doubt about which way to write some bit of code, pick one way (as best you can) and see if it works out for you — do you still understand it when you come back a week later? did it turn out to have bugs in it that you might have been able to avoid if you had written it differently? was it easy to modify when your requirements changed? was it easy to debug when there was a problem? Then if you are still in doubt you can ask for a review here, and since you have real code it will be on topic.