Post History

I think this is important to consider because it doesn't only concern questions about bad practices or XY questions, but also if we should allow questions with artificial requirements or questions about code obfuscation. Currently we have no rule for/against any of this.

---

As for if we should call out dangerous practices or XY problems, this boils down to whether we strive to be an ___engineering___ site or a ___general programming___ site. 

In engineering, we always seek to follow best practices and formal or informal industry standards. On an engineering site, an answer ought to be obliged to point out dangerous practices, obsolete functionality and similar. 

Whereas a general programming site is more fuzzy and more tolerant to students/hobbyists building their own strange, non-recommended things. They could be doing so for learning purposes, or because of artificial school requirements, or even because they are doing something bad on purpose (obfuscation, code golf, illustrating vulnerabilities etc).

Another fundamental difference between engineering and general programming is that an engineer _always_ questions if the requirements make sense and they don't start on a task before the requirements are made clear. Whereas (bad) students as well as misc inexperienced programmers _never_ question the requirements (the common derogatory term for those who blindly follow senseless orders is "code monkeys"). 

If we peek at Stack Overflow, it is somewhere in between. SO has a tendency to close as unclear and/or down-vote XY problems. The requirements laid out in questions are often not questioned. Although answers pointing out flaws of reasoning and dangers with certain approaches are often well-received. Artificial homework assignments are allowed. Obfuscation is frowned upon and not well-received, even though there is no explicit rule against it.

---

To address your specific concerns and how I think Codidact should deal with them:

I think we should always prompt the poster for clarification in comments as a first step. 

Answers that may answer the question without addressing obvious problems with it, and also uses clearly dangerous or obsolete functionality should be marked with our reaction feature as "dangerous" or "outdated".

Questions can also use the "language-lawyer" tag to show that the reason behind the question might not necessarily be practical use, but to understand how a programming language work in-depth and what constructs that are actually marked as safe/unsafe by standards etc.

> Write a separate answer to contain such important caveats and anticipate common Xs underlying the Y in the question? 
>  
> Add a caveat to a canonical answer, or separately to multiple answers?

It can be a separate answer or written together with an answer that does at the same time give the "X answer". It might be a good way to illustrate why a certain method isn't good, by posting a code example explicitly labelled "bad".