On a related note. I think it would be super awesome if all the new code (for the refactoring) that we're checking in is pylint-ing with a 10/10 resulting score. There's no reason to start off on the wrong foot with our refactoring by checking in code that needs refactored.
-- Joyce On Fri, Jul 19, 2013 at 11:29 AM, Boustani, Maziyar (398F) < [email protected]> wrote: > 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 > > >
