Codestyle

Commit style

We use tag style for commits:

add or added - if you add changes

refactor - if you remove or replace existing code

test or tests - if you write or change test code

fix or fixed - if you fix a bug

After tag, commit message should containg info about your changes.

For example:

add: new API endpoint for bind

test: new API endpoint

refactor: removed headers from bind endpoint

fix: headers pass for bind endpoint

If you change codestyle/linting:

refactor: linters, fix: lint or refactor: codestyle

Branch name

Should contain info about your changes, with tag, if possible and not complex:

add_new_modify_endpoint

fix_a_complex_bug

refactor_someexternalservice_wrapper

test_someexternalservice_wrapper

Codestyle

1. We use isort to sort imports, config is in pyproject.toml
2. MyPy, Flake8 and Pycodestyle uses configs from repo
3. Avoid filter, lambda, replace it with list comprehensions

list(filter(lambda x: x % 2 == 0, range(10)))

[i for i in range(10) if i % 2 == 0]

4. All funcs/methods args and return statements should be annotated with types
5. All funcs/methods args and return statements should be annotated with docstrng in sphinx style

Indent style

1. We use 79 length rows, all developers have different monitors, and review will be much easier from browser, so its important. If row is less than 79 chars, this is a priority to keep it untouched, if row is too complex, for e.g. double-tripple dict-list comprehension, its ok to make line breaks
2. Line break style on functions and methos, funcs declarations:

Ok:

def func(
    a: int, 
    b: int, 
    c: int) -> None: ...

def func(
    a: int, 
    b: int, 
    c: int,
) -> None: ...

# long return annotation
def func(a: int, b: int, c: int) -> \
    int | None: ...

def func(a: int, b: int, c: int) -> Generator[
    int, None, None]: ...

# long term statements
my_var = (
    somethinglikethis
    .where(we=do_things)
    .where(we=domore)
    .where(we=everdomore))

my_var = (
    somethinglikethis
    .where(we=do_things)
    .where(we=domore)
    .where(we=everdomore)
)

func(
    somethinglikethis
    .where(we=do_things)
    .where(we=domore)
    .where(we=everdomore),
)

func((
    somethinglikethis
    .where(we=do_things)
    .where(we=domore)
    .where(we=everdomore)
))

# It's ok, but examples above are more readable
my_var = somethinglikethis.where(
    we=do_things).where(
    we=domore).where(
    we=everdomore)

# It's ok, but please, try to use bracket-style
my_var = somethinglikethis \
    .where(we=do_things) \
    .where(we=domore) \
    .where(we=everdomore)

# mutli argument pass

func(arg1, 'abracadabra abracadabra')

func(
    arg1, 
    'abracadabra abracadabra',
)

foo_func(arg1, 
    'abracadabra abracadabra',
    'abracadabra abracadabra',
)

foo_func(arg1, 'abracadabra abracadabra',
    'abracadabra abracadabra',
)

foo_func(
    arg1, 
    'abracadabra abracadabra',
    'abracadabra abracadabra',
)

Not ok, but it's correct for linters, avoid it:

def func(a: int, 
         b: int, 
         c: int) -> None: ...

bar_func(arg1, 
         'abracadabra abracadabra',
         'abracadabra abracadabra')

bar_func(arg1, 
         'abracadabra abracadabra',
         'abracadabra abracadabra',
)