-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Style Guide update #3122
base: main
Are you sure you want to change the base?
Style Guide update #3122
Conversation
The exceptions to this rule are `for`-comprehensions which lack a | ||
`yield` clause. In such cases, the construct is actually a loop rather | ||
than a functional comprehension and it is usually more readable to | ||
string the generators together between parentheses rather than using the | ||
syntactically-confusing `} {` construct: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to drop this since the arguments for using one-generator-per-line syntax hold no matter whether the next keyword is do
or yield
As a rule, files should contain a *single* logical compilation unit. By | ||
"logical" I mean a class, trait or object. One exception to this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This resolves #1621 by removing the confusing concept entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very glad to see the style guide getting some love!
|
||
## Curly-Braces | ||
|
||
Curly-braces should be omitted in cases where the control structure | ||
In Scala 3 using curly-braces is discouraged and the quiet syntax with significant indentation is favoured. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this claim might be too strong. How about something like:
We have chosen to use significant indentation through this style guide, but our preference is not universally shared.
Some teams and individuals have enthusiastically embraced Scala 3's significant indentation; others still favor curly braces.
### Thanks to ### | ||
|
||
[Daniel Spiewak](https://www.codecommit.com/) and [David Copeland](https://www.naildrivin5.com/) for putting this style guide together, and Simon Ochsenreither for converting it to Markdown. | ||
**Thanks to** [Daniel Spiewak](https://www.codecommit.com/) and [David Copeland](https://www.naildrivin5.com/) for putting this style guide together, and Simon Ochsenreither for converting it to Markdown. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think enough years have now passed, and enough people have contributed, that it's no longer necessary to have a "Thanks to" section at all.
@@ -27,22 +30,70 @@ the way in which semi-colon inference is implemented. Many headaches | |||
will be saved by simply following the curly brace convention | |||
demonstrated above. | |||
|
|||
## End markers <span class="tag tag-inline">Scala 3 only</span> | |||
|
|||
In Scala 3 using curly braces is discouraged in favor of significant indentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see my other comment
No description provided.