Skip to content

Latest commit

 

History

History
65 lines (51 loc) · 2.9 KB

naming_conventions.md

File metadata and controls

65 lines (51 loc) · 2.9 KB
Raw

Naming conventions

Table of contents

TODO

This is a skeletal design, added to support the overview. It should not be treated as accepted by the core team; rather, it is a placeholder until we have more time to examine this detail. Please feel welcome to rewrite and update as appropriate.

Overview

We would like to have widespread and consistent naming conventions across Carbon code to the extent possible. This is for the same core reason as naming conventions are provided in most major style guides. Even migrating existing C++ code at-scale presents a significant opportunity to converge even more broadly and we're interested in pursuing this if viable.

Our current proposed naming convention, which we at least are attempting to follow within Carbon documentation in order to keep code samples as consistent as possible, is:

  • UpperCamelCase for names of compile-time resolved constants, such that they can participate in the type system and type checking of the program. Comple-time constants fall into two categories:
    • Template constants that can be used in type checking, including literals.
    • Generic constants whose value is not used in type checking, but will be used as part of code generation.
  • lower_snake_case for names of run-time resolved values.

As an example, an integer that is a compile-time constant sufficient to use in the construction a compile-time array size might be named N, where an integer that is not available as part of the type system would be named n, even if it happened to be immutable or only take on a single value. Functions and most types will be in UpperCamelCase, but a type where only run-time type information queries are available would end up as lower_snake_case.

We only use UpperCamelCase and lower_snake_case (skipping other variations on both snake-case and camel-case naming conventions) because these two have the most significant visual separation. For example, the value of adding lowerCamelCase for another set seems low given the small visual difference provided; in particular, one-word identifiers would have no difference.

The rationale for the specific division between the two isn't a huge or fundamental concept, but it stems from a convention in Ruby where constants are named with a leading capital letter. The idea is that it mirrors the English language capitalization of proper nouns: the name of a constant refers to a specific value that is precisely resolved at compile time, not just to some value. For example, there are many different shires in Britain, but Frodo comes from the Shire -- a specific fictional region.