Wemake-python-styleguide: `get_*` functions must return something.

[orsinium]

Rule request

Thesis

Functions and methods with get_ prefix must return something (have return or yield in the body).

Reasoning

get_ function is expected to return what it promises to return. For example, get_user returns a user object. If it's not so, it's an error or a bad interface.

[sobolevn]

Related #1054

[uhbif19]

@sobolevn Am I correct in understanding, that realizations for this and #1054 would not share code?

Is checking that return type is not None enough for this rule?

[sobolevn]

Yes, you are correct. There would be no code sharing.

Is checking that return type is not None enough for this rule?
We should check that functions and methods named with get_:

1. Have at least one return ...
2. All returns are not bare: return a (not bare) vs return (bare)

[sobolevn]

Thanks a lot, @lukelima!
Assigned!

[uhbif19]

@sobolevn As I understand, the issue is not assigned now? Please assign me, then.

[sobolevn]

Thanks a lot, @uhbif19!

[hhsdev]

@sobolevn May I take this?

[sobolevn]

Thanks!

[sobolevn]

@hhsdev can you please take and extend this PR? https://github.com/wemake-services/wemake-python-styleguide/pull/1185

[hhsdev]

I would love to!

Just for clarification, #1185 and this issue will still not share code, right? And by extend do you mean to clone their PR and modify that or just start a new implementation?

[sobolevn]

It might actually share some code (but, I am not sure).

And by extend do you mean to clone their PR and modify that or just start a new implementation?

Do you have an opportinity to continue that work?

[hhsdev]

I thought maybe I can clone their PR and work from there, but if there's a chance the two features might share code, I guess I should just start clean. Thanks!

[sobolevn]

I still think that this would be easier:

I thought maybe I can clone their PR and work from there

But, do what feels best! 👍

[uhbif19]

@hhsdev @sobolevn Sorry I forgot to share my code on this issue. Code and tests are working (as far as I remember), but I stumbled upon writing docs.

You can use this code, if you need to: https://github.com/uhbif19/wemake-python-styleguide/commit/9e6e266ddf505744dee74d64752e9804f886e827

[hhsdev]

@uhbif19 Thank you so much! This will help a lot.

[hhsdev]

@sobolevn Hey I think I found a documentation/code mismatch.

The docstring of FunctionDefinitionVisitor.visit_any_function, It's said to check regular, lambda and async functions. However, the visit_any_function is not aliased to visit_Lambda . Which one is correct?

[sobolevn]

@hhsdev this is a bug, because turns out ComplexDefaultValueViolation does not work for lambda cases.
I will fix it right now. Thanks!

[hhsdev]

@sobolevn Sorry to bother again.

The code is almost complete. But I wondered whether or not we should check every execution path a function can take to make sure it consistently returns a value .

Consider:

def get_foo():  # explicit return None; A-ok
    if some_condition:
        return 1
    return None

def get_bar():  # implicitly returns None if some_condition == False
    if some_condition:
        return 1

Should get_bar raise GetterWithoutReturnViolation?

[sobolevn]

@hhsdev we already have a different rule that checks for consistent returns. This rule should check that we have at least one non-empty return.