coding style

[yudai09]

It's a matter of personal preference, but I thinks coding style, e.g. PEP8, should be applied.

[whyscream]

I tried to give python3 code a try tonight, but ran into this same issue: the code is very non-standard which makes it hard to edit. Would you accept PRs to improve code style to get it more towards pep8?

[sdgathman]

I'm open to the continuation line recommendations. I should have converted all leading tabs to spaces. Naming conventions will have to consider backward compatibility, of course. New/changed comments should support Doxygen where appropriate (method/variable descriptions). I'm not a big fan of 4 space indents - but it is ok when it doesn't introduce additional continuation lines.

What style issue makes it "hard to edit"?

[sdgathman]

Ok, I'm using pep8, which has a number of checks all with nice ids. I'll work up a list of pep8 checks which I will --ignore. For example:

W291 Trailing white space in comment - this is used by paragraph reforming in vim (to preserve number of spaces between words).

E111 4 space indents - I hate extra continuations

E266 More than one leading # - double ## needed for Doxygen

[sdgathman]

How important is E231 missing whitespace after comma to you guys? I am not liking it - makes most function calls harder to read, especially those mixing variable and string constants like print().

E302 two blank lines before function defs - Already have a block of comments at a function def. The 2 blank lines in addition are not helping, and pushing code off the screen. Maybe I can do a plugin to require 2 blank lines only for function defs with no Doxygen comment header.

In any case, I approve of requiring code to pass pep8 - with my list of checks ignored. We can debate my list of checks to ignore here.

[tomhendrikx]

IMHO: the nice thing thing about pep8 is that it makes python code adhere to the same rules everywhere: less ignored checks are always better. As far as your comments go:

• E111: I do like 4 spaces indenting, and tend to violate the 80 chars line length to circumvent line continuations (set limit at 120). The mixup of 2 and 4 spaces used throughout the project makes it even harder.
• E302: the comment blocks above the methods are totally non-Pythonic, and the Doxygen documentation suggests that it supports the regular Python style docblocks, so I'd advocate convert everything to Python docstrings where possible. This would probably also invalidate your need for E266 and E302.
• E231: I disagree with you, but this is really just personal preference

[dkg]

fwiw, the official python doxygen documentation suggests that while it supports regular python-style docblocks, it doesn't apply any of the doxygen special commands to them, which loses a lot of the value of the doxygen documentation.

That said, i prefer the pythonic form of documentation for python modules anyway -- having explicit help text available in the python interpreter's help() is super helpful.