All Projects → roch1990 → peon

roch1990 / peon

Licence: MIT license
Python "Elegant Object" Naive linter.

Programming Languages

python
139335 projects - #7 most used programming language
Makefile
30231 projects

Projects that are alternatives of or similar to peon

Husky.Net
Git hooks made easy with Husky.Net internal task runner! 🐶 It brings the dev-dependency concept to the .NET world!
Stars: ✭ 394 (+1170.97%)
Mutual labels:  linter
linter-terraform-syntax
terraform validate linter and formatter for atom
Stars: ✭ 19 (-38.71%)
Mutual labels:  linter
codeclimate-apexmetrics
ApexMetrics - Code Climate engine for Salesforce [DISCONTINUED use CC PMD instead)
Stars: ✭ 46 (+48.39%)
Mutual labels:  linter
cactoos-matchers
Elegant object-oriented hamcrest matchers
Stars: ✭ 30 (-3.23%)
Mutual labels:  elegantobjects
prlint
GitHub App for linting pull request meta data
Stars: ✭ 122 (+293.55%)
Mutual labels:  linter
flexlint
A flexible linter with rules defined by regular expression
Stars: ✭ 19 (-38.71%)
Mutual labels:  linter
f2e-spec
Alibaba Front-end Coding Guidelines and Relevant Tools
Stars: ✭ 548 (+1667.74%)
Mutual labels:  linter
Frontend-StarterKit
Frontend StarterKit - [Gulp 4, Pug, SCSS, ES6+]
Stars: ✭ 13 (-58.06%)
Mutual labels:  linter
nimfmt
Nim code formatter / linter / style checker
Stars: ✭ 75 (+141.94%)
Mutual labels:  linter
actionlint
Static checker for GitHub Actions workflow files
Stars: ✭ 1,385 (+4367.74%)
Mutual labels:  linter
vscode-linter
Extension for code linting, all in one package. New linters can be easily added through an extension framework.
Stars: ✭ 47 (+51.61%)
Mutual labels:  linter
nano-staged
Tiny tool to run commands for modified, staged, and committed files in a GIT repository.
Stars: ✭ 347 (+1019.35%)
Mutual labels:  linter
healthier
🧘‍♀️ Healthier is an opinionated style agnostic code linter – a friendly companion to Prettier
Stars: ✭ 78 (+151.61%)
Mutual labels:  linter
repolint
Tool to check github user/organization repositories for some simple and common issues.
Stars: ✭ 19 (-38.71%)
Mutual labels:  linter
sqlclosecheck
Linter that confirms that DB rows and stats are closed properly.
Stars: ✭ 21 (-32.26%)
Mutual labels:  linter
vue-cli-template-library
Template for developing open-source vue.js libraries with Rollup + Jest + Babel + Storybook + TravisCI + SemanticRelease
Stars: ✭ 61 (+96.77%)
Mutual labels:  linter
flake8-spellcheck
❄️ Spellcheck variables, classnames, comments, docstrings etc
Stars: ✭ 71 (+129.03%)
Mutual labels:  linter
vnu-elixir
An Elixir client for the Nu HTML Checker (v.Nu).
Stars: ✭ 50 (+61.29%)
Mutual labels:  linter
errchkjson
Go linter that checks types that are json encoded - reports unsupported types and unnecessary error checks
Stars: ✭ 29 (-6.45%)
Mutual labels:  linter
retext-assuming
Check for unhelpful ‘assuming’ phrases such as ‘just’, ‘simply’ or ‘obviously’ with retext
Stars: ✭ 15 (-51.61%)
Mutual labels:  linter

EO principles respected here We recommend IntelliJ IDEA

Build Status codecov Maintainability Rating Quality Gate Status Vulnerabilities Duplicated Lines (%) Code Smells Security Rating Technical Debt Hits-of-Code License: MIT

PEON (In development now)

Table of contents

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

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].