Help a new user avoid being off-topic

I am new to Code Review (but not new to Stack Exchange in general). I'm puzzled by the reasoning for putting this question on hold and would like some advice on how to be on-topic in this and future content I may post. I've read the links on how it is supposedly off-topic, and I simply can't understand how they apply to my post.

Is there any way we can promote more helpful explanations to avoid totally mysterious close and hold actions that don't do anything to improve the quality of a user's posts?

The problem in your question is that your code looks simplified just for posting it here. Although you state that it is real code, the name ProcessCommand() is a very generic name and leaves us asking "What kind of command is being processed"? What is the purpose of this code? Why did you write this code in the first place?

The code in your question looks like it's a small part of a method. If it is the complete body of a method, you could also include the function declaration of this code.

I'd also recommend taking a look at Simon's Guide to posting a good question.

• Per this answer and similar comments on the original question, I have added more context that I hope will clarify why this relatively simplified-looking code is actually a full real function in my program. I appreciate any follow-up thoughts you may have. It would be nice if such prejudice could be avoided - kind of an unreasonable expectation of a first time user to foresee that people are going to jump to the wrong conclusion about some code. But at least I think I understand why they did now, and how I might avoid it in the future. – BlueMonkMN Dec 27 '17 at 15:58
• Now Hosch250 has rolled back my context, eliminating my explanation. Why is this site so frustrating? The question was put on hold presumably so it could be improved. So I improved it, then my improvements get rolled back. Whats going on here? – BlueMonkMN Dec 27 '17 at 16:01
• Hosch rolled back by mistake, he just undid his revision (I was about to roll back his edit myself). Probably the code change prompted our chatbot to warn about a potential answer-invalidating edit, and Hosch wrongly reverted the edit (answer-invalidating edits are very common and routinely rolled back), and fixed it. No harm done! Thanks for adding that in, IMO the question looks good now. – Mathieu Guindon Dec 27 '17 at 16:27
• @BlueMonkMN We prioritize preventing answer invalidation more than fixing off-topic questions, however, I don't think your edit invalidated any answer so the rollback was also rolled back. We have some special rules here that don't exist on other sites (no example code), and some other rules that we apply harder than other sites (preventing answer invalidation), I guess that's what makes this site sometimes feel so frustrating. When all is well though, I promise that we aren't that bad. – Simon Forsberg Dec 27 '17 at 16:27
• Glad to see higher powers are on top of the situation, at least; thank goodness for meta! :) – BlueMonkMN Dec 27 '17 at 16:46
• @Mat'sMug That's partly my fault. The edit appeared invalidating on first sight but explaining why would be too long for a comment. As for avoiding prejudices BlueMonkMN, It's not as simple as that. So many people simply don't read the help articles we provide and instead want to defend their question (while clearing up the confusion would be more constructive), we can't read intent from comments. Every once in a while, somebody misinterprets and/or misjudges. That's not prejudice, it's human error. – Mast Dec 27 '17 at 16:59
• @Mast Sorry, I wasn't referring to personal prejudice, but rather pre-judging the nature of the content without understanding it fully. I guess that's a weighty word these days. I'm having a bad day at communicating clearly :). – BlueMonkMN Dec 27 '17 at 17:26

In a comment, you wrote:

this relatively simplified-looking code is actually a full real function in my program.

If you look around the site, you will notice that very few of the questions are single functions. And most of those that are are self contained. E.g. this question. The input and output are clear there.

I have the following questions reading your original question:

1. What input and output does your function take? I'm still not sure after the edits. Part of this may be C# — I don't know anything about how C# works.

2. What does ProcessCommand() return? It's hard to know what ContinueWith does if I don't know in what class it is.

3. What's a t?

4. Does Wait do more than its name?

5. For the revised version, what does onClick have to do with anything?

More context can make this more obvious. Ideally a question should be self-contained. If we can run it, it's much easier to understand how it works and modify it.

Sometimes people use explanation or comments to fill in the gap. So you might say ProcessCommand() returns a ... which has an interface as described at this URL. Here's what t is. Etc.

There is an argument that there is still insufficient context to review that code. That you already have an answer is probably the strongest counter-argument.

In the future, you may want to spend more time thinking about how people will see your code. Can they run it? Do you describe the input and output? If you can't post all the code within the 65k character limit, can you post a runnable fraction? Perhaps you can write a test harness for the code (both good practice and makes reviewing easier) so that the code can be run separately from the application.

• If I answer those questions maybe you can help determine if that info should have been incorporated into my question: 1. There is no input or output. SendCommand is just there to trigger another function that reads information from a field on the UI, and, based on its content, change global data. It may pop up a dialog in the process, thus the async behavior. 2. ProcessCommand doesn't return anything. It's the function doing the work described in #1. 3. t is an anonymous function parameter representing the async task that was executed. 4. Wait is a .Net task function that wraps up async. – BlueMonkMN Dec 28 '17 at 15:57
• 5. onClick is mentioned because it explains why SendCommand exists as a synchronous function instead of having callers just directly call ProcessCommand. Apparently Android/Xamarin cannot call async functions, so I had to wrap the async ProcessCommand function in a more conventional synchronous function. I think in order to understand and answer this question you really have to understand C# syntax, including async keywords and related framework, and maybe, to some extent, Xamarin Android framework. I suspect that this question makes more sense to someone familiar with all that. – BlueMonkMN Dec 28 '17 at 16:01
• I should qualify "ProcessCommand doesn't return anything." Technically it returns an async Task object, which is part of the .NET framework and is required by any function labeled with the async keyword. But in the context of an async function, it's not returning any value to an async caller. It only returns the Task object that would be returned to a synchronous (non-async) caller. All you need to add to make the code runnable is: void ShowMessage(string s) { } async Task ProcessCommand() { } but that would be irrelevant stub code so it doesn't belong in the question. – BlueMonkMN Dec 28 '17 at 16:42