Adding base pylint rcfile and plugin for unittests.

[dhermes]

No description provided.

[dhermes]

@tseaver This is a start towards getting our code clean without having to sprinkle comments as you mentioned before.

I had a lot of fun learning a bit about the internals of pylint and astroid. However, I'm not sure building a world class code inspection library is worth the trade-off relative to just using pylint: disable.

LMK what you think.

[coveralls]

Coverage increased (+0.0%) when pulling 67417e0 on dhermes:unittest-pylint-plugin into e30de64 on GoogleCloudPlatform:master.

[dhermes]

@silvolu @tseaver Here

[silvolu]

The plugin looks very slick, but I'm worried about the maintenance cost; also, if I understand correctly, comments are the most common way of handling this, is that correct?

[dhermes]

I'm trying to read up on best practices / things people do on the web.

This comment seems interesting:

QUES: How do you handle people adding lots of pylint disable commands? We fail the build on pylint on pylint errors, and Django/Celery peculiarities require us to disable those messages to prevent build failures. Unfortunately, that practice has spread, and we have lots disable statements for things that truly are code smell (e.g. too many local variables, etc.).

ANS: We have a custom .pylintrc file that is under source control. Disabling checks inline is not permissable and changes to the .pylintrc file are carefully reviewed for appropriateness.

I'm also looking into pyflakes as a SO post seems to indicate it is a nice best practice as well.

[tseaver]

As in that answer, ISTM that enforcing project policy through a .pylintrc file and a ban on inline comments disabling lint leads to the best code quality.

[dhermes]

Yes it seems to be a policy which is alive and well in the Python ecosystem. I'd be interested to hear what people do in cases like this.

In reality, a class with 47 public methods is doing too much, but having pylint complain about the 47 public methods "owned" by our unittest2.TestCase subclass is a bit silly. I'm not sure how one modifies it as the only setting I know of is

[DESIGN]
max-public-methods=20

[coveralls]

Changes Unknown when pulling f85eeba on dhermes:unittest-pylint-plugin into * on GoogleCloudPlatform:master*.

[coveralls]

Coverage increased (+0.0%) when pulling f85eeba on dhermes:unittest-pylint-plugin into 6dd5f2b on GoogleCloudPlatform:master.

[tseaver]

Feel free to ignore the other "Invert the test and nest the following code?" comments if you don't find the first helpful.

[dhermes]

Gotcher. I will handle uniformly depending on the resolution of our discussion.