PyPI 官网下载 | wemake-python-styleguide-0.4.0.tar.gz

# wemake-python-styleguide [](https://wemake.services) [](https://travis-ci.org/wemake-services/wemake-python-styleguide) [](https://ci.appveyor.com/project/wemake-services/wemake-python-styleguide) [](https://coveralls.io/github/wemake-services/wemake-python-styleguide?branch=master) [](https://pypi.org/project/wemake-python-styleguide/) [](https://wemake-python-styleguide.readthedocs.io/en/latest/?badge=latest) [](https://github.com/wemake-services/wemake-python-styleguide/pulls?utf8=%E2%9C%93&q=is%3Apr%20author%3Aapp%2Fdependabot) --- Welcome to the strictest and most opinionated python linter ever. `wemake-python-styleguide` is actually a `flake8` plugin with some other plugins as dependencies. ```text The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! ``` ## Installation ```bash pip install wemake-python-styleguide ``` You will also need to create a `setup.cfg` file with [the following contents](https://wemake-python-styleguide.readthedocs.io/en/latest/_pages/options/config.html#third-party-plugins). This file is required to configure our linter and all 3rd party plugins it uses. However, this is a temporary solution. We are working at providing the required configuration for you in the future. See ["Usage" section](https://wemake-python-styleguide.readthedocs.io/en/latest/_pages/usage.html) in the docs for examples and integrations. ## What we are about We have several primary objectives: 0. Enforce `python3.6+` usage 1. Significantly reduce complexity of your code and make it more maintainable 2. Enforce "There should be one-- and preferably only one --obvious way to do it" rule 3. Create consistent coding and naming style You can find all error codes and plugins [in the docs](https://wemake-python-styleguide.readthedocs.io/en/latest/_pages/violations/index.html). ## What we are not We are *not* planning to do the following things: 0. Assume or check types, use `mypy` instead 1. Reformat code, since we believe that developers should do that 2. Check for `SyntaxError` or exceptions, write tests instead 3. Appeal to everyone, this is **our** linter. But, you can [switch off](https://wemake-python-styleguide.readthedocs.io/en/latest/_pages/usage.html#ignoring-violations) any rules that you don't like ## Contributing We warmly welcome any contributions! See ["Contributing" section](https://wemake-python-styleguide.readthedocs.io/en/latest/_pages/contributing.html) in the documentation if you want to contribute. You can also check which [issues need some help](https://github.com/wemake-services/wemake-python-styleguide/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) right now. ## License MIT. See [LICENSE](https://github.com/wemake-services/wemake-python-styleguide/blob/master/LICENSE) for more details.