Skip to content

AlwxSin/wemake-python-styleguide

 
 

Repository files navigation

wemake-python-styleguide

wemake.services Build Status Build status Coverage PyPI version Documentation Status Dependencies Status


Welcome to the most opinionated linter ever.

wemake-python-styleguide is actually a flake8 plugin with some other plugins as dependencies.

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

pip install wemake-python-styleguide

You will also need to create a setup.cfg file with the following contents.

This file is required to configure our linter and 3rd party plugins it uses. However, this is a temporary solution. We are working at providing the configuration for you in the future.

Usage

Since we are just a flake8 plugin, it means that all you have to do is: run flake8.

flake8 your_module_or_package.py

There are different options how to automate linting process. We prefer pytest-flake8 plugin to run our linter alongside with the tests.

What we are about

We have several primary objectives with this linter:

  1. Enforce python3.6+ usage
  2. Significantly reduce code's complexity and make it more maintainable
  3. Enforce "There should be one-- and preferably only one --obvious way to do it" rule
  4. Create consistent coding and naming style

You can find all error codes and plugins in the docs.

What we are not

We are here not to:

  1. Assume or check types, use mypy instead
  2. Reformat code, since we believe that developers should do that
  3. Check for SyntaxErrors or exceptions, write tests instead
  4. Suite everyone, this is our linter

Contributing

See CONTRIBUTING.md file if you want to contribute. You can also check which issues need some help right now.

License

MIT. See LICENSE for more details.

Packages

No packages published

Languages

  • Python 100.0%