3

This question How to write maintainable event code in C#.NET? was closed by Robert Harvey (and deleted afterwards by others). I add a picture of the question for those lacking privileges to read it:

Picture of the question

Though Robert gave a clear statement why he closed it (it contains the magic words "Is this the best way though", which can be problematic), I have issues to follow his argumentation. In my eyes, the OP already gave enough criteria what he means by "best":

  • the question title says clearly it is about maintainability of the code

  • the text mentions "readability for every novice programmer" (as well as readability for more experienced ones)

Robert asked for "specific, objective criteria". Maintainability and readibility are often to some degree opinionated - so do we now start to close and delete every question which asks about maintainability without giving a specific metrics for this?

Especially here in this question, a very specific use of C# was mentioned, which makes IMHO the focus narrow enough in my eyes.

So any suggestions how the criteria for "best" in the question could be made even more specific as it already is? Or is this just about stripping the buzzword "best" out of it?

3

At first glance the question title and first paragraph screams “too broad”. But they also contribute almost nothing to the question and could be edited away (might invalidate the answers, though).

I see some more sensible questions that could be edited into more prominence:

  • “Should every class implement exactly one interface?” That's not OP's main question but received one answer. I think it wouldn't be a great question and sounds opinion-based, but it's actually on-topic and answerable because there's a professional consensus on this matter.

  • “How should I write event handlers in C#? Should I declare this kind of interface?” On topic, and answerable iff the language's ecosystem has a clear convention. Otherwise that might still be opinion based.

  • “Should I dumb down my code for novice programmers, at the cost of writing less idiomatic code?” I'm not sure though if that would be on topic and objectively answerable. Opinions will usually fall in between “Yes – write for the lowest common denominator” and “No – lift your juniors to the level of the code”. With the occasional “it depends”. None of these contradictory opinions is per se invalid, I'd therefore close as too broad or too opinion based.

Asking about maintainability and best practices in general really doesn't work. This is not necessarily a problem of topicality but of answerability – Robert's comment is on point, see also my opinions below. The question is not necessarily sufficiently limited by focusing on one language and one subject matter for these best practices: as long as the question is more of a discussion prompt, it doesn't work in the Stack Exchange model.

It can be expected that questions clearly work out a focused, answerable question, and don't just present an amorphous blob of confusion. Unfortunately, writing good questions is a difficult skill. In some cases, more experienced community members can seek to clarify the question in the comments and suggest edits.

This question saw substantial discussion in the comments that did unearth helpful insights about OP's understanding, but none that could be used to improve the question. OP's real problem was that they lacked first-hand experience that would allow them to contextualize advice they read on some blog, and that they were deeply confused about maintainability. But those are not software engineering problems that could be solved by one answer on this site.

Background on figuring out whether a question is answerable.

Many good questions are answerable because they pose a concrete, real-world problem.

  • Here, the problem must fall within the area of Software Engineering, excluding code-level problems.

  • Problems have possible solutions. A solution either works or it doesn't.

    • Hypothetical problems cannot be solved.
  • Questions generally benefit from showing attempted solutions and explaining why they fail to solve the problem.

    • If the question already shows a working solution to the problem, no problem remains. In particular, asking for feedback about a particular solution is not a workable problem statement.
    • I think it is fine if a question asks whether some approach will successfully solve a real problem, for example where OP lacks the professional experience to understand the implications of the approach. For example: “will this design make it easy to add new event handlers, or would a different design be better?”
  • It is fine if solutions are based on professional opinion or industry consensus.
    Sometimes a particular sliver of the industry has a clear convention like where to put braces in a C# program, sometimes it doesn't like whether to use tabs or spaces.

  • If any possible “solution” is equally valid, the question is too broad or too opinion based. In particular, if the “best” solution is a matter of opinion, or if answers are likely to voice personal opinions.

    • Sometimes, a great answer is able to summarize and contrast different standpoints in the context of the problem statement.
  • The problem must be reasonably scoped so that a solution can be described in an answer. Otherwise, it is too broad.

  • The problem must effectively be answerable by a mainstream professional developer. This excludes cutting edge research topics or problems that require inside knowledge to answer (like: “Why did James Gosling decide to design Java this way or that?”).

  • If reasonably scoped, “What is X?” or “How does X work?” can be answerable questions: the problem is in OP's understanding. However, the question must still describe a clear problem statement.

    • These questions are often too broad unless OP describes their current understanding. Frequently, the issue is a misunderstanding that can be easily resolved.
    • Otherwise, such questions tend to be unanswerable and require more extensive discussion, which doesn't work here.
  • Problem statements are usually timeless. The opposite is something like “what is the best JS frontend framework in 2019?”

To decide whether a question is on topic, I consider the typical answers it is likely to receive. This doesn't preclude that off topic questions sometimes receive great, on-topic answers.

The question discussed here received multiple such great answers, but about completely different problems. That too indicates (but does not prove) that the question is too broad.

Asking about best practices in general like “what are the best practices around X?” fails to present a solvable problem, unless there happens to be an authoritative document describing the consensus on X. For example, official styleguides sometimes cover best practices. But that is dangerously close to resource requests. In absence of such a clear answer, best practice questions are almost universally to broad because any answer that mentions a best practice would be “valid”.

As mentioned above, this can be avoided by asking whether some approach solves a problem. “Does this design adhere to best practices?” is not a problem in this sense, but “Does this design successfully enable some particular aspect of maintainability?” is.

  • No final conclusion? – Doc Brown Apr 6 at 19:38
  • @DocBrown Lol, you read all that? I think aspects of the question could have been salvaged and rewritten as an answerable question, but that OP's underlying problem is unsolvable in the context of Stack Exchange. I wouldn't have deleted the question due to the answers, but closing and maybe locking it were/would have been appropriate responses. – amon Apr 6 at 19:42
  • Thanks to you and @ewan for both of your answers. It seems you both agree to me that deleting a question like this was probably not the best possible action. However, to make it a good question, someone needs to do a heavy rewrite. The OP could have done this, but I it is unlikely they will invest so much effort into an already deleted question. So maybe I should let the matter rest for now. Though I still hope to get an answer (or at least a comment) from Robert Harvey. – Doc Brown Apr 7 at 14:12
1

When I read this question the first time I thought it fell into the category of: "person confused about X has invented solution Y, but want's confirmation that its good"

I don't think its the best question in the world. But if it was "What is the correct way to write event handlers in c#" it would go on stackoverflow and get a factually correct answer with links.

We are never going to be asked perfect questions. We are going to get people feeling their way and wanting help.

It's up to the answerer to pull meaning from the question and write something helpful. Simply deleting "bad" questions is not a good response.

Reopening now, wont solve anything with the question, as the OP has probably long ago moved on and only they know what they really meant.

But I do think its good content. Others will doubtless think of the same "solution" and google it. They wont get the microsoft page on writing event handlers. Because that's not what they want. They might well find this question, its answers and comments helpful though.

  • 1
    “It's up to the answerer to pull meaning from the question” – it's also up to the asker to write a clear question that can be answered. I generally agree with your conclusion, though. – amon Apr 7 at 12:15
1

Since folks seem to continue to be confused about how I handle "best practice" questions, by way of illustration I'll offer a colorful metaphor.

Unanswerable:

How do I make the best chocolate-chip cookies?

Answerable:

How do I make chocolate-chip cookies that are soft, like Grandma makes?

We can't answer the first question, because we don't know what "best" means to the asker. The second question is clearly answerable: she stated a criteria. She wants soft cookies, not the crunchy ones you get over the counter.

That's all there is to this.

Now look at the OP's original question (paraphrased, for your enjoyment).

I find events in C# unmaintainable, so I added an interface. Is this better?

Well... we don't know the answer to that, do we? For starters, why did you add the interface in the first place? What sort of perceived benefits did you derive? Why do you think the interface improves things? And what do you mean by "unmaintainable?"

Now the OP goes on to say that C# requires a "pointer" to a method. In C#, we call these delegates. A delegate is a form of indirection. In that sense, it is just like an interface; it defines the method signature by which we can hook up a first-class method to an event (a handler) so that we can receive information when the event fires.

All of which begs the question, why do you need yet another layer of indirection? And we've come full-circle to the question I asked the OP in my original comment: "What additional value do you think this interface provides?"

Your own answer to the question essentially (and correctly) states that "you need to learn more and get better in C#" (in so many words). Which leaves me wondering, what value does this question-answer pair provide to anyone else?

  • Thanks for sharing your point of view, gives me a better understanding of what was going on here. – Doc Brown Apr 9 at 5:42

You must log in to answer this question.

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