I believe it would be valuable to create a 'canonical' question/answer of sorts for each language, and I am hoping to get others' thoughts on this.
These questions and answers would serve as a central explanation of certain common issues. All answers would still be expected to be tailored to the posted code, but the canonical answers would provide a detailed explanation of sorts. These answers could complement the specific review to reduce repeated explanations of common (beginner) issues.
In the two languages in which I am active on here (PHP, C++), there is a distinct set of common, core issues. I would go as far as to say that most questions are about 85% overlap when you consider the root issues, not the bits of code that contain the issues.
For example, go find 10 random PHP questions. I can guarantee you that at least 7 of those 10 will have an issue with globals. Additionally, each answer will have a different explanation ranging from a well focused, catered look at how it negatively affects the reviewed code to "globals are bad because I said so." Though these brief, seemingly opinion-based statements like this tend to be at most moderately helpful, I find myself doing it all of the time. It's simply too taxing on me as an answerer to continually explain the same things over and over again with just different variable and function names.
If a language-specific, central explanation of issues existed, it would mean a large decrease in the amount of "boilerplate" review necessary on the more beginner level code snippets. It would mean instead of a three page explanation of the harm of globals, I could send direct the person to an example answer and point out how it applies to them specifically. (e.g. "[globals are bad]. For example,
$db is a very common variable name. What if some other piece of code overwrote your
$db? Or, what if you wanted to be able to use the same function against 2 databases?)
What does this mean?
If the community agrees with me, it would mean people from each language getting together, carefully crafting a realistic question of purposefully non-ideal code and then creating answers to point out each of the issues.
The question would ideally cover as many common style/bad practice/inefficiency/etc issues as possible without being sacrificing a minimal level of readability and decipherability.
In turn, each answer would focus on one very specific issue and explain, in detail, what the issue is, why it is an issue, and how to fix/avoid it.
What does this not mean?
This does not mean that I would support answers simply becoming "look at the following N links."
Countless books on code quality exist. Our entire community's knowledge could be summed up by "go learn SOLID really, really well, then go find the champion for code quality of your language, and read everything they've ever written." Our value--I believe--is in our customization. We don't just tell generic tips in an abstract, contrived form, we point out very specific, very real issues in a question asker's specific code. This would of course continue to be the case. The canonical answers would function as the "why" not the what. We would still need to relate the items to the code posted, not just point them out blindly.
In a way, this is an exercise of DRY and single source of truth, and the benefits are similar. Duplication would be avoided, and best of all, as languages and best practices change, a central explanation would allow us to better reflect that. A great example of this is C++'s use of
std::size_t. Until fairly recently, it was considered best practice to match the standard library's use of
std::size_t when dealing with containers or working with sizes of your own. Recently the suggestion has became "use signed numbers unless you truly need that extra bit" due to the more natural semantics of signed numbers. There are quite a few C++ answers around on CR (including a lot of mine) that suggest using
std::size_t. At some point I will go back and fix all of these, but until I get around to it, it would nice if they linked to a central location that noted this change of best practice. Although the parts of the criticism unique to the question would stay dubious, at least there would be an explanation at the other end of the more general link explaining that things have changed and why. It would keep the misinformation at a minimum until time permits.