Code style standardization

[dunossauro]

Create standard to define new PRs and commit.

We have many case like that: https://github.com/flask-extensions/Flask-GoogleMaps/blob/f9e55917a3cbb98199e5a0cc4bc7a4745b68dd46/flask_googlemaps/__init__.py#L223-L234

What the form is more correctly or preferable for this project?

I think the best way is to use the Black and respect PEP-8 using black -l 80

Maybe add -s flag to not normalize strings.

Another case is related to docstring standards: https://github.com/flask-extensions/Flask-GoogleMaps/blob/f9e55917a3cbb98199e5a0cc4bc7a4745b68dd46/flask_googlemaps/__init__.py#L46

In some docstrings we have parameters explanations in others not. In another cases we has things that can be replaced by type annotations https://github.com/flask-extensions/Flask-GoogleMaps/blob/f9e55917a3cbb98199e5a0cc4bc7a4745b68dd46/flask_googlemaps/__init__.py#L421-L428

We can test it in a CI using tox, or not, is only a sugestion

[vit0r]

For the dev/env vscode, we can create some settings.json rules like:

autodocstring ext

${HOME}/.config/Code\ -\ Insiders/User/settings.json
{
    "autoDocstring.docstringFormat": "google",
    "autoDocstring.includeName": true,
    "autoDocstring.includeExtendedSummary": true,
    "autoDocstring.startOnNewLine": false,
    "python.linting.flake8Enabled": true,
    "python.linting.pydocstyleEnabled": true,
    "python.linting.pylintEnabled": false,
    "python.linting.pydocstyleArgs": [
        "--convention=google",
        "--ignore=D4"
    ]
}

[Riverfount]

@dunossauro I think that the use o Blak to create a standard for the new commits a great idea. Can you do it and send us a PR?

You can work from this brach. I say it because I think to use a Feature Branch to control the flow of the work.

@dunossauro after standardizes the code with the Black, can you change the README with this code: [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)