-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Naming conventions #861
Naming conventions #861
Conversation
@zygoloid @chandlerc Note, I'm trying to interpret the current rationale for the naming decision. I think I've accurately captured your perspective now: I had definitely misunderstood some of the discussions, but a quick thread with Chandler hopefully cleared that up. Given I may be inserting the wrong words into your mouths, please let me know if I'm still wrong. |
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.
Addressing comments
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.
Trying to get back to this, again sorry for the delay. Suggestions and comments inline, and thanks for working on pulling all the different discussions together into a proposal.
proposals/p0861.md
Outdated
- `UpperCamelCase` will be used when the identifier can be resolved to a | ||
specific value at compile-time. |
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 curious, would "value or entity" wore better or worse here?
- `UpperCamelCase` will be used when the identifier can be resolved to a | |
specific value at compile-time. | |
- `UpperCamelCase` will be used when the identifier can be resolved to a | |
specific value or entity at compile-time. |
Specifically thinking about namespaces. @zygoloid might have thoughts on the specific wording of 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.
An alternative way to phrase this we could consider: "UpperCamelCase
will be used when the identifier names a specific program entity, such as a function, a namespace, or a compile-time constant value." This tries to anchor more on the "proper noun" kind of rationale.
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.
Using the second suggestion, since I assume you prefer it.
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.
One phrasing that came up in discussion with @chandlerc: "if the named entity cannot have a dynamically varying value".
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.
FWIW, I think I prefer the latest version ("... names a specific program entity, such as ....") slightly over "cannot have a dynamically varying value". Maybe they could be combined?
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.
Tried rephrasing...
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 happy with the phrasing that you ended up with. I feel like I could apply it to understand why function parameters get one result and template/generic parameters get another result, and why a local let a: i32
binding gets one result but a global let A: i32
binding gets a different result.
proposals/p0861.md
Outdated
Private member variables should use a `_` suffix in order to prevent name | ||
collisions. We discourage private properties. |
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.
Could we skip this suggestion, at least for now? I'm not sure it will be needed in Carbon, and I'd rather not get ahead of that design.
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.
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'd just like to avoid pre-adopting a workaround for an avoidable design problem... Thanks for moving this to an open question, would it be OK to remove it from the list above as well?
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.
Okay, but I'm a bit confused by your request... All I see in the above list is properties with no mention of _
, so I assume you mean to remove properties altogether -- gone.
Co-authored-by: Chandler Carruth <[email protected]>
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.
Addressing comments
proposals/p0861.md
Outdated
- `UpperCamelCase` will be used when the identifier can be resolved to a | ||
specific value at compile-time. |
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.
Using the second suggestion, since I assume you prefer it.
proposals/p0861.md
Outdated
Private member variables should use a `_` suffix in order to prevent name | ||
collisions. We discourage private properties. |
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.
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 the only main thing left is making sure we've converged on the least confusing phrasing for the UpperCase stuff. Some minor things elsewhere....
proposals/p0861.md
Outdated
- `UpperCamelCase` will be used when the identifier can be resolved to a | ||
specific value at compile-time. |
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.
FWIW, I think I prefer the latest version ("... names a specific program entity, such as ....") slightly over "cannot have a dynamically varying value". Maybe they could be combined?
proposals/p0861.md
Outdated
Private member variables should use a `_` suffix in order to prevent name | ||
collisions. We discourage private properties. |
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'd just like to avoid pre-adopting a workaround for an avoidable design problem... Thanks for moving this to an open question, would it be OK to remove it from the list above as well?
Co-authored-by: Chandler Carruth <[email protected]>
…eow/carbon-lang into proposal-naming-conventions
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.
Addressing comments
proposals/p0861.md
Outdated
Private member variables should use a `_` suffix in order to prevent name | ||
collisions. We discourage private properties. |
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.
Okay, but I'm a bit confused by your request... All I see in the above list is properties with no mention of _
, so I assume you mean to remove properties altogether -- gone.
proposals/p0861.md
Outdated
- `UpperCamelCase` will be used when the identifier can be resolved to a | ||
specific value at compile-time. |
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.
Tried rephrasing...
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.
LGTM with a minor tweak to Base
below!
Co-authored-by: Richard Smith <[email protected]>
Co-authored-by: josh11b <[email protected]>
Co-authored-by: josh11b <[email protected]>
Co-authored-by: josh11b <[email protected]>
A pretty straight copy of #861. Cutting down README.md example text since it seemed a little redundant with examples in the bullets.
- For idiomatic Carbon code: - `UpperCamelCase` will be used when the identifier can be resolved to a specific value at compile-time. - `lower_snake_case` will be used when the identifier's value won't be known until runtime, such as for variables. - For Carbon-provided features: - Keywords and type literals will use `lower_snake_case`. - Other code will use the guidelines for idiomatic Carbon code. Co-authored-by: Chandler Carruth <[email protected]> Co-authored-by: Richard Smith <[email protected]> Co-authored-by: josh11b <[email protected]>
A pretty straight copy of #861. Cutting down README.md example text since it seemed a little redundant with examples in the bullets.
Primitive types have been renamed in pull request carbon-language#861 and also the design document.
Primitive types have been renamed in pull request carbon-language#861 and also the design document.
Primitive types have been renamed in pull request #861 and also the design document.
UpperCamelCase
will be used when the identifier can be resolved to aspecific value at compile-time.
lower_snake_case
will be used when the identifier's value won't beknown until runtime, such as for variables.
lower_snake_case
.