Hi All, So far three file have been refactored and they are still in old style. Before I move forward to the other code, I will modify them to follow PEP-8 (no camelCase). Let me know for any more modification.
Best regards, Mazi On Jul 19, 2013, at 9:57 AM, Michael Joyce wrote: Alex, Yes, it is standard to not place spaces around an equals in that instance. The wiki mentions that to handle all the cases save that edge case. If we end up following PEP-8 the wiki page for documentation standards is going to be drastically simpler. I imagine it'll mostly consist of "Follow PEP-8 and use Pylint" =) -- Joyce On Fri, Jul 19, 2013 at 9:14 AM, Goodman, Alexander (398J-Affiliate) < [email protected]<mailto:[email protected]>> wrote: +1 to removing camelCase. When I first began working on this project, I did think using the camelCase naming convention for variables and functions was contrary to what I had typically seen in python code up to that point, so I think it would be good to be consistent with the rest of the pythonic community at large. A few of us did spend a significant amount of time refactoring some of our older code to adhere to the camelCase convention, but nevertheless it is a fact that a lot of our python code still doesn't follow the convention properly. One other thing: The "operators must be surrounded by single spaces" convention as stated in our wiki does not explicitly account for the exceptional case of optional and keyword arguments for functions, where it is standard to not surround the equals signs by spaces, eg f(arg=None), but this is explicitly mentioned in the PEP-8 document. As a result some of our modules (namely plots.py and metrics.py) do not follow this convention correctly. I think it would be good to mention this on the wiki page. Thanks, Alex On Fri, Jul 19, 2013 at 7:48 AM, Michael Joyce <[email protected]<mailto:[email protected]>> wrote: Agreed. It seems that now is the perfect time given how much code we're moving/changing. So much code is being committed for the "first time" as we refactor. It's simple to lint prior to committing and making our life easier later! Joyce -- Joyce On Fri, Jul 19, 2013 at 7:39 AM, Ramirez, Paul M (398J) < [email protected]<mailto:[email protected]>> wrote: +1 to PEP-8 (no camelCase) Either way looks like our compliance to a style is bad overall and something we need to work towards. I'd say just work on as we go though and not let it stand as a blocker to anything. The interesting thing here is if its merely variable names then any changes would remain backwards compatible as we don't have many classes at this point. --Paul On 7/19/13 7:28 AM, "Michael Joyce" <[email protected]<mailto:[email protected]>> wrote: Hi all, I would like to discuss our style guides, specifically regarding the style guide for the Python part of OCW. Currently our style guide is effectively PEP-8 + camelCase variable names + slightly longer line lengths. I propose that we switch to plain PEP-8. Our compliance is fairly terrible either way and since we're already going through a large refactoring I don't see losing those few points of compliance as that big of an issue. Following the Python communities standard makes it easier for developers to jump into the project and it keeps our code in line with the rest of the Python that we use. We also don't need a custom pylint config file. The linting documentation is now simply "run pylint". -- I ran pylint over the toolkit with and without our config. With (This is our CamelCase version of Pep8) 3.41/10 Without (This is PEP8) 2.27/10 Thoughts? -- Joyce -- Alex Goodman
