#64 - Introduce the pylint into project

[miroslavpojer]

• Added pylint config. Reused config from living-documentation-generator repository as approved settings.
• Add section in README.md describing how to use pylint.
• Add new library dependency into requirements.txt
• Updated test.yml file (renamed from build.yml) to run two jobs: unit test and static code analysis. Job for static code analysis contains check for minimal required scode == 9.5.
• Formatting of repository code will be part of following Issue. Check is failing now.

Closes #64

[miroslavpojer]

Release notes:

• Introduces pylint support & CI check job to fail when not reached limit (9.5/10) score.

[MobiTikula]

I would suggest to improve .pylintr file with ignoring method documentation for getter methods. It is not a substantial documentation. Less is more.

• Improve your Pylint score up to 9.5 or higher.

[miroslavpojer]

I would suggest to improve .pylintr file with ignoring method documentation for getter methods. It is not a substantial documentation. Less is more.

• Improve your Pylint score up to 9.5 or higher.

Implemented in commit f4b1058.

[MobiTikula]

I have several thoughts about Pylint check implementation

• you use a lot of constants all over the project, but having only 5 of them in the utils/constants.py. Does it have any deeper meaning? I think that is the same pattern like I had in liv-doc: see the comment from Laco: Refactoring/13 documentation and formatting living-doc-generator#30 (comment)
• you often use # pylint: disable=, but even in scenarios, where I think it is suggesting improving the code. IMOP you are overusing classes, like the constants class etc. I had the same issue with my pylint implementation and after removing the unnecessary classes the code got much better.
• since you use so many pylint disabling constants, maybe you should modify the pylint settings. You can ignore some error logs even for the whole files (like test files). The code with so many disabling comments does not look the best.
• There are some formatting issues, BUT don't worry. We have BLACK tool!:)

[miroslavpojer]

I have several thoughts about Pylint check implementation

• you use a lot of constants all over the project, but having only 5 of them in the utils/constants.py. Does it have any deeper meaning? I think that is the same pattern like I had in liv-doc: see the comment from Laco: Refactoring/13 documentation and formatting living-doc-generator#30 (comment)
• you often use # pylint: disable=, but even in scenarios, where I think it is suggesting improving the code. IMOP you are overusing classes, like the constants class etc. I had the same issue with my pylint implementation and after removing the unnecessary classes the code got much better.
• since you use so many pylint disabling constants, maybe you should modify the pylint settings. You can ignore some error logs even for the whole files (like test files). The code with so many disabling comments does not look the best.
• There are some formatting issues, BUT don't worry. We have BLACK tool!:)

• Contants accepted and solved.
• Could you identify other location to improved instead of usage pylint disable?

[MobiTikula]

As requested, I added some suggestions, how code can be improved with Pylint advices. IMOP all pylint warnings should be tried to be solved at the first place. If the improvement is affecting the logic in a bad way, than there is option to disable the warning. But I try to solve the issue first and I am satisfied with the benefits. I don't care a lot about the aesthetics of the code, since I can format it later with other tools.

[MobiTikula]

Not used import.

[miroslavpojer]

Removed.