Python coding style? (Flake8/PEP8...)
Alois Mahdal
amahdal at redhat.com
Wed May 14 11:11:40 UTC 2014
Thanks both Michal and Stephen for comments.
Just few comments, mostly from the point of view of static analysis
tools usability.
On Fri, 09 May 2014 10:18:25 +0200
Michal Minář <miminar at redhat.com> wrote:
>
> * autogenerated class names and methods for modules in providers
> - they are very long
> - mix of CamelCase, lowercase and underscores
> - but they just make sense since they correspond to CIM
> equivalents
> * CamelCase used throughout unittest
> - when using unittest.TestCase as a base class for our test cases,
> it's just impossible to follow these coding styles. Overriding
> any method results in CamelCased method in your code.
AFAIK casing is not exactly required by PEP8; there are
recommendations, but at least it's not enforced by the pep8 script by
default.
One exception is the line length 79, but even considering the above,
I believe it would be very rare to have such long ID that would force
us to break this rule (and still make sense).
> * OpenLMI Scripts and particularly command-line wrappers are
> specifically designed for quick prototyping and do not follow
> any coding style at all (you may expect a bunch of warnings).
For that matter, at least flake8 and pep8 can be disabled by magic
comment in file header.
> Making at least our tests look similar should not be a big problem.
> Let's start with that and see, where it gets. Please, go on with your
> idea. Let's discuss the details on review :).
Thanks, I have already started with lmi.test.util. (Unfortunately it's
not on RB yet due to problems with RBTools --- I'm working on resolving
that.)
Thanks,
aL.
--
Alois Mahdal <amahdal at redhat.com>
Platform QE, BaseOS Daemons
#qa, #brno, #daemons
More information about the openlmi-devel
mailing list