return guidelines#31
Conversation
Though present in other parts of the guide, this change spells out the preference for implicit returns more clearly with respect to the return keyword.
| let x: ref Xxx = new Xxx | ||
|
|
||
| # Consider using Hungarian naming convention with `ref object` - this makes it clear at usage sites that the type follows the unusual `ref` semantics | ||
| # Consider using Hungarian naming convention with `ref object` - this makes it |
There was a problem hiding this comment.
It's a bit confusing for me who never knew this was called Hungarian naming convention.
Also, the Wikipedia examples of Hungarian notation looks different: refXxx instead of XxxRef (https://en.wikipedia.org/wiki/Hungarian_notation)
I would suggest writing the idea explicitly: Put a Ref at the end of your reference types so that their ref semantics would be obvious at the call site.
| ### Cons | ||
|
|
||
| * Can be confused with an early return, when used at the end of a function | ||
| * When nested deeply in control flow, can make conditions for early return difficult to understand |
There was a problem hiding this comment.
When nested deeply in control flow, can make conditions for early return difficult to understand
in this case user should simplify logic
|
|
||
| ### Cons | ||
|
|
||
| * Can be confused with an early return, when used at the end of a function |
There was a problem hiding this comment.
Can be confused with an early return, when used at the end of a function
how come? last return is last return, how can it be considered early return?
There was a problem hiding this comment.
when the expression rule is applied consistently, you never use return at the end of a function -> when you read "return", you learn to think it's an early return and look for indentation errors.
| ### Cons | ||
|
|
||
| * Can be confused with an early return, when used at the end of a function | ||
| * When nested deeply in control flow, can make conditions for early return difficult to understand |
There was a problem hiding this comment.
maybe there should be a distinction between guards (above code example), top level early returns, and early returns in nested code.
| * ...specially when changing a `proc` _to_ a `template` | ||
| * `return` deep inside a complex set of conditionals indicates that the function likely needs refactoring | ||
| * `return` of a `var` risks returning instances that have not been fully initialized - this in particular applies to the implicit [`result`](./language.result.md) variable. | ||
| * expression style forces each branch of control-flow statements to end in a value, proving a compiler-enforced safety net that typically results in better error messages than `return`, specially when maintaining existing code |
There was a problem hiding this comment.
typically results in better error messages than
return
this is if the early return only contains a return. If it contains more code and the return is missing/removed in a refactor, then you most likely get a misbehaviour at runtime, while if you remove the true/false in the expression style you get a compile time error.
Co-authored-by: Constantine Molchanov <moigagoo@duck.com>
5 participants
Though present in other parts of the guide, this change spells out the preference for implicit returns more clearly with respect to the return keyword.
In general, we prefer expressions throughout which helps with maintenance due to the stricter compile-time checking that Nim performs - this spills over to a preference for usage of implicit expression "return" without an explicit
returnkeyword at the end.