Qiskit-terra: Make the linter happier!

[atilag]

Welcome contributor!

We are evolving the SDK at near speed of light! (almost), so, you know.. sometimes we forget about our Linter friend.
We want to fix this! and we think this is a good opportunity for newcomers to have first-soft-contact with the code and help us out.
Are you willing to help? Seriously!? ... Thank you!!
I'd recommend executing this to start with (brace yourselves!):

make lint

... yeah, we know... overwhelming :(
Of course, you don't have to fix them all, we would be extremely grateful if you take care of a bunch of them... or just one!

UPDATE
As there are many people who wants to contribute here, let's sync this way:
1st - Read in the comments which files are already taken.
2nd - Pick the files you want to fix and write a comment so everybody knows in which files you are working on.

Notes

• If you want to take this bug, let us know and we will assign you to it.
• You can open a PR to "master" branch with the word: "WIP" (Work In Progress) in front of the description, so we will know that you haven't finished and we can make parcial reviewings. We will eliminate the WIP prefix once the PR is ready to be merged.
• Make sure all tests pass! :)

[desireevl]

Hi, I'd be keen to help with this :)

[jessicalostinspace]

What is the current status of this ticket?

[atilag]

We are leaving it opened for a while because there are still a lot of work to be done here.
So to avoid conflicts, I'd suggests that if you want to contribute, pick some files and write a comment telling us which ones did you pick.

[atilag]

@desireevl @jessicalostinspace Should I assign this issue to you both? :)

[jessicalostinspace]

Sure :) May want to start on opposite ends of the log(or just note which modules we are working on). I'll start working on the first five modules listed. @desireevl I would run this so you can open it up in your file editor easier make lint > lint-log.txt but don't check it in.

[atilag]

Ok, my fault. Seems like Github doesn't allow to assign Issues to non-members of the project. Anyway, pick your files (or modules) and let us know in a comment.

[diego-plan9]

Wonderful news! If working on an individual file, you might find it handy as well to invoke the linter directly for that a specific file (and optionally, do not display the full report), for example:

$ pylint qiskit/_result.py  -rn
************* Module qiskit._result
W: 78, 0: Bad indentation. Found 9 spaces, expected 8 (bad-indentation)
C:  1, 0: Missing module docstring (missing-docstring)
W: 52,36: Access to a protected member __qobj of a client class (protected-access)
W: 55,37: Access to a protected member __qobj of a client class (protected-access)
W: 56,39: Access to a protected member __qobj of a client class (protected-access)
W: 57,39: Access to a protected member __result of a client class (protected-access)

------------------------------------------------------------------
Your code has been rated at 9.06/10 (previous run: 9.06/10, +0.00)

[jessicalostinspace]

Ok. @atilag So I'm seeing that most of these errors (perhaps thousands) are because each script is standalone and not wrapped in a function. There are two+ ways around this. Changing the configuration for pylint so that const-rgx is the same as variable-rgx, or wrapping the body of each script into a function and calling the function. Not sure how you want to approach this?

[diego-plan9]

Thanks, @jessicalostinspace - those (extremely frequent throughout the codebase) invalid-name warnings are indeed in this case due to the combination of the example/ files being a bit exceptional (in the sense of being scripts meant to be standalone and not part of a module), and our current configuration of the linter not yet fine-tuned for the false positives. In this particular case, and even if both your solutions would be valid, I'd recommend to just ignore them for the moment while we revise the issue of the false invalid-name positives as a whole.

As a matter of fact, in general, I would try not to make a short term goal to try to solve _each and every warning_ - it would eventually be awesome and is the long term goal, but there are still quite some cases where the warnings might be a result of an over-zealous linting, or require some clarification and consensus. For the moment we are more than happy to keep solving them incrementally, and every contribution in this sense is extremely appreciated!

[jessicalostinspace]

There are a lot of bare "except" errors. Since the error message is custom in this case, should it also be suppressed for now, along with the invalid-name, and relative imports?

[diego-plan9]

Hmm, are you referring to broad-except (rather than bare - a recent linter run seems to find 1 bare-except and 9 broad-except on my setup)? As a general case we should indeed try to catch the most specific kind of Exception, but it can be rather difficult to find the ones that can be raised at the moment (specially for deeply nested calls) - my recommendation would be to ignore the warnings for now as they might require quite a lot of time to track them down.

[diego-plan9]

Closed by #224.