-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pedantic & controversial: rewrite/remove explicit nils #5857
Pedantic & controversial: rewrite/remove explicit nils #5857
Conversation
Lets `if` and `case` expressions implicitly return `nil`, and let them implicitly return their value unless they're deeply nested and explicit returns do improve readability. Methods always return `nil` when their body is empty, let's leverage this behavior. Stops returning a `nil` when the method signature returns `Nil` and marks methods as return `Nil` instead of returning a `nil`. Keeps an explicit `nil` after some loops (e.g. `Enumerable#each`) which are supposed to return `nil` but may have been overwritten. Rewrites some `foo = bar; if foo` statements as a single expression.
I'm strongly against this. Looking at the diff, it makes the code more confusing for little benefit. Code isn't poetry, it's meant to display clear and unambiguous meaning. Sometimes (all the time in this case), longer code is faster and easier to read. Does pointless bikeshedding about style get us closer to 1.0? No, let's drop it. |
Isn't this a slippery slope? You could easily say the same about implicit return values, which is I think something most people would probably say they love about Ruby... |
If we can't agree on a style guide, we'll never reach 1.0. |
Implicitness is great and helps writing code that is simple and pretty. But sometimes it is better to be explicit about some things. For example, In my opinion this PR adds improvements in some places but not in all and we need to look at the individual subjects to determine how it should be handled. This PR shows examples of code that could be improved and it can be used to discuss these examples. But instead of just applying the results in code, it is essential to codify them in a style guide for reference and further applications. That's what we should focus on. |
@ysbaddaden we've managed up to now perfectly fine with a hodgepodge of styles. How is that changing? |
When I see an alone For now, do we agree at least to have a formatter rule to transform We should a least have an unified style on this. 👍: I'm for |
No, you use |
@j8r debating over |
@straight-shoota this PR is about I think ensuring a consistent style backed by the (opinionated of course) formatter is important, either for newcomers or old contributors. To be back on Let's have one way to do the same thing for this once and for all - not that complicated, is it? |
I don't mind I also don't mind a few explicit So my vote is 👎 for this (it makes things consistent, but not necessarily easier to read or understand). |
Crystal's language is based on Ruby's language, which itself reflects of the Japanese language. In Japanese the context is often not spoken out because it would be redundant (if not rude) to specify it. It's only ever specified to avoid a misunderstanding —but sometimes left confusing, for example in poetry.
Implicitness is part of Ruby's beauty. You can call
something
instead ofself.something()
for example, avoiding unrequited noise. Unless an expression evaluates to something it will evaluate tonil
or a nilable. An empty method body? it returnsnil
. Anif
expression with noelse
branch? it evaluates to a nilable. Areturn
expression with no value? it returnsnil
.Let's fully embrace implicitness once and for all and clean the compiler/stdlib code base.