Refactoring

Description

After setting up basic CI with linting, need in refactoring became evident. The code is brought in accordance with PEP8 standard and few improvements were also made, notably lazy logging is now used, so the logger should not bring too much overhead (this should be visible with test bages). The CI file was pre-pushed to the develop in order to have convenient badges on the gitlab page. Sorry If there're any comments to CI file, the can be addressed in the current MR, however I'd consider it to be a pretty good basic template. As soon as eos website for service account will be created, the docs deployment job can be used.

Related Issue

Closes #12 (closed)

How Has This Been Tested?

Tested both locally and with the CI. The pylint score changed from 4.06 to 9.82

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

DEVELOPERS.md

@@ -36,7 +36,7 @@ deactivate # return from virtual environment to the regular one
 
 ### Checking whether your code is up to project standard
 Use [*pylint*][pylint] to check if your code quality is good. Standard linter configuration is used.
-Compare the linter ratings before and after your modifications and do not commit the code which reduces the code quality.
+Compare the linter ratings before and after your modifications and do not commit code that reduces the code quality.
 
 ### Testing the code with Jupyter notebooks