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 };
} else {

Option 2:

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

Option 3:

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

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.

  • 5
    \$\begingroup\$ It doesn't sound like you entirely understand what the topic of Code Review is. It's not about getting general advice, but specific advice on particular code. General practice advice isn't the intent, as said in the help centre. \$\endgroup\$ Oct 15, 2015 at 10:00
  • \$\begingroup\$ Or maybe I understand (partially, not entirely, in my own way) and want to challenge status quo? \$\endgroup\$ Oct 15, 2015 at 10:03
  • \$\begingroup\$ I see, the title makes it sound like you're only concerned with the particular close reason rather than looking to change the scope of the site. \$\endgroup\$ Oct 15, 2015 at 10:04
  • 2
    \$\begingroup\$ Unfortunately, the rule is necessary. In this type of situation, you have 2 options (already mentioned in the answers): Either obfuscate any sensitive names / text / etc. and Make it clear that you have done so, or write a separate non-sensitive project using the same structures and have that reviewed instead. \$\endgroup\$
    – Kaz
    Oct 15, 2015 at 10:13
  • 2
    \$\begingroup\$ The site did once allow these questions, but not anymore. Also, both SO and Programmers address such questions in different ways, so there's really no need for a third site (again) to allow them. Plus, no other SE site reviews real code like us, and those two sites certainly won't start doing so. \$\endgroup\$
    – Jamal
    Oct 15, 2015 at 15:59
  • 2
    \$\begingroup\$ +1 for a well researched, well written question. I don't agree that it's a good idea, but thank for taking the time to bring it up in such an intelligent manner. \$\endgroup\$
    – RubberDuck
    Oct 17, 2015 at 12:26

3 Answers 3


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.


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

  • 1
    \$\begingroup\$ Oddly enough, the comments on the other answer to that question are a really good example of why we don't allow hypothetical code here. \$\endgroup\$
    – RubberDuck
    Oct 17, 2015 at 12:25

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.

  • \$\begingroup\$ it seems that you have not yet answered any questions - well... I had a few questions about recommended style, but cannot publish actual code, because the variable names are confidential. So I decided to obscure them but then no good... \$\endgroup\$ May 7, 2018 at 11:08
  • 3
    \$\begingroup\$ If you are working on confidential code for a company, then get your colleagues at the company to review it. They know more about the context of your code than we do. \$\endgroup\$ May 7, 2018 at 13:55
  • \$\begingroup\$ I didn't fancy interacting with them, all busy. Besides they have their own views and I wanted to provide independent data point. \$\endgroup\$ May 8, 2018 at 15:07
  • 1
    \$\begingroup\$ If you have confidentiality issues, instead of posting generic or hypothetical code, find some other way to make it concrete. Basically the same advice that @Mast gave. \$\endgroup\$ May 8, 2018 at 20:51

You must log in to answer this question.

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