+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]> 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]> 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]> 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
