-
Notifications
You must be signed in to change notification settings - Fork 5
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
Python coding style and consistency #283
Comments
👍 What about unit tests? There are some kicking around, would be good to say something about that too. My share of python is the ACORN Current Generator and I promise to align it to the code conventions specified here (mostly renaming function names). |
@lbesnard @bpasquer @ggalibert Any thoughts on this? |
👍 |
Sounds good to me. |
FIY : |
I think those 2 are contradicting somewhat. We're not using classes much, but image I have a modules called
@mhidas I'd like to have your feedback on that... |
a fair bit of work to do in |
Bit by bit. |
Personally I don't have a problem with this. For what it's worth, it does help distinguish a class from a module or sub-module. You can avoid having to write all that by importing it like this instead:
Or would you prefer to use CapWords for module names as well? |
I just prefer to have consistency. I'm not bothered by any of that :) |
A minor point in the above mentioned style guide:
So for example instead of |
Perhaps update the issue above with that. It makes perfect sense. |
@danfruehauf Done |
Now that more of us are starting to write more Python code, it might be helpful to converge a bit in terms of coding style. In particular, naming conventions for variables, functions, classes and files. It just makes the code a bit more readable, so it's worth putting a bit of effort (not heaps) into it. As this detailed style guide for Python code suggests "A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important. "
My own code needs some cleaning up, but first we should agree on what to aim for. I propose we adopt the following conventions as an ideal:
lower_case
, with underscores if necessaryCapWords
(capitalise first letter of every word, no underscores). If any word is an abbreviation, capitalise the whole word, e.g. useANMNFileClassifier
instead ofAnmnFileClassifier
lower_case
, with underscores between words (alternatively, if we decide we have too many inmixedCase
already, we can stick with that, though IMHO they're less readable. Also we use the lower_case convention in our bash scripts)lower_case
, same as functionsUPPER_CASE
These are just suggestions, open for discussion.
The text was updated successfully, but these errors were encountered: