-
Notifications
You must be signed in to change notification settings - Fork 21
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
Comments
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? |
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"? |
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 |
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. |
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:
|
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 |
It's a matter of personal preference, but I thinks coding style, e.g. PEP8, should be applied.
The text was updated successfully, but these errors were encountered: