Naming conventions: Difference between revisions

Line 1,532:

Roughly speaking: camelCaseFunctionName, TitleCaseTypeName, snake_case_variable_name. More precisely:

If x is a type then x should be TitleCase, unless it is a struct with 0 fields and is never meant to be instantiated, in which case it is considered to be a "namespace" and uses snake_case.

* If x is a type then x should be TitleCase, unless it is a struct with 0 fields and is never meant to be instantiated, in which case it is considered to be a "namespace" and uses snake_case.

If x is callable, and x's return type is <code>type</code>, then x should be TitleCase.

If x is ~~otherwise~~ callable, then x should be ~~camelCase~~.

* If x is callable, and x's return type is <code>type</code>, then x should be TitleCase.

⚫

Otherwise, x should be snake_case.

* If x is otherwise callable, then x should be camelCase.

⚫

* Otherwise, x should be snake_case.

Acronyms, initialisms, proper nouns, or any other word that has capitalization rules in written English are subject to naming conventions just like any other word. Even acronyms that are only 2 letters long are subject to these conventions.

Line 1,587:

Line 1,591:

fn readU32Be() u32 {}

</lang>

These are general rules of thumb; if it makes sense to do something different, do what makes sense. For example, if there is an established convention such as <code>ENOENT</code>, follow the established convention.

=={{header|zkl}}==

* Conventions are for the user to [create and] follow, no enforcement.