Metadata-Version: 2.0
Name: hacking
Version: 0.10.2
Summary: OpenStack Hacking Guideline Enforcement
Home-page: http://github.com/openstack-dev/hacking
Author: OpenStack
Author-email: openstack-dev@lists.openstack.org
License: UNKNOWN
Platform: UNKNOWN
Classifier: Development Status :: 4 - Beta
Classifier: Environment :: Console
Classifier: Environment :: OpenStack
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: Information Technology
Classifier: License :: OSI Approved :: Apache Software License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.6
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.3
Requires-Dist: pbr (>=0.11,<2.0)
Requires-Dist: pep8 (==1.5.7)
Requires-Dist: pyflakes (==0.8.1)
Requires-Dist: flake8 (==2.2.4)
Requires-Dist: mccabe (==0.2.1)
Requires-Dist: six (>=1.7.0)
Introduction
============
hacking is a set of flake8 plugins that test and enforce the `OpenStack
Style Guidlines <http://docs.openstack.org/developer/hacking>`_.
Installation
============
hacking is available from pypi, so just run:
``pip install hacking``
This will install ``flake8`` with the ``hacking`` and ``pyflake`` plugins
Origin
======
Most of the additional style guidelines that OpenStack has taken on came from
the Google Python Style Guide.
- http://google-styleguide.googlecode.com/svn/trunk/pyguide.html
Since then, a few more OpenStack specific ones have been added or modified.
Versioning
==========
hacking uses the major.minor.maintenance release notation, where maintenance
releases cannot contain new checks. This way projects can gate on hacking
by pinning on the major.minor number while accepting maintenance updates
without being concerned that a new version will break the gate with a new
check.
Adding additional checks
========================
Each check is a pep8 plugin so read
- https://github.com/jcrocholl/pep8/blob/master/docs/developer.rst#contribute
The focus of new or changed rules should be to do one of the following
- Substantially increase the reviewability of the code (eg: H301,2,3
as they make it easy to understand where symbols come from)
- Catch a common programming error that may arrise in the future (H201)
- Prevent a situation that would 100% of the time be -1ed by
developers (H903)
But, as always, remember that these are Guidelines. Treat them as
such. There are always times for exceptions. All new rules should
support noqa.