Docs/augment code style guide 193

[shalgrim]

One of the items from this gist of Djangonauts items was to have the coding style information from the Toga API design page changed to reference this Coding style guide and move any information only there into this one.

There is a partner issue on Toga as well as a partner PR.

Consolidates documentation for a more DRY approach

Fixes #193

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

Thanks for the PR; the code style cleanup pieces are definitely needed improvements - looks like we're running ruff, but we haven't got a ruff linting configuration in place. The set of rules from Toga would be a reasonable starting place for this.

Regarding the actual content change - PEP 8 has a whole section about method and variable naming. What do we gain from the additional paragraph here? Is this intentional, or oversight regarding what is described by PEP 8?

[shalgrim]

Linting

looks like we're running ruff, but we haven't got a ruff linting configuration in place. The set of rules from Toga would be a reasonable starting place for this.

Oh, I had assumed those changes were part of the CI linting things on my machine, but it might have happened as a result of a file watcher in PyCharm. Do you want me to back those linting changes out and create an issue to add linting configuration (starting from Toga) to this repo?

Content

Regarding the actual content change - PEP 8 has a whole section about method and variable naming. What do we gain from the additional paragraph here? Is this intentional, or oversight regarding what is described by PEP 8?

It was intentional. But I have no strong opinion on what it should be. So what follows is only an explanation of my thought process and not a defense of it or a statement of what should be.

I thought the key part that added a touch more than PEP 8 provides was

even if the underlying platforms don't lean that way

That sentiment is almost covered by PEP 8's

New modules and packages (including third party frameworks) should be written to these standards, but where an existing library has a different style, internal consistency is preferred.

But I thought it might be enough of a distinction that we wouldn't want to lose it on the merge.

Like I said, no strong feelings. I'm happy to change to something like:

In addition, BeeWare follows a "Pythonic" style, using Python language idioms (e.g., context managers and iterators) even if the underlying platforms don't lean that way.

We could even nix "lean that way" for additional clarity.