roch1990 / peon

Python "Elegant Object" Naive linter.

PEON (In development now)

Table of contents

• Introduction
  • What is that
  • What eo principles i can check
  • Python versions compability
• Use-cases
  • Shell
  • Pre-commit hook
• Some theoretical nuances
  • Why naive
• Development
  • Testing
  • Contributing
    • Commit naming conventions
    • Pull-request naming conventions
• License

Introduction

What is that?

"Python Elegant Objects Naive" linter allows you to check your code for conditions of "Elegant objects" OOP architecture, proposed by yegor256

This repo works only for python code.

What eo principles i can check?

Priciple	Yes/No
No null	✔️
No code in constructors	✔️
No getters and setters	✔️
No mutable objects	✔️
No readers, parsers, controllers, sorters, and so on	✔️
No static methods, not even private ones	✔️
No instanceof, type casting, or reflection	✔️
No public methods without a contract	❌
No statements in test methods except assertThat	✔️
No ORM or ActiveRecord	❌
No implementation inheritance	✔️

✔️ - realized

⁉️ - so-so (not sure)

➖ - not done yet

❌ - will never be done, i think

Python versions compability

Version	Yes/No	Why
3.6	✔️
3.7	✔️
3.8	✔️
3.9	✔️

Use-cases

From shell

Simply you should run something like this (dont forget to python3 setup.py install)

peon ./path/to/code

or not recommended way

python3 ./peon/__main__.py

Add linter to pre-commit hooks

You can use this linter by adding it to pre-commit configuration file.

For example (for check all project):

  - repo: https://github.com/roch1990/peon
    rev: '0.13'
    hooks:
      - id: peon
        stages:
          - commit
        args:
          - ./peon

or (for check only changed files):

  - repo: https://github.com/roch1990/peon
    rev: '0.13'
    hooks:
      - id: peon
        stages:
          - commit

Some theoretical nuances

Why naive?

Because it checks only "plain definitions".

For example:

• good, linter check that:

def some_function(some_arg):
   some_var = some_arg

• bad, linter skip that (definition inside definiton - discourage and decrease code quality):

def some_function(some_arg):
   def some_another_function(some_arg):
       return some_arg
   some_var = some_another_function(some_arg)

• good, linter check that:

class SomeClass:
   pass

• bad, linter skip that (definition inside definiton - discourage and decrease code quality):

class SomeClass:
   class SomeAnotherClass:
       pass
   pass

Development

Pre-requisite

After you clone repo:

• create virtual env

python3 -m venv /path/to/new/virtual/environment

• install requirements

pip3 install - r ./peon/requirements.txt

• install pre-commit hooks

pre-commit install

• setup PYTHONPATH

export PYTHONPATH=$PWD/peon

And then feel free to make a changes.

Testing

You can start local test:

make tests

this instruction starts - unit, mutual and security tests.

You can test pre-commit integration:

make local-run

Show results of mutual tests:

mutmut results

Show result of concrete mutual test:

mutmut show <test_id:int>

Contributing

Easiest way is:

• fork
• make changes at your branch
• commit and create PR to dev branch of this repo

If all check would be passed - I check your changes so fast, as i can.

P.S.: falling of mutual tests - is normal now (in development, as you remember)

Commit naming conventions

Every commit should start with keyword with colon:

• feature: (if you add new functionality)
• fix: (if you fix bug or invalid behaviour)
• chore: (if you fix something, that you were not going to fix)

Then, after keyword you should shortly describe your changes: feature: add sec test step to travis

Pull request naming conventions

Every pull request to dev should start with keyword pr-dev and issue number: pr-dev: 123

Every pull request to master should start with keyword pr and issue number: pr: 123

peon's Issues

Multiversion test

Neew to write bash script, that:
for python 3.0..9:
- pull container with python v3.N (n=0..9 ?)
- clone peon to container
- try to test a some python code by peon
- if exception raised - test should fall
- start test with next version

• if one of version-test fall - exit(127) else exit(0)

Release auto-creation

At now there is only one way to create release - manual.
Need to add this step to travis.
Travis should create only minor versions.

So, result looks like:

• after merge changes to master travis start to deploy release
• release would be created at https://github.com/roch1990/peon/releases
• release name should consists of version (wildcard - X.Y where X is major version, Y - minor version)
• travis autoincrement minor version of release
• description of release should consists of commit list (with links), chained with this release (deff between previous and current releases)

Fix mutual tests

A lot of mutual tests (around 50) is falling now.
Should repair.

Report to file

Create report to file if user choose -o cmd flag with output name (relative or absolute).
Default - to stdout.
To report class add method to_file (create file if need and write to it).
To methods of principles class add option by if-else operator for output channel choosing (file/stdout).

Use of mutation testing in peon - Help needed

Hello there!

My name is Ana. I noted that you use the mutation testing tool in the project.
I am a postdoctoral researcher at the University of Seville (Spain), and my colleagues and I are studying how mutation testing tools are used in practice. With this aim in mind, we have analysed over 3,500 public GitHub repositories using mutation testing tools, including yours! This work has recently been published in a journal paper available at https://link.springer.com/content/pdf/10.1007/s10664-022-10177-8.pdf.

To complete this study, we are asking for your help to understand better how mutation testing is used in practice, please! We would be extremely grateful if you could contribute to this study by answering a brief survey of 21 simple questions (no more than 6 minutes). This is the link to the questionnaire https://forms.gle/FvXNrimWAsJYC1zB9.

Drop me an e-mail if you have any questions or comments ([email protected]). Thank you very much in advance!!

Redesign 'Principles' class

Now pipeline looks like:
every file -> Principles -> file goes trough every rule and every rule has it own report

Its not good, because reports mixed between each other.

How it should be:
Tuple of files -> Principles -> tuple of files goes trough every rule (rule by rule)
Every rule is standalone class.
Tuple of files is Principles property.

Every Rule class has its own report method, that create report (of course, its report!).

And report should be like:

Principle bla-bla-bla.
/src/project/file.py:23
/src/project/file2.py:32
More information: link to yegor256

Principle atata.
....

This looks more pretty.

python 3.8 ast compability

at python 3.7 - all is ok
python 3.8:

AttributeError: module '_ast' has no attribute 'Str'

Skip-result cmd flag

If person, who use this linter want only to know what is invalid - he or she can start liner with flag -s, that only show invalid places and thent exit with 0.
If flag not given - exit with 1 (if was found invalid cases).

Additional information to readme + License

• MIT License
• Table of contents
• Development guideline

Grouped report

Now report is not ordered.

But report should loks like this (example):

Principle: No mutable types
file1.py:1
file1.py:3
file2.py:12
source:<link to yegor256 article>

Principle: No null
....