Coding Style

Josef Skladanka jskladan at redhat.com
Tue Jun 3 13:54:43 UTC 2014


First of all - forget the max-line-length comment from earlier... I went through the pep8's configuration options, and there is basically next to none, so the overall decision will mostly need to be "keep it or drop it".

> ==== E251 =====
> Josef is used to add spaces between keyword name and its value in method
> definitions or method calls. Personally, I find it more readable according
> to PEP8 (with no space), but Josef claims the opposite :)

I can, of course, try and change my mindset, but it is true, that i find it more readable the way I'm used to write it
 

> ==== E303 ====
>
> This forbids you from adding two blank lines between class methods. Another
> braindead checks.

Sadly, this can not be configured in any way.

> ==== E124 ====
>
> In a longer line of text, having the closing bracket really matching the
> opening one (the first example) is much easier on the eyes.

Agreed!

 
> ==== E122 =====
> 
> I don't really understand the purpose of this error. If I move 'type(' to the
> third line, it goes away.

I must say, that I find the "proper" way enforced by pep8 to be a bit more readable/understandable. It makes sense, but we can IMHO easily dismiss this error.
 

> ==== E111, E113 ====
> 
> I'm not sure if we can suppress certain warnings only in
> a selected block of code, but if we check for PEP8 automatically, we should
> find out. There will be more use cases like this one.

There is an option to disable checks using #noqa comment, but (sadly) not for these errors.


All in all I'd be for configuration that ignores at least E128 and E303. My personal preference would be also ignoring E303 and E124.
I have no strong opinion on E122, although I'd vote for keeping it, should it ever come to it.
E111 and E113 should IMHO be kept, even if it means this kind of false positives.

J.


More information about the qa-devel mailing list