Combine Best Practices and Style guides

[Wil Hall]

It may make sense to combine Best Practices and style guides.

My thoughts behind this:

• There is some overlap between the existing best practices and style guides; it still might be worth calling each out separately if they live together, but combining them makes it feel more natural to include guidelines which exist in a gray area between "best practices" and "style"
• We split the style guides up by language/framework but the best practices guides still live in a single file. Combining them rectifies that difference in structure
• It's more cumbersome to browse and maintain guides that exist in two places, but have similar content. I find myself checking both because I don't know which has the guideline I am looking for, or if adding a style guideline will overshadow something in best practices
• The graphql and data guides are at the root level of the repo; they don't really fit into style or best-practices since they contain both. They would feel more at home in a structure that combined style and best-practices guides together

I propose a structure similar to that of the existing style guides folder, but named best-practices. I see "Style" as being in the superset of "Best Practices", and best practices can apply to programming languages, frameworks, and tooling. The proposed structure might look something like:

best-practices/
  css/
    README.md
    example.css
  html/
    README.md
    example.html
  ruby/
    . . .
  rails/
    . . .
  git/
    . . .

I would love to hear others' thoughts on this proposed structure, alternatives, or reasons against combining these two types of guides.

[Daniel Colson]

This seems to fit with #606 (comment), and some PRs I opened to start removing things from the Ruby style guide (#607, #608, #609).

[Joe Ferris]

We could also potentially move them all to the root, since we also have some things like "Protocol" that are hard to differentiate from "Best Practices." The guides originally dealt largely with style concerns and only contained Ruby. They've evolved to the point now where I think a flat structure where everything is assumed to be best practices or recommendations would work best.

[Wil Hall]

They've evolved to the point now where I think a flat structure where everything is assumed to be best practices or recommendations would work best.

I like this option a lot. Having everything at the top level will help to codify a single folder for each language/framework/tool without other arbitrary hierarchy.

Tangentially related to this issue, I think that suggestion fits well with your comment:

For what it's worth, I don't feel as though any of these are worth keeping if they can't be automated.

Having everything in one place at the top level encourages us to keep guides short and specific and outsource anything we can automate, and remove anything we don't care about enough to automate.