Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

coding style #7

Open
yudai09 opened this issue Aug 15, 2016 · 6 comments
Open

coding style #7

yudai09 opened this issue Aug 15, 2016 · 6 comments

Comments

@yudai09
Copy link
Contributor

yudai09 commented Aug 15, 2016

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

@whyscream
Copy link
Contributor

whyscream commented Sep 21, 2016

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Owner

sdgathman commented Sep 23, 2016

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
Copy link

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
Copy link
Contributor

dkg commented Feb 20, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants