PEP8

Because I know that we should.

This could probably help ease us in: http://propertiespy.readthedocs.io/en/latest/content/renamed.html#renamed-property

I think that there are a number of handy properties that people use quite often that would need some thought:

nC, nF, vnE etc. I think true PEP8 doesn’t even like the 2 letter variable names? For some of this stuff that is used constantly, I think that is fine?

faceDiv --> face_div

Oh boy.

fatiando/fatiando#278

Thoughts @lheagy?

[lheagy]

A few naming thoughts on the base class

• nC --> ncells, similarly nF --> nfaces, nE --> nedges
• nEx --> nedges_x, etc
• vnC --> vec_ncells, or vector_ncells ?
• x0 stays? or x0 --> origin

[leouieda]

This package was my first exposure to the Python language. I was young, naive, and fancy free.

@rowanc1 I’ve been there 😃 This got implemented in Fatiando right after Scipy 2014 in fatiando/fatiando#115

I used autopep8 but did it one file at a time to check that all tests and scripts were still working. I wouldn’t recommend running it on the entire library at once. A good way to start to put the pep8 check into a CI system and enforce it for new code.

I recently started running flake8 in TravisCI to catch any incompatibilities (fatiando/fatiando#382). Another useful tool is pylint with the --py3k argument to make sure new code is Python 3 compatible (mostly).

@lheagy I’ve been very liberal with breaking backward compatibility in Fatiando. I should actually make it more clear in the docs about that. One thing that mitigates this is to always record and cite the version number in research projects. The code there will still work and produce the results from the paper, just not using the latest Fatiando. For example, I was working on this paper and this one in parallel and they both use different incompatible versions. But they both still work.